LassoUserGuide_4.0.5

Project Lasso 4.0.2

LogLogic Windows Event Collector Guide

Software Release: 4.0.2 Document release: February 2008 Part No: LL41002-00E04020000 This manual supports Project Lasso 4.0.2 and later releases until replaced by a newer edition.

Š 2005 - 2008 LogLogic, Inc. All rights reserved.

LogLogic is a trademark of LogLogic, Inc. All other products or services mentioned are the trademarks, service marks, registered trademarks or registered service marks of their respective owners.

LogLogic, Inc. 110 Rose Orchard Way Ste200 San Jose, CA 95134 Tel: +1 408 215 5900 Fax: +1 408 774 1752 U.S. Toll Free: 888 347 3883 Email: info@loglogic.com www.loglogic.com

Contents Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter 1

Installing Project Lasso Prerequisites for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Installing Project Lasso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Scripted Installation of Project Lasso on Multiple Systems . . . . . . . . . . . . . . . . . . . . . . . . 10

Chapter 2

Configuring Project Lasso Setting Hosts and Event Logs to Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 hostlist.ini File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Setting Run-Time Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Lasso.ini Configurable Run-Time Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Basic Project Lasso Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 LogAppliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 CheckRemHostAvail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 CheckHostListInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 MaxNumWorkerThreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Control Event Collection and Spooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 HighWaterMarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 NewHostSkipHistorical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 WatermarkWriteInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 EventPollInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 SpoolPath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 SpoolFileSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Control DLL Collection and Project Lasso Shares. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 DllLoadInterval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 SkipInitDLLScan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 RepositoryPath. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 EnableShareDlls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 EnableAdminSharesIfDisabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 DefaultLassoShare. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Error Logging, Tracing, and Access Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 DebugLevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 LogLevel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 MaxTraceFileSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 AccessReport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 AccessReportFileSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Configuring Project Lasso as a Windows Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Windows Event Collector (Project Lasso) Guide

3

CONTENTS

Configuring Site-Specific Network Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Chapter 3

Running Project Lasso Running Project Lasso as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Chapter 4

How Project Lasso Works Agent and Collector Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Windows Services Control Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Configuration Parameters in the Lasso.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Target Hosts Monitored Using the hostlist.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Using Multi-Threading for Parallel Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Testing Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Accessing Registry Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Locating String Resource DLL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Building the Project Lasso Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Event Messages from Monitored EventLogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Expanding EventLog Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Traceability and Field Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Scalability and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Appendix A

Permissions and Security Considerations for Project Lasso Authentication and Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Privileges Required for the Project Lasso User Account . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Collecting DLLs in the Project Lasso Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Appendix B

TCP/IP and UDP/IP Ports Used by Lasso Lasso Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Testing Project Lasso Communication with Monitored Hosts through a Firewall . . . . . . . 44

4

Windows Event Collector (Project Lasso) Guide

About This Guide

Preface

About This Guide

The LogLogic Windows Event Collector Users Guide describes how to install, configure, and manage security for the LogLogic Windows Event Collector (also called Project Lasso).

The LogLogic Windows Event Collector (Project Lasso) converts Windows Event Logs into a syslog stream that a LogLogic appliance can collect. You can configure Project Lasso to monitor multiple machines across your network from a single Windows host machine.

Project Lasso can monitor the following servers and workstations: Servers - Windows 2000 and Windows 2003 Workstations - Windows XP Professional and Windows 2000 Professional Project Lasso: monitors specified Windows hosts from a central Log Collection Server collects all EventLog records and other related data from specified Windows hosts can monitor and collect from System, Security, Application, DNS Server, ADServer, File Replication Service, and custom logs generates complete, easy-to-read EventLog messages sends EventLog messages to Log Management appliances

Related Documents In addition to this LogLogic Windows Event Collector Users Guide, you might want to refer to the following documentation provided with the LogLogic appliance software: LogLogic Windows Event Collector Release Notes: This document contains any late-breaking information specific to the Project Lasso release.

LogLogic Quick Start Guide: This guide gives you short, simple instructions for getting started quickly with a new appliance.

LogLogic Administration Guide: This guide explains administrative tasks in more complete detail.

LogLogic Upgrade Guide: This guide provides information relevant to upgrading an existing appliance.

LogLogic Help: This online help system is integrated into the appliance. It provides information about fields within the user interface. To access complete online help system, click on the Help link in the upper right of the screen. For context-sensitive help, use the ? button below the Help link.

Windows Event Collector (Project Lasso) Guide

5

Conventions

Conventions LogLogic documentation uses the following conventions to highlight code and command-line elements: Monospace is used for programming elements (such as code fragments, objects, methods, parameters, and HTML tags) and system elements (such as file names, directories, paths, and URLs).

Monospace bold is used to distinguish system prompts or screen output from user responses. username: root home directory: home\test Monospace italic is used for placeholders, which are general names that you replace with names specific to your site.

LogLogic_home_directory\upgrade\ Straight brackets signal options in command-line syntax. ls [-AabCcdFfgiLlmnopqRrstux1] [-X attr] [path ...]

A straight vertical line separates option choices when only two choices exist.

HighWaterMarks,ON|OFF

6

Windows Event Collector (Project Lasso) Guide

CHAPTER 1

Installing Project Lasso

C HAPTER 1

Installing Project Lasso

Prerequisites for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Installing Project Lasso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Scripted Installation of Project Lasso on Multiple Systems . . . . . . . . . . . . . . . . . . . . . 10

Prerequisites for Installation To install Project Lasso, you need the following hardware, software, and environment: 1 gigabyte RAM, 20 gigabytes of free disk space, 1 2.0 Ghz CPU (2 or more is recommended), 1000 Mbps network interface. If you have more than 50 log-intensive hosts to monitor, consider additional RAM. The free disk space amount on the Project Lasso host server depends on the data rate of log events expected, in aggregate, from the monitored hosts. This disk space is not used as long as the Project Lasso host maintains contact with the LogLogic Appliance. Up to 10% of the disk, or more if you configure it, is used for spooling storage if the LogLogic appliance connection is lost.

LogLogic version 4.0.2 or later installed on your LogLogic appliance.

Note: To run Project Lasso with an earlier LogLogic release, you must register all Windows servers with the LogLogic Appliance prior to starting Project Lasso for the first time. Earlier releases do not auto-discover syslog-ng data. LogLogic recommends upgrading to 4.0.2 or later.

Windows 2003 Server to host Project Lasso, in the same Windows Domain as the Windows hosts to monitor. (Non-Domain hosts can be monitored, but it takes effort.)

Domain User ID under which Project Lasso runs on the host Windows server. The Project Lasso User ID must have certain permissions in the Domain and/or on each monitored host, to have remote access to protected resouces such as the Windows Security Event Log. Note: Log Administrators do not need to know the Project Lasso user password. Your Security Administrator can keep the password secure so long as this installation can be completed.

Note: To run Project Lasso in a non-Domain environment, you must work within the constraints of Windows user authentication. For details, see Appendix A, Permissions and Security Considerations for Project Lasso.

Windows Event Collector (Project Lasso) Guide

7

Installing Project Lasso

A text editor, such as NotePad or WordPad, to edit the .csv configuration files.

Installing Project Lasso You can install Project Lasso from a CD or from a network install image, downloadable from http://sourceforge.net/projects/lassolog/. You install (and uninstall) Project Lasso using the InstallShield installer program.

To install Project Lasso on a large number of machines (for instance, if you are using agent mode), you can use InstallShield's scripted install capability to automate the process. See Scripted Installation of Project Lasso on Multiple Systems on page 10.

Project Lasso also installs as a Windows Service, and must be configured to auto-start on boot and auto-restart upon process failure.

Installing Project Lasso: 1. (Collector mode only) Create a Project Lasso User ID (as a Domain User ID) for the host Windows Server machine. The Project Lasso User ID must have permissions equivalent to the Domain Administrator or the Local machine Administration on each monitored server. For more information, see Prerequisites for Installation on page 7.

Project Lasso running in agent mode can run as the local system, so this is required only for collector mode.

2. Log in to the Project Lasso host machine using an account with privileges to install services.

3. Run the ProjectLasso_4.0.2_Installer.exe file. a. Accept the License Agreement; click Next. b. Read the Project Lasso Release Notes; click Next. c. Select a destination folder to install Project Lasso in; click Next.

