This information assumes that the Server Sensor you are asking about is
running on a Windows machine.  The information should be similar for
other operating systems, but I only have experience on Windows Based
Server Sensors.

This is a long answer as I am also attempting to describe the behavior
of the sensor, signature definitions, vaguely documented event
exceptions, and a tiny bit about Regular Expressions and TCL Validation
scripts.

To see how ISS defines a signature, look in the RuleDef_Win_???.policy
where ??? is 2K or NT4 depending on the Windows Version the Server
Sensor is running on.  The 2K version of this file is used on Server
2003 and 2000.  This file is located in the server sensor directory and
should be used for reference only.  Do not modify this particular file.

The Logon_with_admin_privileges signature is defined by ISS in the
RuleDef_Win_2K.policy file as follows ...

------------------------------------------------------------------------
--

[\Advanced\Rules\EventLog Rules\Logon_with_admin_privileges\];
Alert Type      =S      AdminNormalActivity;
Risk Level      =L      3;
Log Type        =S      Event Log;
Event Log Source        =S      Security;
Event Log SourceName    =S      Security;
Event Log Type  =L      0;
Event Log Category      =L      0;
Event Log ID    =L      576;
Regular Expression      =S
SeBackupPrivilege|SeRestorePrivilege|SeSystemtimePrivilege|SeRemoteShutd
ownName|SeAuditPrivilege|SeDebugPrivilege|SeLoadDriverPrivilege|SeSecuri
tyPrivilege|SeSystemEnvironmentPrivilege|SeTakeOwnershipPrivilege|SeProf
SingleProcess|SeSystemProfilePrivilege|SeCreatePermanentPrivilege;
[\Advanced\Rules\EventLog Rules\Logon_with_admin_privileges\Audit\];
[\Advanced\Rules\EventLog
Rules\Logon_with_admin_privileges\Audit\Global\];
User Rights     =S      Success;
[\Advanced\Rules\EventLog Rules\Logon_with_admin_privileges\Info\];
User    =S      @String0;
User's Domain   =S      @String1;
Privileges      =S      @String3;
Purpose =S      NT Admin;

------------------------------------------------------------------------
---

This signature looks for event ID 576 from the Operating System
"Security" event log and reports any event that includes any of the text
included in the list defined by the Regular Expression shown above.  The
pipe character "|" represents or.  So This|That in a regular expression
means to look for This "or" That.

This signature uses the following information from the event to populate
the event data.  The first line of data in the OS event is String0 while
the second line of data is String1 etc.

User is pulled from String0  
User's Domain is pulled from String1
Privileges are pulled from String3
Purpose is always set to the text "NT Admin"
User Rights is always set to the text "Success"

Given this information, you can now create an "Exception" for this
particular signature.

