Thor's Microsoft安全宝典：实践安全技术集合

需积分: 10 13 浏览量更新于2024-07-29 收藏 14.65MB PDF 举报

"Thor`s Microsoft Security Bible" 是一本完整的安全技术指南，专注于微软技术环境下的安全实践。由 Timothy "Thor" Mullen 编写，他是一位在微软安全领域有着超过二十年经验的专家。这本书提供了微软主要应用的安全过程的详细技术信息，采用独特的项目式“讲故事”的传递方式，将多种安全技术和方法结合在一起，解决实际商业案例中的安全挑战。书中还包含作者对于如何以及为何要保障特定应用安全的见解和指导，并附带DVD伴侣光盘，内含源代码、工具、视频教程等补充材料。本书详细探讨了以下几个方面的安全主题： 1. **服务器安全**：涵盖确保基于微软基础设施的服务器安全所需的策略和技术，包括设置、配置和管理安全控制。 2. **客户端安全**：讨论如何保护个人电脑和其他客户端设备免受恶意软件、网络攻击和数据泄露。 3. **组织结构安全**：强调企业级网络安全架构的设计，包括网络分段、访问控制和监控策略。 4. **平台特定安全选项**：深入探讨Windows操作系统及其他微软平台的安全设置和最佳实践。 5. **应用程序特定安全**：重点介绍IIS Web服务器、SQL Server数据库和Active Directory目录服务的安全配置和管理。 6. **新发布的安全工具**：提供原创的、未公开过的安全工具源代码，帮助读者更有效地实施安全措施。 7. **项目式“讲故事”**：通过实例展示如何将多个安全技术结合，以解决实际业务场景中的安全问题。 8. **参考式内容**：书中的信息组织成易于查找的形式，方便读者根据需要快速获取特定应用的安全技术和方法。 9. **作者观点与指导**：不仅告诉读者如何操作，还解释为什么这样做，有助于读者理解安全措施背后的逻辑。 10. **配套资源**：随书附赠的DVD光盘包含源代码、实用工具、视频教程等，为读者提供了额外的学习和支持资源。这本《Thor's Microsoft Security Bible》是微软安全专业人士和IT管理员不可或缺的参考资料，无论你是初学者还是经验丰富的专家，都能从中获得宝贵的洞见和实践指导，提升你的微软环境安全管理水平。

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 sim

ilar solutions, I would typically see SQL set up for mixed mode authentica

tion, 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 vul

nerability 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 connec

tion 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

3Scope and Considerations

takeaways from that chapter, our MSSQLSERVICE service should be run

ning 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 be

cause 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 config

ured, 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 Geoloca

tion.” 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 group

ing. 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

I prepend my global groups with a g so that they are all sorted together.

FIGURE 1.1 TMG Access Rule Showing

Outbound HTTPS Access for Authenticated Users

4 CHAPTER 1 Securely Writing Web Proxy Log Data to SQL Server

(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 anon

ymous users in the database itself, simply remove them from your query cri

teria, 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 organiza

tional attributes suggested.

5Implementation

剩余327页未读，继续阅读

唔系个好人

粉丝: 0

Thor's Microsoft安全宝典：实践安全技术集合

掌握thor-hollaback：在Ruby的thor命令中设置回调

Thor过滤器1.34版本适用规则全集

Thor：Python库简化HTTP中介开发

Thor

543个thor规则_thor规则_thor_Thor过滤器_543个thor_543个thor规则_

Thor 0.0.1

Thor 0.0.2

thor:Thor是我们公司的机器人

validaciones_thor

thor:雷神

最新资源