InstallShield asks whether to use a custom Lasso.ini file. d. Indicate whether to use a custom file. If so, indicate the file location (whether on this system or on a network file server share).

Using a custom Lasso.ini file lets you perform scripted install with options not included in this Installer interface. Typically, it is used for installing the same custom settings on a large number of machines. e. Select the Project Lasso Repository location to create; click Next.

The Repository contains all resource string .dll files necessary for text expansion of log messages. Each EventLog on each host can have up to three .dll files that must be copied. The .dll files can be several megabytes each.

8

Windows Event Collector (Project Lasso) Guide

CHAPTER 1

Installing Project Lasso

f. Select the spooling directory location to create; click Next.

The spooling directory contains: Log messages, if the connection to the LogLogic appliance is lost. LogLogic recommends providing at least the same percentage of disk space that you specify later in the Lasso.ini file.

Other data files written by Project Lasso, including LassoHighWatermarks.log and LassoTrace.log. g. Complete the installation program as prompted, providing: LogLogic appliance information - the appliance IP address and port number Monitoring parameters - certain Project Lasso performance defaults.

For guidance, see Control Event Collection and Spooling on page 18. These settings can be changed during Project Lasso configuration in the Lasso.ini file.

Host and event log identification - the primary host name and which logs to monitor.

For guidance, see Setting Hosts and Event Logs to Monitor on page 11. These settings can be changed during Project Lasso configuration in the hostlist.ini file. h. Confirm the settings as displayed; click Next.

InstallShield displays that it is ready to install Project Lasso. i. Click Next.

InstallShield installs Project Lasso, and notifies you upon completion.

4. Optionally, limit access privileges to the install, Repository, and spool directories created during installation.

Log data can temporarily reside in these directories, so you might want to limit access to them. If you limit access, make sure you give the Project Lasso UserID full and unrestricted access to these directories and all their subdirectories.

Make sure that appropriate Log Administrators, who will maintain the list of hosts monitored by Project Lasso, have at least read/write access to the installation directory.

IMPORTANT! The Project Lasso Windows Event Collector service is installed with the Startup type in the “Manual� state. You must configure Project Lasso, then use the Windows Services Manager to start the service. See Chapter 2, Configuring Project Lasso.

Windows Event Collector (Project Lasso) Guide

9

Scripted Installation of Project Lasso on Multiple Systems

Scripted Installation of Project Lasso on Multiple Systems To simplify the installation of Project Lasso on a large number of machines (for example, if you are using agent mode), you can use InstallShield's scripted install capability.

1. Create a recording file.

This option records all the user input and options for future playback. The f1 option can use any filename but it should be an absolute path to an existing folder. run: Loglogic_Installer.exe /r /f1"c:\temp\setup.iss" 2. Copy the recorded install file and the installer program for access to use on other machines. You can: Copy them directly to each machine on which you will install Project Lasso.

Copy them to a shared network file server, accessible from each machine you will install Project Lasso on.

3. If you are using a custom Lasso.ini file for these machines, copy it to the same system as the recorded install file and installer program.

4. Play back the recording file on each additional machine: To run the installer if it is on the machine: run: Loglogic_Installer.exe /s /f1"c:\temp\setup.iss" To run the installer if it is on a network server: run: Loglogic_Installer.exe /s /f1"\\server\share\setup.iss" During interactive installation, if you try to install Project Lasso on an Operating System other than Windows 2003 Server, it opens a warning dialogue box, but lets you continue.

Scripted install suppresses this warning dialogue.

During interactive installation, Project Lasso is installed as a service, but with Startup type set to Manual. You are expected to set Startup type to Automatic after configuring all the items specified in Chapter 2. However, if you are performing a hands-free scripted install in agent mode (using your Lasso.ini file provided with the install script, the default hostlist.ini consisting of only localhost, and a User ID of Local System), you might want to install Project Lasso with Startup type already set to Automatic. To do this, add the /autostart flag to the command line invocation of Loglogic_Installer.exe.

10

Windows Event Collector (Project Lasso) Guide

CHAPTER 2

Configuring Project Lasso

C HAPTER 2

Configuring Project Lasso

Before you can start Project Lasso, you must configure it: 1. Setting Hosts and Event Logs to Monitor, by editing the hostlist.ini file (page 11) 2. Setting Run-Time Parameters, by editing the Lasso.ini file (page 14) 3. Configuring Project Lasso as a Windows Service (page 26) 4. Configuring Site-Specific Network Details, if necessary, to enable the Project Lasso host machine to communicate with target machines in your network (page 27)

Setting Hosts and Event Logs to Monitor At service startup, Project Lasso loads a list of hosts (by NetBIOS name, fully qualified domain name, or IP address) and EventLogs to monitor from a hostlist.ini configuration file. hostlist.ini is a comma-separated file that lists each host ID, followed by the names of logs to monitor on that host.

Project Lasso can monitor System, Security, Application, DNS Server, AD Server, and File Replication Service logs, and any custom logs for which the EventLog name is known (for example, OracleLog).

Also at service start-up, Project Lasso loads the target LogLogic Appliance (by IP address or DNS name) from the Lasso.ini file. See Setting Run-Time Parameters on page 14.

Note: The hostlist.ini file is loaded at start-up and re-read periodically, according to the configuration parameter CheckHostListInterval. You can edit the list of monitored hosts while Project Lasso is running. New hosts are added at the next CheckHostListInterval. Removed hosts continue to be collected until the Project Lasso service is restarted.

To modify the hostlist.ini file: 1. On the Project Lasso host machine, navigate to SYSTEM\Program Files\Lasso.

2. Open the hostlist.ini file using a program that can read .csv files such as Microsoft Excel.

3. Add, remove, or update lines in hostlist.ini so it contains all the hosts and EventLogs for Project Lasso to monitor. Every line follows the form: hostname,lognames,[sharename=sharepath\]

Windows Event Collector (Project Lasso) Guide

11

Setting Hosts and Event Logs to Monitor

a. hostname identifies the system to monitor: Use the IP Address or Server name for the machine to monitor. For example, dc-server1 or 192.168.22.14.

To monitor the Project Lasso Host, use the reserved word localhost, the local IP address,or the machine name.

If there are multiple IP addresses on the machine to monitor, specify the IP address to monitor; do not specify localhost. b. lognames identifies one or more (comma-separated) logs, or groups of standard Windows logs, to monitor on the system: Enter one or more (comma-separated) EventLog names, specifying particular standard Windows logs and/or other EventLogs. *3 specifies three standard Windows 2000/2003/XP logs: Security, Application,

System. *6 specifies six standard Windows 2000/2003 logs: System, Security, Application, DNS Server, ADServer, and File Replication Service.

Generally, only Domain Controllers have all six of these logs. For hosts that do not have all of these logs, the unavailable ones are ignored without error.

You can include specific EventLog names and a *3 or *6 group entry in the same host entry line. c. sharename=sharepath (optional) defines a Windows Share on each target specifically for Project Lasso use.

This makes the use of Administrative Shares no longer necessary for DLL collection.

The DefaultLassoShare parameter on page 23 allows creation of a generic Lasso Share with the same name and a common path on all monitored hosts. However, in hostlist.ini you can specify a unique name and path per host. If both are present, the per-host value in hostlist.ini overrides the general DefaultLassoShare value in Lasso.ini. sharename and sharepath cannot include a comma or equal sign. sharepath must be terminated by a back-slash character.

IMPORTANT! Do not insert spaces or blank characters, unless they are part of field values such as an EventLog name. Values must be delimited with commas only, though leading and trailing blank spaces are ignored. Blank spaces can create errors when Project Lasso is reading the file during startup.

4. Enter comments as needed, by starting a line with the # character.

The # character is only allowed at the beginning of a line; you cannot add comments at the end of a keyword line.

5. Save the hostlist.ini file.

New hosts are added at the next CheckHostListInterval as specified in Lasso.ini.

Removed hosts continue to be collected until the Project Lasso service is restarted.

12

Windows Event Collector (Project Lasso) Guide

CHAPTER 2

Configuring Project Lasso

hostlist.ini File Example The following is an example of valid entries in the hostlist.ini file: localhost,*3 dc-server1,*6 192.168.22.14,Security,System 192.168.22.53,*3,OracleLog 192.168.1.1,*6,LassoShare=C:\LassoShare\ Table 1

hostlist.ini File Example Details

