Thor's Microsoft Security Bible: A Collection of Practical Security Techniques

Thor's Microsoft Security Bible: A Collection of Practical Security Techniques

by Timothy "Thor" Mullen
     
 

View All Available Formats & Editions

Thor’s Microsoft® Security Bible provides a "one-stop-shop" for Microsoft-related security techniques and procedures as applied to the typical deployment of a Microsoft-based infrastructure. The book contains detailed security concepts and methodologies described at every level: Server, Client, Organizational Structure, Platform-specific

Overview

Thor’s Microsoft® Security Bible provides a "one-stop-shop" for Microsoft-related security techniques and procedures as applied to the typical deployment of a Microsoft-based infrastructure. The book contains detailed security concepts and methodologies described at every level: Server, Client, Organizational Structure, Platform-specific security options, application specific security (IIS, SQL, Active Directory, etc.) and also includes new, never-before-published security tools complete with source code.



  • Named the 2011 Best Systems Administration Book by InfoSec Reviews
  • Detailed technical information on security processes for all major Microsoft applications
  • Unique project-based "storytelling" delivery, combining multiple security techniques and methods together for real-world solutions to security challenges in actual business use cases
  • Reference-style content for access to specific application security techniques and methods
  • Actual author opinion and guidance as not only HOW to go about security particular applications, but WHY to do so
  • DVD Companion disk with source code, tools, video tutorials, and other materials

Editorial Reviews

From the Publisher
"Most recognize Thor as the Norse god of thunder with massive powers of destruction. Few realize that he was also the god of restoration. Likewise, his namesake, Timothy "Thor" Mullen, has spent his entire adult life both destroying and restoring Microsoft-based security systems.Thor'sMicrosoft Security Bible conveys the wisdom and expertise of the industry legend that has defined the bleeding edge of Microsoft security for over twenty years. I highly recommend this book."

-Johnny Long, Hacker at Large Author of the best-selling "Google Hacking" series

Product Details

ISBN-13:
9781597495738
Publisher:
Elsevier Science
Publication date:
07/16/2011
Sold by:
Barnes & Noble
Format:
NOOK Book
Pages:
336
File size:
12 MB
Note:
This product may take a few minutes to download.

Read an Excerpt

Thor's Microsoft Security Bible

A Collection of Practical Security Techniques
By Timothy "Thor" Mullen

SYNGRESS

Copyright © 201 Elsevier Inc.
All right reserved.

ISBN: 978-1-59749-573-8


Chapter One

Securely Writing Web Proxy Log Data to SQL Server and Programmatically Monitoring Web Traffic Data in Order to Automatically Inject Allow/Deny Rules into TMG

INFORMATION IN THIS CHAPTER:

* Implementation

* Securely Logging Data to SQL

* Designing the Workflow

* Execution

PRODUCTS, TOOLS, AND METHODS:

* Active Directory (AD)

* MS SQL Server

* Internet Security and Acceleration (ISA) Server/TMG Windows Firewall with Advanced Security

* TMG Logging to SQL Server

* Least Privilege Service User

* SQL Common Language Runtime (CLR) to Replace xp_cmdshell

* AD Permissions Delegation

* Organizational Units

* TMG Deny Rules

* Computer Certificates

* AppLocker

INTRODUCTION

The purpose of this process example is to securely combine the logging features of Microsoft's Threat Management Gateway (TMG) with the power of SQL Server to monitor user traffic with the goal of determining if the user has violated corporate (or other) web browsing policies by way of checking the destination uniform resource identifier (URI) called by the browser against a blacklist of predetermined sites. We will then block that user using dynamically managed AD group membership in an automated fashion. These techniques can also be applied to different scenarios, so take note of those that you can port over to other applications and configurations.

In this example, we will configure TMG to log web proxy data to a SQL database using integrated machine credentials and then create a SQL job to monitor entries in the log in order to trigger an event where the SQL service will update user group information for an AD global group that has been preconfigured as the target of a DENY rule in TMG.

