Ultimate Windows Security Newsletter:

Issue #4, 06/01/05

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 script's 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 VIP
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!