John, thank you very much! Your solution of course better because, I
think, it's very dangerous to practice fusion scripting on production
DCs.
May be this is interesting for someone, here is how I've manually
changed policy to get desired result:

[\Advanced\Rules\EventLog Rules\Logon_with_admin_privileges\];
CheckDescription        =S      User with administrative privileges
logged in;
Enabled =B      1;
Priority        =L      3;
IgnoreCase0     =B      1;
RegExp0 =S      (\$$)|(NETWORK SERVICE)|(LOCAL SERVICE)|(ANONYMOUS
LOGON);
Except0 =B      1;
[\Advanced\Rules\EventLog Rules\Logon_with_admin_privileges\Response\];
[\Advanced\Rules\EventLog
Rules\Logon_with_admin_privileges\Response\BANNER\];
Enabled =B      0;
[\Advanced\Rules\EventLog
Rules\Logon_with_admin_privileges\Response\BLOCK\];
Enabled =B      0;
[\Advanced\Rules\EventLog
Rules\Logon_with_admin_privileges\Response\DISPLAY\];
Choice  =S      Default;
[\Advanced\Rules\EventLog
Rules\Logon_with_admin_privileges\Response\LOGDB\];
Choice  =S      LogWithoutRaw;
[\Advanced\Rules\EventLog
Rules\Logon_with_admin_privileges\Response\RSKILL\];
Enabled =B      0;


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

> -----Original Message-----
> From: John Zeigler [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, October 19, 2005 11:37 PM
> To: Soldatov, Sergey V.; [EMAIL PROTECTED]
> Subject: RE: [ISSForum] Logon_with_admin_privileges on Server Sensor
> 
> 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|SeR
> emoteShutd
> ownName|SeAuditPrivilege|SeDebugPrivilege|SeLoadDriverPrivileg
> e|SeSecuri
> tyPrivilege|SeSystemEnvironmentPrivilege|SeTakeOwnershipPrivil
> ege|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