In other words, SQL will monitor the TMG logs practically in near-real-time and look for destination sites in the logs that match a list of admin-defined blacklisted sites. When it finds a user that has broken a policy (for example, visiting ESPN during work hours), it will automatically execute a command to add that user to a global group that has been denied outbound access in TMG. When the rule is matched, rather than the default TMG access error page, the user will be redirected to an internal web page where they will be greeted by Quake Arena's DENIED.wav file and a spinning skull graphic telling him that he is a loser, to pack his things, and to report to the front desk. I have actually deployed this method into a production environment at a corporation I worked for previously, and the results were well worth the issues it created with Human Resources. You, of course, will have to make that determination on your own.

At each step, we will be consciously aware of what process environment we can create using security in depth and using least privilege where possible. While these illustrations are just examples of the integration possibilities available, I will try to make each as complete as possible insofar as working code is concerned. When I present ideas, they are complete, tested, and operational—unlike security by theory, which is not worth the HTML it is written in. As always, these processes can be applied to a multitude of different security processes with varied end results.

SCOPE AND CONSIDERATIONS

I have seen many SQL environments where scheduled jobs would run as administrator and drop down to the command interpreter via the ever popular xp_cmdshell extended system stored procedure in order to interact directly with the operating system (OS) or file system. Years back, there were not many reliable solutions for doing this other than xp_cmdshell, and people were not as worried about security then as we are now. For similar solutions, I would typically see SQL set up for mixed mode authentication, using a database source name (DSN) on the TMG box to connect to the SQL server with stored credentials that post log records, and with the SQL Server service running in a privileged context so it could directly alter group membership in AD and do something like execute a net user command via the previously mentioned xp_cmdshell.

There are consequences to this type of configuration when it creates a vulnerability that allows an attacker to execute code in the context of the service account, or when SQL injection vectors allow for attacker-defined scripts to be injected into the SQL code. If xp_cmdshell was enabled, injecting Transact-SQL (T-SQL) in order to drop down to the command (cmd) prompt and add users to the local administrators group was trivial. It was also easy to build cmd scripts one line at a time with echo ftp > getit. cmd in order to begin building an ftp connection script, and then continuing on with echo open >> getit.cmd and so on so you could execute the connection script and have the server download your favorite toolset. Afterward, you could execute server-side tools so you could make direct connections to it, steal data, and so on. You can see how dangerous this can be, and though xp_cmdshell is disabled by default on SQL Server now, people still leverage the power of xp_cmdshell to do their dirty work. We will not be doing that, of course. We will actually walk through three progressive examples of bad, better, and even better so that the benefits of our final method, SQL CLR, are clearly illustrated.

Secure Process Prerequisites

This exercise has two prerequisites. We first need the SQL Server service running as least privileged user as discussed in Chapter 5, "The Creation and Maintenance of Low Privileged Service Users." To summarize the takeaways from that chapter, our MSSQLSERVICE service should be running as a domain user (HAMMEROFGOD\SQLUser), which is in turn a member of the HAMMEROFGOD\gServiceUsers global group. This user/group has no rights other than those granted during the assignment of the user during the installation of SQL Server. More specifically, the user is not part of any other built-in group, and has explicitly been removed from the default domain users group. As also discussed in Chapter 5, Windows Authentication (or Integrated Windows Authentication) will be used because of its inherited security benefits like account lockout and password complexity enforcement.

Secondly, in order for TMG to properly log the name of the Windows user in the web proxy log, we must ensure that our outbound Internet access rule requires authentication. All browser requests, even when a proxy is configured, are initially made in the context of an anonymous user. If the access rule for TMG's outbound Internet access is configured to allow all users, then the anonymous request will succeed, the access will be granted, and the log file will look something like (snipped):

ClientIP ClientUserName DestHost DestHostIP 3232235829 anonymous www.bing.com 3232235786

Notice that the client username is anonymous, as you would expect from an all-users TMG rule. Note also that the client IP and destination host IP are notated in long integer format. This is normal, and I will show you how to write a scalar function for easy conversion to dot-decimal notation in Chapter 3, "Analyzing and Blocking Malicious Traffic Based on Geolocation." Figure 1.1 illustrates what your TMG rule should look like. You can, of course, base the authentication on any other local or domain-based grouping. As long as you do not allow all users, TMG will force authentication for the rule.