hostlist.ini Entry

Monitored Event Logs

Monitored Machine

localhost,*3

Security, Application, System

local Project Lasso host

dc-server1,*6

System, Security, Application, DNS dc-server1 Server, ADServer, File Replication Service

192.168.22.14,Security, Security, System System

192.168.22.14

192.168.22.53,*3,Oracle Security, Application, System, OracleLog 192.168.22.53 Log 192.168.1.1,*6,LassoSha System, Security, Application, DNS 192.168.1.1 (with a re=C:\LassoShare\ Server, ADServer, File Replication Service Project Lasso Share created at the specified path)

Windows Event Collector (Project Lasso) Guide

13

Setting Run-Time Parameters

Setting Run-Time Parameters At service startup, Project Lasso loads application parameters for your site from the Lasso.ini file. Lasso.ini is also read at the beginning of each event poll cycle. It is a .csv file that can be viewed using any spreadsheet program or text editor.

Note: Although the Lasso.ini file is read at the beginning of each poll cycle, some keyword values are only read at startup. If you need to make changes to the file, determine if your changes require the Project Lasso Windows Event Collector service to be restarted. For more information on running Project Lasso, see Running Project Lasso as a Service on page 29.

To modify the Lasso.ini file: 1. On the Project Lasso host machine, navigate to SYSTEM\Program Files\Lasso.

2. Open the Lasso.ini file using a program that can read .csv files such as Microsoft Excel.

3. Add, remove, or update lines in Lasso.ini so it contains the configuration parameter values needed for your site. Every line follows the form: keyword,variable[,variable...] a. keyword is a configurable run-time parameter, as listed in Table 2 on page 15. b. variable is an option for the entry’s keyword. Some parameters allow multiple options.

IMPORTANT! Do not insert spaces or blank characters. Values must be delimited with commas only, though leading and trailing blank spaces on field values are ignored. Keywords are not case-sensitive.

4. Enter comments as needed, by starting a line with the # character.

The # character is only allowed at the beginning of a line; you cannot add comments at the end of a keyword line.

5. Save the Lasso.ini file.

New run-time parameter settings are available either immediately or upon restart of Project Lasso. The parameter descriptions in this chapter identify when each setting is available.

14

Windows Event Collector (Project Lasso) Guide

CHAPTER 2

Configuring Project Lasso

Lasso.ini Configurable Run-Time Parameters Table 2 describes the Project Lasso run-time parameters you can configure in the Lasso.ini file.

Table 2

Lasso.ini Configurable Run-Time Parameters

Keyword

Required Description

Page

LogAppliance

Y

The target appliance

page 16

CheckRemHostAvail

N

Checks whether target hosts are available on the network

page 16

CheckHostListInterval

N

How often hostlist.ini is reloaded

page 17

MaxNumWorkerThreads

N

Maximum number of worker threads for event collection from remote hosts

page 17

Basic Project Lasso Configuration

Control Event Collection and Spooling HighWaterMarks

N

Restarts collecting all available logs

page 18

NewHostSkipHistorical

N

Skips collecting historical event data on new host

page 18

WatermarkWriteInterval

N

Interval for writing progress cursors

page 19

EventPollInterval

N

Minimum time interval between pollings of hosts and logs for additional events

page 19

Spoolpath

N

Where Lasso spools log messages if connection is lost

page 19

SpoolFileSize

N

Maximum size of all spool files

page 20

Control DLL Collection and Project Lasso Shares DllLoadInterval

N

Time between collecting String Resource DLL page 21 files

SkipInitDLLScan

N

Skips startup check of DLLs

page 21

RepositoryPath

N

Where Lasso stores resource string .dll files for text epansion of log messages

page 21

EnableShareDlls

N

Identifies and shares identical DLLs

page 22

EnableAdminSharesDisabled

N

Temporarily enables Admin Shares for DLL collection

page 22

DefaultLassoShare

N

Allows a Windows Share on each target host

page 23

Error Logging, Tracing, and Access Reporting DebugLevel

N

Writes messages into a trace file

page 24

LogLevel

N

Writes eventlog entries

page 24

MaxTraceFileSize

N

Maximum size of LassoTrace.log

page 24

AccessReport

N

Writes summary resource access reports

page 25

AccessReportFileSize

N

Maximum size of LassoAccessReport.log

page 25

Windows Event Collector (Project Lasso) Guide

15

Setting Run-Time Parameters

Basic Project Lasso Configuration The following parameters control basic Project Lasso confirmation settings.

LogAppliance (Required) Specifies the target appliance.

LogAppliance,appliance-ID[,port-number[,udp]] appliance ID (required) - IP address or DNS name of the appliance port-number (optional) - port number for syslog-ng communication (default is 514) udp (optional) - causes Project Lasso to use UDP instead of TCP to communicate with the LogLogic Appliance. If udp is specified, port-number must also be specified.

Caution: UDP communication is intended for use only with Project Lasso in “agent” mode. If you specify udp, the hostlist.ini file should contain only “localhost” as a monitored host. If you accidentally set udp while monitoring remote hosts, the LogLogic Appliance interprets all Project Lasso logs as coming from the Project Lasso Host rather than from the various remote hosts.

Examples

To specify an appliance with IP address 192.168.22.199, using standard syslog-ng port 514: LogAppliance,192.168.22.199 To specify appliance 192.168.22.199 using port number 1514: LogAppliance,192.168.22.199,1514 To specify appliance LLAUSTIN using port number 1514: LogAppliance,LLAUSTIN,1514 To use UDP communications for appliance 192.168.22.199 using port 514: LogAppliance,192.168.22.199,514,udp

CheckRemHostAvail (Optional) Enables Project Lasso to check whether target hosts are available for communication over the network by sending it an Echo message using TCP port 7.

CheckRemHostAvail,0|1 If a target host is running Windows Firewall, port 7 is blocked by default. In this case, you can turn off the Echo test by adding CheckRemHostAvail,0 to Lasso.ini. See Testing Project Lasso Communication with Monitored Hosts through a Firewall on page 44.

Default is 0.

If an expected host is not available on the network, Windows networking APIs can take between 30 seconds and 2 minutes to time out. During this time, one of the Project Lasso threads is blocked and unavailable for other work. Non-response to the Echo test takes only a few seconds. Therefore, if you turn off the Echo test it is important to have a clean hostlist.ini file, without large numbers of unavailable target hosts.

16

Windows Event Collector (Project Lasso) Guide

CHAPTER 2

Configuring Project Lasso

Tip: If Project Lasso is collecting logs from the localhost normally, but is collecting no logs from remote hosts and the manual tests in Testing Project Lasso Communication with Monitored Hosts through a Firewall on page 44 all work, try turning off CheckRemHostAvail.

CheckHostListInterval (Optional) Specifies how often Project Lasso reloads the hostlist.ini file.

CheckHostListInterval,value value is the reload interval, in seconds. (default is 3600) To disable the reload of hostlist.ini and make it read only at startup, use 0.

Example

To check the hostlist.ini file for changes once per hour: CheckHostListInterval,3600

MaxNumWorkerThreads (Optional) Sets the maximum number of worker threads for event message collection from remote hosts. The actual number of threads is defined by this value and the number of hosts in hostlist.ini .

MaxNumWorkerThreads,value Valid values: = 1 to 99 (default is 4) Usage Notes

LogLogic recommends setting this parameter to 4 times the number of CPU cores in the Project Lasso Host server.

The number of worker threads actually used by the system never exceeds the number of hosts defined in hostlist.ini at the time the Project Lasso service is started.

Example

MaxNumWorkerThreads,8

Windows Event Collector (Project Lasso) Guide

17

Setting Run-Time Parameters

Control Event Collection and Spooling The following parameters control event collection and spooling settings.

HighWaterMarks (Optional) HighWaterMarks affects how Project Lasso collects new EventLog messages.

It is dependent on the concept of “progress cursors” or “high-water marks”, as mentioned in Chapter 4, How Project Lasso Works.

HighWaterMarks,ON|OFF As Project Lasso collects events, it maintains a record of the last event successfully collected from each monitored EventLog on each target host. It periodically records these progress cursor values in the LassoHighWatermarks.log file in the Project Lasso Spool directory.

At startup, Project Lasso reads the LassoHighWatermarks.log file to find out how far it got on each monitored EventLog during its last run. To discard this information and restart collecting all available logs, set HighWaterMarks,OFF. This one-time setting is automatically reset to HighWaterMarks,ON immediately after Project Lasso startup.

