Ultimate Windows Security Tip #4

In this issue:
- Newsletter Enhancement: Free Logparser Script
- Upcoming Public Courses
- Tip #4: Implement first level host defenses with logon rights
- Logparser: Report user logons and computers subsequently accessed

=============================================
Newsletter Enhancement: Free Logparser Script
=============================================
Everyone is crazy about the ever more powerful logparser utility from
Microsoft that allows you to query any log using simple, familiar SQL SELECT
queries.  Starting now I'm including a new logparser script in every issue
of this newsletter.  Each script will show you how to exploit logparser's
power as well as shed light on the cryptic Windows security log. 

=======================
Upcoming Public Courses
=======================
http://www.ultimatewindowssecurity.com/register.asp
Security Log Secrets
- Seattle, July 11, 12
Complete Windows Security
- Atlanta, July 18-22
(Read on below to see how you can save $100 on this course.)

=============================================================
Tip #4: Implement first level host defenses with logon rights
=============================================================
Logon rights are a great way to implement very broad, first level defenses
on Windows servers. Logon rights control how an account can gain access to a
system.  Even if an attacker knows or guesses the password of an account or
if an account inadvertently gains inappropriately high permissions to
critical objects on a server, if the account lacks the proper logon right
the attacker won't be able to exploit the situation.  You can find Windows'
logon rights in group policy objects under Computer Configuration\Windows
Settings\Security Settings\Local Policies\User Right Assignments.  The logon
rights are mixed in with Windows' other user rights.  There's a
corresponding logon right for each logon type.  When you logon at the
keyboard and screen (i.e. the console) of a computer, your account must
possess the "logon locally" right.  Technically Microsoft should have named
this right "Allow interactive logon" because every where else in Windows,
Microsoft uses the term interactive for this type of logon.  When you access
a Windows resource over the network, such as a shared folder or any other
resource that you can access through Computer Management or that is provided
by the Server, Remote Registry or RPC services, Windows requires you to have
the "Access this computer from the network right".  Any account used by a
service, such as an SQLServer account created for the Microsoft SQL Server
service, must possess the "logon as a service" right and any account used by
Scheduled Tasks requires the "Logon as a batch job" right.  Finally, Windows
XP and Windows Server 2003 introduce the "allow logon through Terminal
Services" right which is required in order to open a remote desktop
session.  (Windows 2000 requires you to have the logon locally right as well
as the appropriate permission to the RDP connection object in the Terminal
Services Configuration MMC snap-in.)  If you use some imagination you can
use the rights to easily implement some powerful controls and added layers
of defense. 

For instance you can use "access this computer from the network" right to
implement broad restrictions on who can touch computers remotely.  This is
particularly useful for blocking attackers from exploiting insecure local
accounts on member servers throughout your domain.  In my audits I
frequently find critical member servers with highly privileged local
accounts that have been forgotten and have a weak password or none at all. 
You can easily implement a policy at the domain or organizational unit that
eliminates this vulnerability on all your member servers.  Simply assign the
"access this computer from the network" user right to the Domain Users group
from each domain that should be allowed to access the server. 

You can also use the "access this computer from the network" right to
protect workstations from remote attacks.  To support remote administration
and management by Systems Management Server (SMS) most companies find it
necessary to leave the Server service enabled on workstations, but doing so
greatly increases the workstations' vulnerability to other malicious
individuals on the network or to worms.  This is especially true since the
default assignment for "access this computer from the network" is Everyone. 
For workstations I recommend a group policy that limits this right to Domain
Admins, workstation support groups and the account under which your SMS
server runs if applicable.  That way authorized accounts can still access
the workstations remotely for legitimate reasons but everyone else -
including local SAM - accounts are blocked at the front door of the
workstation.

========================================
Save $100 if you register before June 18
========================================
Join me in Atlanta beginning July 18 for my 5-day, in-depth Complete Windows
Security course.  We will explore every area of Windows and Active Directory
security in detail.  Going far beyond the basics we will cover wireless
security, Certificate Services, IPSec, Encrypting File System, VPNs and
more.  To save $100 pre-register now and then request approval from your
employer; if you are unable to obtain approval you can cancel your
pre-registration without any obligation. http://www.ultimatewindowssecurity.com/register.asp