It is important to understand that this does not change the default behavior of your browser. Internet Explorer (IE), for example, will still continue to attempt an anonymous connection initially. TMG will deny this request and challenge IE for credentials, which it will then provide to TMG either by integrated authentication or by displaying a credential logon dialog (depending on how you have configured your browser and domain). Your log will now look something like this:

ClientIP ClientUserName DestHost DestHostIP 3232235829 anonymous www.bing.com 3232235786 3232235829 HAMMEROFGOD\thor www.bing.com 3232235786

For purposes of reporting, you can either delete the log entries for the anonymous users in the database itself, simply remove them from your query criteria, or not include them in the first place, whichever works best for your environment. I personally delete the anonymous requests records because I require authentication for all web access in my environment and am not concerned with the attempts. This may not work in your environment, or you might find that parsing source client data (browser types, for example) is helpful in weeding out rogue access attempts on your network.

IMPLEMENTATION

Assuming the preceding prerequisites are met, we will continue with the process. Since we will be blocking all attempts for external access based on group membership, we need to create a target global group to act as a container to move users into and out of when we deny them access and subsequently reenable access—after they have been sufficiently pummeled and ridiculed by the IT staff in the parking lot.

The important point here is that for our autonomous traffic analysis system to work, the SQL Server database engine (specifically the SQL Server Agent in this case) will have to perform the group membership assignment transaction itself. This will be executed within the context of our HAMMEROFGOD \SQLUser account since the SQL Server Agent runs under that context. In our example, a scheduled SQL job will be doing the heavy lifting. While we could certainly execute the job in an escalated privileged account context, that would be lazy and potentially dangerous because the process could be hijacked to perform other functions. We will, of course, have a structure in place to minimize any potential attack of that sort (defense in depth), but we should minimize such opportunities for attack whenever possible. We will use delegation control in AD to specifically grant the SQL user the rights to read members and write members to the organizational unit containing the global group that will contain the denied user membership. Since you delegate control at the organizational unit (OU) level as opposed to the group specifically, we will need to create the OU, and then create the group within that OU where we ultimately want the delegated control target to have membership management capabilities. Figure 1.2 shows the organizational attributes suggested.

Delegating Rights to Users

The aSpecial Use organizational unit was created, and then the gDeniedLittleBeotch global group was created within it. At this point, the gDeniedLittleBeotch group has no members, which is fine. While we are here, we will take advantage of the previously mentioned and very powerful aspect of AD called delegation of control. We will delegate control of this OU to the HAMMEROFGOD\SQLUser account, allowing it to manage group membership, and only group membership, of the aSpecial Use OU.

Right-click the OU and select Delegate Control to bring up a wizard that we can use to easily set the rights we want imposed on the selected OU to the users we choose. As seen in Figure 1.3, the selection we want is Modify the membership of a group so that the SQLUser account can manage group membership of objects contained in the aSpecial Use OU. Once this is selected, SQLUser will be able to add members to, and remove members from, the gDeniedLittleBeotch group (and any other groups that we put into the aSpecial Use OU).

This selection in the wizard will write two specific permissions to the OU, which you can view, as shown in Figure 1.4, by opening the security properties of the OU and selecting Advanced.

The read members and write members permissions are the true resultant permissions applied to the OU for the selected group or user. You could have also simply selected the OU's permissions and manually applied the Read and Write options for the SQL user, but the wizard makes it easier.

(Continues...)



Excerpted from Thor's Microsoft Security Bible by Timothy "Thor" Mullen Copyright © 201 by Elsevier Inc.. Excerpted by permission of SYNGRESS. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Meet the Author

Timothy “Thor” Mullen is an independent programming consultant who, after 25 years of supporting Microsoft operating systems and programming languages, has completely abandoned all Microsoft technologies in favor of Apple OS X and open source systems such as Linux and BSD.

After years working for the software giant, Thor now condemns the company for their unethical practices and evangelizes for Apple OS X and open systems and has committed his research to the betterment of users by providing guidance for users to switch from their dependency upon Windows and enjoy the superior, secure, and feature-rich experience that is OS X.

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >