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
Preface
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:
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.
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
C HAPTER 1
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.
A text editor, such as NotePad or WordPad, to edit the .csv configuration files.
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.
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.
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.
C HAPTER 2
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)
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.
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.
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.
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.
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\
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.
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.
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
LogAppliance,192.168.22.199,1514
LogAppliance,LLAUSTIN,1514
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.
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
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
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
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.
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:
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.
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
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.
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.
The value is not reloadable. The value is read only during Project Lasso startup.
Example
SpoolFileSize,10.0
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).
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.
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)
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.
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.
DebugLevel
(Optional) Enables Project Lasso to write messages into a trace file (LassoTrace.log, in
the Project Lasso program installation folder).
DebugLevel,value
Examples
To disable Trace:
DebugLevel,0
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.
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
Default is 0.
AccessReportFileSize
(Optional) Controls the maximum size, in MB, of LassoAccessReport.log until the
output wraps around to the beginning of the file.
AccessReportFileSize,value
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.
C HAPTER 3
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.
C HAPTER 4
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
Testing Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Lasso Monitored
LogLogic
Windows Windows
Appliance 9. Expand EventLogs Host System
into readable form
7. Copy DLLs to Lasso Repository
10. Send expanded EventLogs 8. Collect new events from
to appliance monitored EventLogs
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
A PPENDIX A
Contents
Authentication and Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
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
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.
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
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
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:
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).
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.
A PPENDIX B
Contents
Lasso Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
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)
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.
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.