=================================================================
Logparser: Report user logons and computers subsequently accessed
=================================================================
This log parser script analyzes all the Kerberos authentication events in
your domain controller security logs and reports each workstation where the
user logged on and then the computers he or she subsequently accessed.  To
customize this script to your environment you'll need to replace my list of
domain controllers ('MTG1';'MTG2','MTG3') with your list in 2 different
places in the script - first in the FROM clause and then in the WHERE
clause.  Note that this script filters out logons at the domain controller
itself by administrators.  If you want those logons included just delete
'127.0.0.1'; from the WHERE clause.  The script also omits anonymous IIS
logons by filtering out user names beginning with IUSR.  Note that I've
added line breaks and indentation to improve readability; before using this
script you must reformat it into a single line.
logparser "SELECT distinct
     TO_STRING(TimeGenerated, 'yyyy-MM-dd hh:mm') as DateTime,
     EventID,
     case EventID
          when 672 then '*** Initial Logon'
          when 673 then '    Computer Accessed' end as Event,       
     EXTRACT_PREFIX(TO_LOWERCASE(EXTRACT_TOKEN(Strings,0,`|')),0,'@')
as User,
     case EventID
          when 672 then EXTRACT_TOKEN(Strings,9,'|')
          when 673 then REPLACE_CHR(EXTRACT_TOKEN(Strings,2,`|'),'$','') end
as Computer
FROM \\mtg1\security, \\mtg2\security, \\mtg3\security,
WHERE (EventID in  (672;673))
     and (User not like '%$%')
     and (Computer not like 'krbtgt%')
     and (Computer not in ('';'127.0.0.1';'MTG1';'MTG2';'MTG3'))
     and (User not like 'IUSR%')
ORDER BY DateTime, User, EventID"

Here's a sample of the scripts output:

DateTime         EventID Event                 User      Computer
---------------- ------- --------------------- --------- -----------
2005-05-31 21:18 672     *** Initial Logon     rsmith    10.42.42.19
2005-05-31 21:18 673         Computer Accessed rsmith    TABLET2
2005-05-31 21:19 673         Computer Accessed bozo      SINGULARITY
2005-05-31 22:30 672     *** Initial Logon     batchwork 10.42.42.4
2005-05-31 22:30 673         Computer Accessed batchwork M1
2005-05-31 23:00 672     *** Initial Logon     batchwork 10.42.42.4
2005-05-31 23:00 673         Computer Accessed batchwork M1
2005-06-01 00:21 672     *** Initial Logon     rsmith    10.42.42.20
2005-06-01 02:31 672     *** Initial Logon     rsmith    10.42.42.20
2005-06-01 05:51 673         Computer Accessed rsmith    M1
2005-06-01 05:53 672     *** Initial Logon     rsmith    10.42.42.4
2005-06-01 05:53 673         Computer Accessed rsmith    M1
2005-06-01 07:01 672     *** Initial Logon     csmith    10.42.42.27
2005-06-01 07:27 673         Computer Accessed bozo      SINGULARITY
2005-06-01 11:18 672     *** Initial Logon     csmith    10.42.42.27
2005-06-01 11:18 673         Computer Accessed csmith    S120
2005-06-01 11:50 673         Computer Accessed csmith    QBVM

Each event ID 672 produces an "Initial Logon" record with the IP address of
the workstation where the user logged on.  Event ID 673s list the computers
subsequently accessed.  Note that you will occasionally see 673s of other
users interspersed throughout the report resulting from users accessing an
additional computer sometime after their initial logon.  All in all, the
script works pretty.

If you would like to understand the "nitty gritty" details of the security
log and log parser please join us in Seattle on July 11.  Seats are filling
up. To register or for more information please email
info@ultimatewindowssecurity.com or visit http://www.ultimatewindowssecurity.com/register.asp.

Regards,
Randy Franklin Smith
CISA, SSCP, Microsoft Security MVP
CEO, Monterey Technology Group, Inc.

============================================
Subscribe, Unsubscribe and Usage Information
============================================
- subscribe to this newsletter
- unsubscribe from this newsletter
- usage information
If you've received this message as a forward from a friend, or are reading
it online in the archives, you can sign up for your own newsletter
subscription.

Also, if you want to unsubscribe, you can do that too (but we'll be sad to
see you go).

You can use this information as you see fit, but if you're going to copy any
portion, please FORWARD THE ENTIRE email.

While Monterey Technology Group, Inc. tries to ensure that all information
is technically accurate, we make no warranty with regard to the information
within. Please use at your own risk.

If you need personalized attention in any way, just email me:
mailto:rsmith@montereytechgroup.com. I endeavor to respond to everyone who
emails.

Thanks for reading!

List address: MonthlySecurityTip@ultimatewindowssecurity.com
Subscribe: MonthlySecurityTip-subscribe@ultimatewindowssecurity.com
Unsubscribe: MonthlySecurityTip-unsubscribe@ultimatewindowssecurity.com