Usage Notes

The value of HighWaterMarks is effective only at startup, and is therefore not reloadable.

If the value is invalid, the default value (ON) is used.

Example

HighWaterMarks,ON

NewHostSkipHistorical (Optional) NewHostSkipHistorical affects how Project Lasso collects new EventLog messages. It is dependent on the concept of “progress cursors” or “high-water marks”, as mentioned in Chapter 4, How Project Lasso Works.

NewHostSkipHistorical,0|1 As Project Lasso collects events, it maintains a record of the last event successfully collected from each monitored EventLog on each target host. It periodically records these progress cursor values in the LassoHighWatermarks.log file in the Project Lasso Spool directory.

When you add a new host to hostlist.ini, or if Project Lasso starts up and there is no LassoHighWatermarks.log file, Project Lasso normally collects all logs from the monitored EventLogs, no matter how old. This can result in thousands of old event messages being collected and transmitted to the LogLogic Appliance.

Usage Notes

If the value is invalid, the default value (0) is used.

Example

To skip collecting historical event data:

18

Windows Event Collector (Project Lasso) Guide

CHAPTER 2

Configuring Project Lasso

NewHostSkipHistorical,1

WatermarkWriteInterval (Optional) Identifies the interval, in milliseconds, for when progress cursors are written.

WatermarkWriteInterval,value Usage Notes

Range: 100 milliseconds (0.1 seconds) through 10000 milliseconds (10 seconds) If the value is invalid, the default value (1000 milliseconds; 1 second) is used.

The value is reloadable and is effective starting at the next event poll cycle.

Example

WatermarkWriteInterval,1000

EventPollInterval (Optional) Identifies the minimum time interval, in seconds, since the last data collection completed after which Project Lasso polls the identified hosts and logs again for data.

EventPollInterval,value Note: The EventPollInterval is not a guarantee of performance. It is the minimum time between event collections. If a large number of busy servers are monitored, the overall polling cycle time might be much longer than the requested EventPollInterval. The actual polling interval depends on the number of hosts, number of threads, and how busy the collection server is.

Usage Notes

Range: 1 through 86400 seconds (1 day) If the value is invalid, the default value (300 seconds; 5 minutes) is used.

Setting value to 1 allows near real-time log collection.

The value is reloadable and is effective starting at the next event poll cycle.

Example

To set the time between polling occurrences to 5 minutes (300 seconds): EventPollInterval,300

SpoolPath (Optional) Controls the directory where Project Lasso spools log messages if the connection to the appliance is temporarily lost. This configuration line is normally written by the Project Lasso installation program, but can be modified manually. You must have enough available disk space on your host machine. LogLogic recommends at least 5 gigabytes of free disk space.

SpoolPath,path The default path is .\.

Windows Event Collector (Project Lasso) Guide

19

Setting Run-Time Parameters

Usage Notes

If the value is invalid, the default value of RepositoryPath\Spool\, which resides under the same directory as the .dll file repository, is used.

The value is not reloadable. The value is read only during Project Lasso startup.

Example

SpoolPath,C:\Program Files\Lasso\LassoRepository\Spool\

SpoolFileSize (Optional) Identifies the maximum size of the spool files. If there are multiple spool files, this value defines the maximum combined size of all the spool files.

SpoolFileSize,value value is the percentage of disk space of the volume specified in the SpoolPath parameter.

The default is 1.0 (one percent of volume).

Usage Notes

Range: 0.1 (one tenth percent) through 10.0 (ten percent).

If the value is out of bound, it is matched to the appropriate boundary. That is, if the value is greater than 10.0, the value is set to 10.0.

If the value is invalid, the default value (1.0) is used.

The value is not reloadable. The value is read only during Project Lasso startup.

Example

SpoolFileSize,10.0

20

Windows Event Collector (Project Lasso) Guide

CHAPTER 2

Configuring Project Lasso

Control DLL Collection and Project Lasso Shares The following parameters control DLL collection and Project Lasso shares.

DllLoadInterval (Optional) Identifies the amount of time, in seconds, between when Project Lasso attempts to collect String Resource DLL files into the Project Lasso Repository.

DllLoadInterval,value Usage Notes

Range: 900 (15 min) through 2592000 (1 month).

If the value is invalid, the default value (3600; hourly) is used.

The value is reloadable and is effective starting at the next event poll cycle.

Example

DllLoadInterval,86400

SkipInitDLLScan (Optional) Skips Project Lasso’s normal startup check of all String Resource DLLs required by all monitored hosts. The check collects any DLLs that are not already in the Repository. Depending on the number of monitored hosts in hostlist.ini, this check can delay log collection.

SkipInitDLLScan,0|1 If you are certain the Repository exists and contains all required DLLs, skip the check: SkipInitDLLScan,1 Allowed values: 0 (initial DLL scan occurs; default) 1 (initial DLL scan is skipped) If needed DLLs are not already in the Repository, event messages collected before the next periodic DLL collection do not expand or parse correctly on the Appliance.

RepositoryPath (Optional) RepositoryPath controls the directory where Project Lasso stores all resource string .dll files necessary for text expansion of log messages. It is normally written by the Project Lasso installation program, but can be modified manually. You must have enough disk space available on your host machine. LogLogic recommends at least 20 GB free disk space, unless Project Lasso is being used in agent mode to monitor only the local host.

RepositoryPath,path Usage Notes

If the value is invalid, the default value of .\ (the current working directory where Project Lasso is installed) is used.

Windows Event Collector (Project Lasso) Guide

21

Setting Run-Time Parameters

The value is not reloadable. The value is read only during Project Lasso startup.

Example

RepositoryPath,C:\Program Files\Lasso\LassoRepository\

EnableShareDlls (Optional) Where possible, Project Lasso identifies and “shares” identical String Resource DLLs. This frees up a lot of disk space on a Project Lasso Host monitoring many remote systems. If all hosts are kept at the same level of Microsoft service packs and patch level, they have mostly identical DLLs. EnableShareDlls,0|1 DLLs are shared only if they appear identical and are used identically. For example, if the same DLL is used in two different EventLog contexts, there are still two copies of the DLL. EnableShareDlls disables this feature, copying every String Resource DLL used by every monitored host to the Project Lasso host. Because this typically requires 100 to 300 MB of disk space per remote host, LogLogic recommends keeping EnableShareDlls enabled.

Usage Notes

Allowed values: 0 (disable) or 1 (enable) If the value is invalid, the default value (1) is used.

Example

To enable the identifying and sharing of DLLs: EnableShareDlls,1 Note: The sharing of DLL files is done via an NTFS file system feature called “hard links.” If the RepositoryPath is on a non-NTFS volume, shared DLLs are disabled.

The behavior of hard links can be confusing, because the sharing of physical files by multiple hard link instances cannot be perceived in the Windows File Browser. Each instance of a hard link looks like a complete instance of the physical file. If you examine its properties in the Windows File Browser, each instance states the full size of the file. If you add up the file sizes, the Project Lasso Repository seems to take the same amount of space it did in 3.x or more, due to additional directory structures added for Shared Repository support. However, if you query the volume free space before and after creating the Project Lasso Repository, the actual disk usage of the Repository is far less than the sum of the hard link file sizes.

When you install Project Lasso 4.x over a 3.x installation, it replaces the old Project Lasso Repository with the new shared repository during the first DLL collection cycle.

EnableAdminSharesIfDisabled (Optional) Temporarily re-enables Administrative Shares to allow collection of String Resource DLLs from remote hosts.

22

Windows Event Collector (Project Lasso) Guide

CHAPTER 2

Configuring Project Lasso

Some sites disable Administrative Shares for security reasons, so this option lets Project Lasso re-enable them long enough to collect DLLs, then disables them again. Project Lasso must be running with Administrator privileges, and Project Lasso Shares cannot also be in use (see DefaultLassoShare).

EnableAdminSharesIfDisabled,0|1 0 (disabled Admin Shares are inaccessible; default) 1 (disabled Admin Shares are temporarily enabled during DLL collection) Example

To allow temporary re-enabling of Administrative Shares for DLL collection: EnableAdminSharesIfDisabled,1

DefaultLassoShare (Optional) Allows the configuration of a Windows Share on each target host, specifically for use by Project Lasso. The use of Administrative Shares is then no longer necessary.