Note:  The following is documented in the "Customizing Real Secure
Server Sensor" guide starting on Pg 31, but is fairly vague and takes
experimentation to figure out how all of this works.  (from pg 31 "The
only way to create these exceptions is to hand edit the policy file.")
Export your selected policy file, rename the file, then hand edit it.
After editing the file, import it again and a new policy will be created
with the same name as the file, so it is important to rename the file
first to prevent overwriting your current policy.

In the policy file that was just exported, search for the signature
definition.  For this particular signature, you will need to add three
lines to the start of the signature definition within the section ...

[\Advanced\Rules\EventLog Rules\Logon_with_admin_privileges\];

You will need to add these settings ...

IgnoreCase#
RegExp#
Except#

While the expected syntax is as follows ...

IgnoreCase#     =B      1; - Case insensitive comparison
or
IgnoreCase#     =B      0; - Case sensitive comparison

RegExp# =S      (Desired text to filter out)|(Or this text)|(ETC)

Except# =B      1; - Create an exception for the above.
or
Except# =B      0; - Include the values above

The # symbol is to be replaced by the String number the exception is to
look at.  By the signature definition copied far above, the User field
comes from string 0, so you would replace the # symbol with 0.

Let's say that your server naming convention is the word "Server"
followed by a two digit number, plus your domain controllers are named
"DC" followed by a one digit number, and you have one rogue system with
the name "Rogue".  Remember that the computer account names include a $
symbol at the end of the account name, the three lines you would want to
add to the signature definition in the policy file would be as follows
...

IgnoreCase0     =B      1;
RegExp0 =S      (Server[0-9][0-9]\$)|(DC[0-9]\$)|(Rogue\$);
Except0 =B      1;

There are more elegant ways to write the Regular Expression above, but
this is to illustrate how an exception can be written for an Event Log
signature.  The $ symbol is a special symbol in Regular Expressions so
it must be escaped by the \ character if you are looking for the "$"
symbol in the text.  The parenthesis () do not have to be included, but
I like to have them to make the definition more explicit.  The pipe |
symbol represents an "or" statement.  The [0-9] represents any single
numeric character between 0 and 9.  So a computer name of Server01 would
have an account name of Server01$ and would be included in the exception
above.  The interesting thing about Regular Expressions, a name of
MyServer01, ToBeARogue, or PDC1 would all be included in the exception
because one of the above text strings would be found within the computer
account name.

This concept can be used to create all kinds of exceptions.  I use it to
filter out known processes such as a virus scanner which occasionally
makes thousands of calls per minute to specific registry entries with
the write flag set but is only reading the key.  In this case, TCL
Validation scripts are not fast enough to catch the events during the
brief period of time that the event is occurring while an exception is
checked BEFORE any TCL code is executed for the event and is able to
filter out events MUCH faster than TCL scripts.

I hope this helps, and should save you a day of consulting fees.

John R. Zeigler

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Soldatov, Sergey V.
Sent: Wednesday, October 19, 2005 12:44 AM
To: [EMAIL PROTECTED]
Subject: [ISSForum] Logon_with_admin_privileges on Server Sensor

Hi list.
I've submitted enhancements request containing the following:
Logon_with_admin_privileges signature is VERY useful, but now it can't
be used, because it's triggered for system accounts (machine_name$) as
well. In many cases it's this event is not interesting for system
accounts, but  they can't be filtered because SS can't filter events. I
understand that to teaching SS to filter events is may needs great
development, so I propose to make to different signatures for USER
accounts logons with admin privileges and for SYSTEM accounts logon.
Now because of VERY great number of Logon_with_admin_privileges (so it's
impossible to find something in that events) I have to switch it off.

And receive a very interesting answer - that I have to create validation
script on TCL... and if I can't do this by myself ISS could provide me
with the script at the price of one day consulting. Thinking in this way
we can make a conclusion that because EVERY Windows eventlog event and
EVERY text log event can be made by hands, there is no necessity for ISS
to provide these events at all :-)

So, dear list, maybe someone already solved described problem and
already has such validation script for server sensor?

Thank you.

---
Best regards, Sergey V. Soldatov.
Information security department.
tel/fax +7 095 745 89 50 
tel +7 095 777 77 07 (1613)


_______________________________________________
ISSForum mailing list
[email protected]

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo/issforum

To contact the ISSForum Moderator, send email to [EMAIL PROTECTED]

The ISSForum mailing list is hosted and managed by Internet Security
Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.

---------------------
This email has been scanned for viruses.
****************************************************************************This
 e-mail and any files transmitted with it are confidential and are intended 
solely for the use of the individual or entity to whom it is addressed. If you 
are not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, be advised that you have received this e-mail 
in error, and that any use, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender at Merrick Bank and delete it from your 
computer. Although Merrick Bank attempts to sweep e-mail and attachments for 
viruses, it does not guarantee that either are virus-free and accepts no 
liability for any damage sustained as a result of viruses.



_______________________________________________
ISSForum mailing list
[email protected]

TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to 
https://atla-mm1.iss.net/mailman/listinfo/issforum

To contact the ISSForum Moderator, send email to [EMAIL PROTECTED]

The ISSForum mailing list is hosted and managed by Internet Security Systems, 
6303 Barfield Road, Atlanta, Georgia, USA 30328.

Reply via email to