DefaultLassoShare,sharename=sharepath If absent, there is no Default Lasso Share. If present, it defines a Project Lasso Share name that is created on each monitored host. This default can be overridden on a per-host basis in the hostlist.ini file.

If Project Lasso runs as a domain administrator, the default Default Lasso Share is automatically created. If Project Lasso does not run as a domain administrator, Project Lasso can automatically create the Default Lasso Share only if it has sufficient access.

Otherwise, it must be created using the lasso.exe -c command.

Usage Notes

sharename and sharepath must not include 'comma' or 'equal sign' characters. sharepath must be terminated by a '\' character. sharepath can include special substrings which are interpreted relative to their meaning on each monitored host: %SYSTEMDRIVE% - the root drive where Windows is installed, for example: C: %SYSTEMROOT% - the path where Windows is installed, for example: C:\Windows These special substrings are not available in hostlist.ini, only with the DefaultLassoShare keyword in Lasso.ini.

Example

DefaultLassoShare,LassoShare=%SYSTEMDRIVE%\LassoShare\ IMPORTANT! The Project Lasso Share does not have to publish any existing directories on the host, in particular the directories that contain String Resource DLLs. For example, it should not point to C:\windows. To improve security, LogLogic recommends using a directory path that points to a uniquely named subdirectory that does not exist and/or contains no data files, such as C:\LassoShare\. The Project Lasso Share is used only as an intermediate transfer area, and only needs a few hundred MB of space on its volume.

Windows Event Collector (Project Lasso) Guide

23

Setting Run-Time Parameters

Error Logging, Tracing, and Access Reporting The following parameters control error logging, tracing and access reporting.

DebugLevel (Optional) Enables Project Lasso to write messages into a trace file (LassoTrace.log, in the Project Lasso program installation folder).

DebugLevel,value The value variable controls the types of messages to trace.

Table 3

Trace Output Types

Output Type

Value

Description

Disable

0

default

Error

1

Project Lasso encountered an unrecoverable situation that results in loss of functionality.

Warning

2

Project Lasso encountered a situation that might result in loss of functionality.

Info

4

Project Lasso encountered a situation that the user should notice.

Debug

8

(For LogLogic Customer Support use) Project Lasso notes every minor and recoverable error.

Trace

16

(For LogLogic Customer Support use) Project Lasso displays step in and out of various modules of the program.

Examples

To disable Trace: DebugLevel,0 To enable Trace for Error, Warning, and Info = 1 + 2 + 4 = 7: DebugLevel,7 To enable Trace for Error, Warning, Info, Debug, Trace = 1 + 2 + 4 + 8 + 16 = 31: DebugLevel,31

LogLevel (Optional) Enables Project Lasso to write eventlog entries. If Project Lasso is monitoring the localhost, the messages are sent to the log appliance.

LogLevel,value The messages and level setting are identical to the DebugLevel keyword. This keyword separately controls the type of messages written to the eventlog.

Default is 1.

MaxTraceFileSize (Optional) Controls the maximum size, in MB, of LassoTrace.log until the output wraps around to the beginning of the file.

24

Windows Event Collector (Project Lasso) Guide

CHAPTER 2

Configuring Project Lasso

MaxTraceFileSize,size Default is 20.

AccessReport (Optional) Enables Project Lasso to write summary resource access reports. The report file is LassoAccessReport.log located in the Project Lasso program installation folder.

AccessReport,value These values set the level of detail in the report: 0 - Disable 1 - Resource access result success or failure 2 - Level 1 message plus error code or error message associated with this attempt 3 - Level 2 message plus data result from the access Default is 0.

IMPORTANT! SkipInitialDLLScan impacts the AccessReport.

AccessReportFileSize (Optional) Controls the maximum size, in MB, of LassoAccessReport.log until the output wraps around to the beginning of the file.

AccessReportFileSize,value Default is 20. Range is 1 through 1000.

Windows Event Collector (Project Lasso) Guide

25

Configuring Project Lasso as a Windows Service

Configuring Project Lasso as a Windows Service When running in collectore mode, Project Lasso runs as a Windows Service, so you must first configure it as a Service.

1. Set up the Windows Services parameters on the Project Lasso host machine. a. On the Project Lasso host machine, open the Windows Services control panel: Start Menu, click Settings > Control Panel and then Administrative Tools > Services The Services Window appears. b. Scroll down to find the Project Lasso Windows Event Collector service. c. Right-click the Project Lasso Windows Event Collector service, and then select Properties. d. On the General tab, set Startup type to Automatic, and then click Apply. e. On the Log On tab, in the Log on as field, select This Account, enter the Project Lasso User ID and associated password, and then click OK. The Project Lasso User ID is you used to log into the Project Lasso host machine. If you do not have the password for this ID, check with your System Security Administrator. f. Click the Recovery tab. Set First failure, Second failure, and Subsequent failures to Restart the Service. If not, set them to “Restart the Serve�, then click the Apply button. (In Project Lasso 4.0, these settings are already done by the Installer.) g. Click OK. Note: If any of these steps are prevented by the security settings in your Domain, ask your System Security Administrator for help. Your administrator might need to log in as himself and repeat the configuration steps.

2. Confirm the changes in Step 1 were made. Do not click in the Log on as or Password fields again, as this might reset the entries.

Project Lasso is now configured to run as a Windows Service. See Running Project Lasso as a Service on page 29.

26

Windows Event Collector (Project Lasso) Guide

CHAPTER 2

Configuring Project Lasso

Configuring Site-Specific Network Details In addition to controlling user privileges, some Windows environments use host names or IP addresses, or host-based firewall software, to control remote access.

1. Grant remote access authorization to the Project Lasso host machine on every Windows machine it monitors.

This is separate from the privileges of the Project Lasso User ID with Domain User permissions. Many host-based firewall software packages limit machine-to-machine access in Windows 2003. Prior to Windows 2003, this access was unlimited.

2. Ensure each monitored machine is running Windows Management Instrumentation (WMI).

WMI is required on every monitored system. WMI runs by default on all Windows operating system versions supported by Project Lasso. However, if WMI is turned off or network access is restricted, Project Lasso cannot monitor that host.

3. Ensure the services Remote Procedure Call (RPC), Remote Registry, and DCOM, are running on all monitored machines. These services are typically on by default.

4. Configure access to Shares on all monitored machines, to allow transport of String Resource DLLs from the remote hosts to the Project Lasso host: If Project Lasso has Administrator privileges on the Windows hosts, use the Administrative Shares, which are enabled by default on all Windows hosts.

Otherwise, create Project Lasso Shares. By specifying a default Lasso Share in Lasso.ini, or Project Lasso Shares for specific hosts in hostlist.ini, you can enable special shares that are used only by Project Lasso. Creation of these shares requires Project Lasso to run under the Domain Administrator user ID, but thereafter the Shares persist unless you deliberately remove them.

If no Project Lasso Shares exist, Project Lasso tries to use Administrative Shares. If Administrative Shares is turned off or network access is restricted, Project Lasso periodically attempts to use WMI to enable it briefly for DLL file collection. This is attempted only if the Lasso.ini parameter EnableAdminSharesIfDisabled is set to 1. If this succeeds it might generate a Security audit log message. If it fails, Project Lasso cannot collect message expansion resource files from that machine.

In this final case, if shared DLLs are enabled (EnableShareDlls), Project Lasso attempts to find a match in the current Repository for the DLLs needed. If it finds a match, Project Lasso uses it. Otherwise, log messages from that machine are incorrectly parsed by the LogLogic appliance for report purposes.

Windows Event Collector (Project Lasso) Guide

27

Configuring Site-Specific Network Details

28

Windows Event Collector (Project Lasso) Guide

CHAPTER 3

Running Project Lasso

C HAPTER 3

Running Project Lasso

Once configured, you can run Project Lasso as a Windows Service.

Running Project Lasso as a Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Running Project Lasso as a Service If you configured Project Lasso as a Windows Service (page 26), you can start the service.

To run Project Lasso as a Windows service, on the Project Lasso host machine: 1. Verify that the hostlist.ini and Lasso.ini files are configured as needed.

2. Open the Windows Services control panel: Start Menu > Settings > Control Panel and then Administrative Tools > Services The Services Window appears.

3. Scroll down to find the Project Lasso Windows Event Collector service.

4. Right- click the Project Lasso Windows Event Collector service, and then click Start.

The Status column for the Project Lasso Windows Event Collector service changes to Started.

Project Lasso runs indefinitely unless otherwise stopped or paused.

Note: To stop the Project Lasso Windows Event Collector, go to the Services control panel, right-click the Project Lasso Windows Event Collector service, and then click Stop.

Windows Event Collector (Project Lasso) Guide

29

Running Project Lasso as a Service

30

Windows Event Collector (Project Lasso) Guide

CHAPTER 4

How Project Lasso Works

C HAPTER 4

How Project Lasso Works

Project Lasso converts Windows Event Logs into a syslog stream that a LogLogic appliance can collect. You can configure Project Lasso to monitor multiple machines across your network from a single Windows host machine. There is no need to install additional software on each monitored machine.

All messages are delivered to an appliance through the syslog-ng protocol (TCP).

Syslog-ng lets you specify the original source IP Address, so the LogLogic appliance recognizes it as having come from the original source host, and not the Project Lasso host.

Agent and Collector Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Windows Services Control Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Configuration Parameters in the lasso.ini File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Target Hosts Monitored Using the hostlist.ini File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Using Multi-Threading for Parallel Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Testing Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Accessing Registry Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Locating String Resource DLL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Building the Project Lasso Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Event Messages from Monitored EventLogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Expanding EventLog Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Traceability and Field Debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Scalability and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Figure 1

How Project Lasso Works 1. Windows Services Control Module starts 2. Read configuration from lasso.ini 3. Read hosts from hostlist.ini

LogLogic Appliance

9. Expand EventLogs into readable form

Lasso Windows Host

10. Send expanded EventLogs to appliance

Windows Event Collector (Project Lasso) Guide

4. Start monitoring (multi-threaded) 5. Test connectivity 6. Locate String Resource DLL files

Monitored Windows System 7. Copy DLLs to Lasso Repository 8. Collect new events from monitored EventLogs

31

Agent and Collector Modes

Agent and Collector Modes Project Lasso can be installed in two operational modes: Agent mode - Project Lasso collects and forwards messages from the system on which it is installed.

Use agent mode if you only need logs from the system on which Project Lasso is installed.

Collector mode - Project Lasso collects and forwards messages from systems other than the system on which it is installed.

Use collector mode if you need one system to gather logs from multiple other systems.

Project Lasso can also run in both agent and collector modes at the same time. This hybrid mode has the system on which Project Lasso is installed collect and forward messages both from itself and multiple other systems.

The mode Project Lasso runs in is simply set based on the log sources designated in the .ini files while configuring Project lasso.

Windows Services Control Module When running Project Lasso in collector mode, the Windows Services Control Module starts the Project Lasso service. Project Lasso is usually configured to auto-start when the system is started and to auto-restart when a process failure occurs.

The Project Lasso Service runs under a Domain User ID on the Windows host and, for remote access to the Windows Security Event Log and other protected resources, requires certain permissions in the Domain and/or on each monitored host.

Configuration Parameters in the Lasso.ini File Project Lasso reads its configuration parameters from the Lasso.ini file. This file, in the installation directory on the Project Lasso Host, contains about 20 parameters that specify various Project Lasso behaviors including where it should send collected event logs, the polling interval for log collection, and various resources, protocols, and time outs.

Many of these parameters are set during installation, using InstallShield. The Lasso.ini file is a simple CSV (comma-separated values) file, so you can edit the parameter values after installation with a text editor or Microsoft Excel. Many of the parameters can be edited during Project Lasso execution; such edits are re-read on each polling cycle.

32

Windows Event Collector (Project Lasso) Guide

CHAPTER 4

How Project Lasso Works

Target Hosts Monitored Using the hostlist.ini File The hostlist.ini file, also in the installation directory on the Project Lasso Host, details which target hosts Project Lasso monitors and which EventLogs to monitor on each of those hosts. Target hosts can be identified by NetBIOS name, fully qualified domain name, or IP address. Every host can have a different list of monitored EventLogs. hostlist.ini initially contains only localhost, for agent-style self-monitoring of the Project Lasso Host. However, after installation the file can be edited to add other target hosts. The hostlist.ini file is a simple CSV file, so you can edit long complex lists of hosts and eventlogs with a text editor or Microsoft Excel. Depending on the resources of the Project Lasso Host and total rate of EventLog generation by the monitored hosts, one Project Lasso installation might be able to monitor up to several hundred target hosts. hostlist.ini can be edited during Project Lasso execution. It is not necessary to stop and restart Project Lasso to add new target hosts to the list.

Using Multi-Threading for Parallel Processing Project Lasso starts monitoring hosts using multi-threading for parallel processing. The number of simultaneously running threads is configured in the Lasso.ini file. The recommended value is four times the number of CPUs in the Project Lasso Host.

Because Project Lasso is multi-threaded, it is not always predictable which hosts are being polled at a specific time. Project Lasso typically collects from more than one host at a time.

Testing Connectivity For each monitored host, Project Lasso tests connectivity. Project Lasso first attempts to check whether the target host is available for communication over the network, by sending it an Echo message using TCP port 7.

If the target hosts are running Windows Firewall, port 7 is blocked by default. In this case, to turn off the Echo test add CheckRemHostAvail,0 to Lasso.ini. For more details, see Testing Project Lasso Communication with Monitored Hosts through a Firewall on page 44.

Project Lasso performs the Echo test. If an expected host is not available on the network, Windows networking APIs can take between 30 seconds and 2 minutes to time out.

During this time, one of the Project Lasso threads is blocked and unavailable for other work. Non-response to the Echo test takes only a few seconds. So if you turn off the Echo test, it is important to have a clean hostlist.ini file, without large numbers of unavailable target hosts.

Accessing Registry Entries For each monitored host, Project Lasso attempts to access the Registry entries for each monitored EventLog.

Windows Event Collector (Project Lasso) Guide

33

Locating String Resource DLL Files

This is the first activity that requires Remote Access network privileges. Using Windows RPC APIs, Project Lasso reaches out to each monitored host, and reads certain registry entries associated with each monitored EventLog on those hosts.

If permissions are granted according to Appendix A, Permissions and Security Considerations for Project Lasso, this step occurs silently. If it fails, error events are written to the Application EventLog on the Project Lasso Host.

Locating String Resource DLL Files String Resource DLL files are located for each monitored host.

The Registry entries for each EventLog specify the location of String Resource DLL files.

These are the files needed to convert the original, compressed native form of Windows EventLog messages into the expanded, human-readable form seen in “Event Viewer” and in the LogLogic Appliance reports.

Each EventLog can reference up to three String Resource DLL files. For each DLL file, Project Lasso attempts to transport a copy back to the Project Lasso host. This lets log message expansion occur on the Project Lasso Host, avoiding computational load on the target servers, and providing much higher Project Lasso performance.

These String Resource DLL files contain no customer data. Most are simply standard Microsoft files distributed with the Windows operating system. Application-specific or custom event logs are files distributed and installed with each application by the application vendor.

Building the Project Lasso Repository There are three methods to build the Project Lasso Repository to contain String Resource DLLs. The method you choose depends on the security requirements of your network environment. For more details, see Appendix A, Permissions and Security Considerations for Project Lasso.

IMPORTANT! If you use Project Lasso in “agent” mode, monitoring only the localhost, you install it using the User ID “Local System”. In this case, you do not need any of these three methods.

Everything is handled without administrative effort.

Unless using “agent” mode, you must use one of these three methods. Otherwise, while EventLog collection might be successful, the text of the messages is not human-readable because Project Lasso cannot perform message text expansion from the original compressed format.

The three methods are: Allow the Project Lasso User ID to run with Domain Administrator privileges.

If this method is allowed, Project Lasso has all necessary access to target hosts in the Domain, and the Project Lasso Repository is built and maintained automatically without further effort by the administrator.

34

Windows Event Collector (Project Lasso) Guide

CHAPTER 4

How Project Lasso Works

Manually maintain the Project Lasso Repository on the Project Lasso Host, using periodic Administrator setup.

A Security Administrator can perform a “manual” DLL collection, by logging into the Project Lasso Host using a Domain Administrator user ID, then running Project Lasso from the command line with the -c option: \Lasso-installation-directory-path\lasso.exe -c This causes a manual build of the Project Lasso Repository, performing a one-time collection of all DLL files needed for the hostlist.ini file at the time.

This method requires no special privileges for Project Lasso. However, you must repeat this manual process periodically (LogLogic recommends at least once per month) to track modifications and updates in the DLL files due to Windows and application updates.

When new hosts are added to hostlist.ini, their DLL files are not in the repository until the next manual collection. In the interim, if there are shared DLLs in the Repository, Project Lasso attempts to use the most current DLL file of the same name/usage from all other monitored machines. In most circumstances this lets Project Lasso correctly perform message text expansion for all standard eventlogs.

If a new server is added to hostlist.ini which hosts a custom application EventLog not present on any other monitored host, it might be necessary to run a manual DLL collection immediately to let Project Lasso perform message text expansion on the new custom logs.

Allow non-administrative remote access for the Project Lasso User ID on each target host, including DCOM, WMI, and non-admin Shares.

To let Project Lasso collect DLLs without having Domain Admin privileges, configure a non-administrative “Lasso Share” on each target host. You can configure this: Globally in Lasso.ini (see Setting Run-Time Parameters on page 14) Per-host in hostlist.ini (see Setting Hosts and Event Logs to Monitor on page 11) It is not necessary to manually create the Lasso Share on each target host, although you can. Instead, a Security Administrator logged in with Domain Administrator privileges can run Project Lasso once from the command line with the -c option. At the end of that cycle, Project Lasso has created the Lasso Shares on all target hosts, per the configuration options in Lasso.ini and hostlist.ini.

Thereafter, Project Lasso can run without Domain Admin privileges and can still use the non-administrative Lasso Shares for access to the String Resource DLLs. The Project Lasso Repository is built and maintained automatically without further effort by the administrator. For more information about Lasso Shares, and how they are used see Control DLL Collection and Project Lasso Shares on page 21.

To use this option, Windows requires some complex administrative configuration actions. Some of these actions can be done once via Active Directory Group Policies.

Other actions must be performed on each monitored host. For details, see Collecting DLLs in the Project Lasso Repository on page 41.

Windows Event Collector (Project Lasso) Guide

35

Event Messages from Monitored EventLogs

If the first or third (automated) method is used to build the Project Lasso Repository, Project Lasso periodically refreshes the Repository contents. It checks the size and modification date of each referenced DLL, and compares it to the size and modification date of the corresponding DLL in the Repository. If they differ, the target host was updated, and the new DLL is copied to the Repository.

If the second (manual) method is used, Project Lasso depends on system administrators to keep the Project Lasso Repository current.

Event Messages from Monitored EventLogs For each monitored host, Project Lasso collects new event messages from each monitored EventLog. This requires Remote Access network privileges. Microsoft specifies that remote access to the Security EventLog requires Administrator privileges on the target host. If you run Project Lasso without Domain Administrator privileges, this requirement can be overridden by certain Windows configuration choices, either on the target host or in Active Directory Group Policies. For details, see Appendix A, Permissions and Security Considerations for Project Lasso.

Project Lasso has two configuration parameters that affect how it collects new EventLog messages: HighWaterMarks and NewHostSkipHistorical. Project Lasso stores high-water marks of the last processed events for all monitored EventLogs in a file. Upon implicit restart, such as a system reboot or if Project Lasso goes down, the restart is from the high-water marks per monitored EventLog. They can be used to cause Project Lasso to re-collect all available event messages, or to prevent Project Lasso from collecting old, historical event messages on newly monitored hosts. For details, see Control Event Collection and Spooling on page 18.

Expanding EventLog Messages Collected EventLog messages are expanded to human-readable form and sent to the LogLogic Appliance.

This is a complex process, but independent of the preceding network security issues. All event messages collected by all threads are expanded to human-readable form, then combined into a single syslog-ng stream, and sent to the appliance. There they are archived, parsed, and reported.

36

Windows Event Collector (Project Lasso) Guide

CHAPTER 4

How Project Lasso Works

Traceability and Field Debug Project Lasso has a trace functionality for field debug. Six levels of tracing are supported: None, Error, Warning, Info, Debug, and full Trace.

Trace messages can be written to a trace file or to the Application EventLog on the Lasso Host. These options are controlled by the DebugLevel and LogLevel configuration parameters in Lasso.ini.

Project Lasso can also generate a report of all resource access attempts and results for monitored hosts. This lets you determine whether remote host Registry, String Resource DLLs, and EventLogs are available and accessible to Project Lasso. This is a starting point for fixing Security and Permissions issues. This option is controlled by the AccessReport configuration parameter in Lasso.ini.

For more details, see Error Logging, Tracing, and Access Reporting on page 24.

Scalability and Performance For horizontal scalability, use multiple parallel Project Lasso instances. To avoid duplicate logging, monitor each Windows host with a single Project Lasso instance.

Project Lasso performance can vary widely, depending on several factors: number of hosts and workstations to monitor total number of events generated by all hosts, and per host on average maximum number of events generated by a single host number and size of event logs Project Lasso is monitoring available resources (CPUs, amount of RAM) on the server running Project Lasso effective network bandwidth

Windows Event Collector (Project Lasso) Guide

37

Scalability and Performance

38

Windows Event Collector (Project Lasso) Guide

APPENDIX A

Permissions and Security Considerations for Project Lasso

A PPENDIX A

Permissions and Security Considerations for Project Lasso

Contents Authentication and Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Privileges Required for the Project Lasso User Account . . . . . . . . . . . . . . . . . . . . . . . 40 Collecting DLLs in the Project Lasso Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Authentication and Access In the Windows Operating System, all access privileges are allowed based on the User Name. Before accepting that a user or process has the right to access a computer while using a given User Name, it is authenticated by means of the Password. The authentication process differs depending on whether: access to the computer is local or remote the computer being accessed is a member of a Domain The three main scenarios are: 1. If Project Lasso is running in agent mode, accessing only the localhost, it should use the “Local System� user name.

This is the default when Project Lasso is installed. This user name has no password and, according to Microsoft, cannot be faked or spoofed. It is therefore very secure. It also has local administrative privileges on the localhost, and so has easy access to all information required for EventLog collection.

If this is your situation, you do not need this section.

2. If Project Lasso is performing remote collection, where both the Project Lasso Host and the remote target hosts are all members of a Domain, the remote hosts use Active Directory to authenticate the Project Lasso User Name and Password.

If a hierarchical forest of Domains is in use, the Project Lasso User Name must be defined in the Domain hierarchy at a level where it can be authenticated by all target hosts. Only one Project Lasso User Name can be used per Project Lasso host installation.

Note: Although Project Lasso accesses all remote hosts using the same Domain User Name, nevertheless, that User Name might have different privileges on different remote hosts.

Appropriate privileges must be set so that Project Lasso can work properly on each remote

Windows Event Collector (Project Lasso) Guide

39

Privileges Required for the Project Lasso User Account

host. These privileges are best set globally using Active Directory Group Policies, but can also be set via administrative operations on individual target hosts. See Privileges Required for the Project Lasso User Account.

3. If Project Lasso is performing remote collection from a target host that is not a member of a Domain, Windows provides a different means to establish remote authentication: If the Project Lasso Host is on a Domain, Project Lasso should still use a Domain User Name and password.

If the Project Lasso Host, like the target host, is not on a Domain, Project Lasso can use a Local User Name and password created directly on the Project Lasso Host.

In either case, a local user account using the SAME User Name and password must be created on the target host. When Project Lasso tries to access the non-Domain target host, it passes in its User Name and password from the Project Lasso Host to the target host. If these match a Local User Name and password on the target host, access is allowed.

As above, authentication is a separate issue from privileges. Appropriate privileges for this Local User Name must be set on the target host, so Project Lasso can work properly on the remote host. Since the remote host is not a member of a Domain, these privileges must be set locally via administrative operations directly on individual target hosts.

Privileges Required for the Project Lasso User Account As noted in Configuring Site-Specific Network Details on page 27, all target hosts must enable remote access to RPC and DCOM services, and to the Registry, EventLogs, and at least one Share. Beyond this, however, the Project Lasso User Name must also be privileged to use these services remotely for each target host.

If your site allows running the Project Lasso service with Domain Administrator privileges, everything is simple. Add the Project Lasso User Name to the Domain Administrators Group in Active Directory, and it automatically has all privileges required on all target hosts in the Domain. You can skip the rest of this section.

By the same logic, for remote target hosts that are not on the Domain, the easiest solution is to add the Project Lasso User Name to the Local Administrators Group on each target host.

If you are running Project Lasso in agent mode, collecting logs from only the localhost, it should run under the user name “Local System�. As observed previously, this secure user name has local administrative privileges on the localhost.

If remote log collection must be done without administrative privileges, it becomes much more complex to configure the privileges for the Project Lasso User Name. On each target host the following privileges must be enabled, either globally via Group Policies, or locally on each target host via individual administrative operations: WMI remote access DCOM remote access EventLog remote read access to all EventLogs which you want to monitor 40

Windows Event Collector (Project Lasso) Guide

APPENDIX A

Permissions and Security Considerations for Project Lasso

Registry remote access for read, query, and enumerate, to the following registry subtrees: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment (“windir” key only - provides “%WINDOWS%” path value) HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion (“SystemRoot” key only - provides “%SystemRoot%” path value) HKLM\SYSTEM\CurrentControlSet\Services\EventLog (full sub-tree must be traversable - holds all DLL path information, per EventLog and per Source) By default: Most Windows systems let any authenticated Domain User have remote access to all the above Registry paths and EventLogs, except those related to the Security EventLog. Only administrators are allowed remote access to the Security EventLog and its related Registry entries.

Because the Security event log contains the events of most interest for log management, you must provide a non-default configuration to allow remote access to this part of the Registry and EventLog for the Project Lasso User Name without administrative privileges. Your Security Administrator might be able to help you do the necessary configurations.

Access to the Security event log on Windows XP Pro can be controlled via the Local Security Policy: Local Security Setting > Local Policies > User Rights Assignment > Manage auditing and security log. You can assign a Lasso user with this privilege.

However, this Lasso user gets full control of the security logs, including deleting, resetting, and so on, similar to the local administrator. There is no known way to grant just read-only access.

WMI and DCOM remote access are only used for String Resource DLL collection, so you need not enable them for non-administrative access if you can do either of: Allow Project Lasso to run with administrative privileges Build the DLL Repository manually, using an administrative log-in

Collecting DLLs in the Project Lasso Repository Project Lasso requires building a Project Lasso Repository of String Resource DLLs on the Project Lasso Host. It uses these copies of DLLs to perform string expansion of the event messages into human-readable form. Without these DLLs, event messages are not expanded, and are not correctly parsed or reported in the Log Appliance.

For information about the three methods for building the Project Lasso Repository, see Configuring Site-Specific Network Details on page 27 and Building the Project Lasso Repository on page 34.

Beyond the three methods for building the Repository, there are also three methods for collecting DLLs into the Repository:

Windows Event Collector (Project Lasso) Guide

41

Collecting DLLs in the Project Lasso Repository

Collect all DLLs from every remote host, using Administrative Shares. This is the default collection method, if no other method is configured. This method can be a performance burden for some sites.

Shared DLLs in the Repository, so that DLLs common to multiple hosts can be copied just once, and used by all. With Shared DLLs, DLL collection does not necessarily have to occur for all hosts, as long as at least one instance of each needed DLL is collected from a host (such as only the Project Lasso Host).

Shared DLLs makes the system much more forgiving of failure to collect DLLs from some remote hosts, as long as a comparable DLL is available on the Project Lasso Host or some other host where Project Lasso has privileges to collect DLLs. Application-specific Project Lasso Shares so that collection can take place without administrator privileges and from systems that have Administrative Shares disabled.

Project Lasso Shares are not a panacea. Using them instead of Administrative Shares is simple: specify a DefaultLassoShare in Lasso.ini, or a host-specific Lasso Share name for the hosts you want in hostlist.ini. However, this alone is not sufficient to guarantee non-administrative access to DLLs on a remote host. You must also enable the Project Lasso User Name for DCOM and WMI on each remote host, as specified in Privileges Required for the Project Lasso User Account on page 40.

The easiest way to overcome these limitations is to manually build the Project Lasso Repository using the lasso.exe -c command. Project Lasso Shares work with this command or as required when Administrative Shares are explicitly disabled.

To build, rebuild, or delete the Project Lasso Repository, run lasso.exe with the appropriate option. You can run lasso.exe regardless of whether Project Lasso is configured as a service, though you should run it in this manner only when manually maintaining the Project Lasso Repository (the second method in Building the Project Lasso Repository on page 34).

There are three options when running lasso.exe: Lasso.exe -c Creates the Project Lasso Repository.

Initiates a single collection of DLLs from all monitored hosts in hostlist.ini.

Creates all Project Lasso Shares, if any, specified in Lasso.ini or hostlist.ini.

Lasso.exe -cl Similar to the -c option, but collects DLLs only from the localhost. This is useful to refresh the Shared Repository after a Windows Update.

Lasso.exe -d Deletes any previously created Project Lasso Shares for hosts in hostlist.ini.

Caution: Stop the Project Lasso service before you run lasso.exe -d.

When you run lasso.exe manually, Project Lasso is executed with the privileges of the currently logged-in user account.

42

Windows Event Collector (Project Lasso) Guide

APPENDIX B

TCP/IP and UDP/IP Ports Used by Lasso

A PPENDIX B

TCP/IP and UDP/IP Ports Used by Lasso

Contents Lasso Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Testing Project Lasso Communication with Monitored Hosts through a Firewall . . . . . 44

Lasso Ports Communication between the Lasso host and the LogLogic appliance is via protocol and default port number: "syslog-ng protocol

--

TCP port 514 (default)

The TCP syslog port number is not configurable on the Appliance.

For agent use, when monitoring only the localhost, Project Lasso can be configured in Lasso.ini to communicate with the LogLogic appliance via: "syslog protocol

--

UDP port 514 (default)

The default UDP port number can be modified by configuring it on both the appliance and in Lasso.ini.

All communications between the Lasso host and monitored Windows servers is via Windows SDK API calls and Windows WMI calls. These calls use the following Windows protocols and ports: RPC (for remote registry and eventlog access) -- TCP port 135 SMB (for remote DLL and File System access) -- TCP port 445 Echo (checking TCP/IP connection availability) -- TCP port 7 These services also use dynamically assigned ports numbered above 1024.

The use of Echo on port 7improves performance when servers listed in hostlist.ini become unavailable. Project Lasso fails to download DLLs if port 7 is blocked, and Windows Firewall, among others, blocks Port 7 by default. Echo can be turned off by the Lasso.ini parameter CheckRemHostAvail,0.

The TCP syslog port is not configurable on the Appliance

Windows Event Collector (Project Lasso) Guide

43

Testing Project Lasso Communication with Monitored Hosts through a Firewall

Testing Project Lasso Communication with Monitored Hosts through a Firewall To test whether Lasso works through a firewall: 1. Log in to the Lasso Host using the Lasso User ID and password.

2. Open the Event Viewer.

3. Attempt to connect to the remote host that you intend to monitor, and view its logs.

If you can successfully view the remote logs using Event Viewer, it is highly probable that Lasso event collection will work fine.

To check DLL file collection, try to open the remote host's Admin Shares or, if configured, the DefaultLassoShare or other LassoShare path configured for the particular target host in hostlist.ini, using the following steps.

First, discover the Admin Shares available on the target host. (If you are using non-Administrative Shares, skip these three steps.)

4. Open the “Computer Management” MMC. 5. Connect to the remote host, and view its shares.

6. Confirm that you can view the Admin Shares (C$, E$, etc.), and which ones exist on that host.

Now see if you can mount and browse the shares.

7. Open the “Start : Run…” window on the Lasso host.

8. In the “Run…” window, type \\remotehostname\AdminShareName\ or \\remotehostname\LassoShareName\ and confirm that you can mount and browse the specified share from that host.

If both Step 3 and Step 8 work, Lasso should have no difficulty. If either fails, you have an easier environment than Lasso for tracking down the networking and/or permissions issues and changing them. The port numbers mentioned above will be helpful if you need to drill a hole in the firewall, but start with the high-level tools.

This procedure does not test Echo on port 7. If the target hosts are running Windows Firewall, port 7 is blocked by default. If the above works but DLL collection is not taking place for any host except localhost, try turning off Echo on port 7 by adding CheckRemHostAvail,0 to Lasso.ini. For more information, see CheckRemHostAvail on page 16.

44

Windows Event Collector (Project Lasso) Guide