使用 NAP 和 IPsec 来控制通过 DirectAccess 进行的客户端访问,可以改进您的审核和合规报告。
Dan Griffin 和 Lee Walker
建立安全的访问机制是企业步入云计算时代的第一步。现在为合规、报告和远程连接设置相应的策略,也就规定了您的团队将如何安全、顺利地在云计算环境中开展工作。使用带 IPsec 的网络访问保护 (NAP) 连接技术(如 DirectAccess)可以帮助改进您的审核和合规报告工作。
为新的 DirectAccess 或 IPsec 部署方案创建审核和报告解决方案时,识别和收集必要的数据困难重重。在本文中,我们将用一家虚拟的公司作为例子,说明如何创建 DirectAccess 和 NAP 解决方案,并提供报告数据以确定谁进行了连接、何时进行的连接以及客户端计算机是否合规。
合规问题
由于员工的工作场所越来越变化多端,因此很多企业都采用了灵活的远程访问技术,如 DirectAccess。使用 DirectAccess 后,只要获得授权的计算机连接 Internet,用户就将自动连接到远程网络。由于远程客户端有时并未安装最新的安全修补程序,而且可能感染了恶意软件,因此很多企业还部署了带 IPsec 的 NAP 来帮助确保只有健康的客户端可以访问受保护的资源。
在金融服务、医疗卫生和政府等行业,确保只有健康且获得批准的客户端能够连接到云计算或本地网络资源,对于保护数据的完整性非常重要。这些行业经常要按照内部的合规策略以及国家/地区的法律规定,确认个人身份信息(PII,包括银行账号、姓名和健康记录等)不会被任何未经授权的人(包括通过恶意软件和未知的第三方应用程序)访问。
用户都希望能够轻松地远程访问其工作资源,因此这些行业的 IT 经理们还必须确保只有健康的客户端可以访问公司网络。遗憾的是,要从 NAP 和 DirectAccess 日志创建有意义的报告并非易事。
真正的解决方案就是:设置 DirectAccess 基础设施以实现顺畅的远程客户端访问、使用 NAP 和 IPsec 保护 Intranet 资源并通过报告来监控策略的执行情况。TechNet 中有很多关于如何通过 DirectAccess 实现 NAP 的有用信息,但是对于如何有效记录和报告客户端的健康状况,却很少提及。我们将用一家虚拟公司 (Woodgrove National Bank) 为例,说明一位顾问如何用一些简单的代码和 SQL 查询来创建可以直接阅读的报告。报告中详细列出了在指定时间段内连接的客户端以及这些客户端是否 NAP 合规。
在 DirectAccess 上设置 NAP
DirectAccess 要求连接的客户端运行兼容版本的 Windows(Windows 7 旗舰版或 Windows 7 企业版)。这些客户端连接到运行了 Windows Server 2008 R2 的 DirectAccess 服务器。 DirectAccess 部署方案中可以包含一台或多台 DirectAccess 服务器。(我们建议使用至少两台服务器,以便在网络繁忙时帮助平衡负载。)部署中还必须包括一台网络位置服务器(用于确定客户端是连接到 Internet 还是连接到 Intranet)以及一个或多个证书吊销列表 (CRL) 分发点(用于追踪不再允许访问的客户端)。要了解如何设计 DirectAccess 部署方案,请参见 TechNet 上的 DirectAccess 设计指南。
在 DirectAccess 上添加 NAP 时,您必须实施针对 NAP 的 IPsec 强制方法。使用 IPsec 时,NAP 合规的客户端将获得健康证书。如果计算机不合规,则不允许与其他合规的计算机进行通信。要了解如何设计和部署 NAP,请参见 TechNet 上的规划具有网络访问保护的 DirectAccess。要了解如何将带 IPsec 的 NAP 设计为强制方法,请参见 TechNet 上的 IPsec 强制设计。
考虑 NAP IPsec 强制方案如何在 DirectAccess 及其 IPsec 连接策略的背景下工作非常有意思。首先,由于 DirectAccess 使用 IPsec 进行身份验证并处理保密性,因此 DirectAccess 部署中的 NAP 强制方案必须是 IPsec。其次,请记住 IPsec 的 AuthIP 组件让您在策略中配置两个独立的身份验证要求,因此连接必须同时满足这两个要求才能成功。一般来说,如果配置了两个 AuthIP 身份验证选项,则第一个是计算机凭据,第二个是用户凭据。但是,也有可能要配置两个计算机凭据。
NAP 与 AuthIP 策略是如何结合在一起的呢?NAP/IPsec 强制方案为健康的计算机颁发带有健康对象标识符 (OID) 的证书。AuthIP 策略引擎包括一个选项,要求提供该健康 OID。因此,只有健康的计算机可以满足第一个 AuthIP 身份验证要求,并且与 DirectAccess 服务器建立 IPsec 连接。
最后,第二个 AuthIP 身份验证选项要求提供用户凭据。就技术而言,用户凭据对 DirectAccess 来说是可选的。换句话说,客户端可以只使用计算机凭据向 DirectAccess 端点验证身份。对于不经过加强的身份验证就授予完全的远程网络访问权限,注重安全性的 IT 人员应该表示担忧。因此,AuthIP 策略最少也要配置为要求第二个 Kerberos 身份验证。要求用户凭据的证书(在 Woodgrove National Bank 方案中就是如此)是非常好的方案,因为这可以降低远程静态密码攻击的风险。
在此方案中,Woodgrove National Bank 的网络安全和合规部门需要一个报告,显示在指定时间段内有哪些用户连接了公司网络,以及这些客户端是否 NAP 合规。他们相信这段时间内可能出现了用户数据损坏的情况。作为该银行的顾问,我们需要确定如何为 DirectAccess 和 NAP 启用事后报告功能,然后将这些信息转换为能够直接阅读的报告。
正确的策略配置
在这个虚拟的方案中,Woodgrove National Bank 已经配置了 DirectAccess,使 IPsec 策略要求提供包含 NAP 系统健康 OID 和客户端身份验证 OID 的客户端证书。Woodgrove 以强制模式使用 NAP(而不只是报告模式),这意味着将禁止不健康的客户端与健康的客户端通信。
最后,Woodgrove 配置了 DirectAccess IPsec 策略,使用两个基于证书的凭据:一个来自客户端计算机,一个来自用户。Woodgrove 按照上述建议选择了双证书配置,以便更好地利用其 PKI 投资,消除远程访问的静态密码并利用证书自动注册功能。
本示例的其余部分假定您具备相应的实践知识,了解 DirectAccess、NAP 和 IPsec 强制模式的工作原理。要深入了解这些技术,请参见以下资源:
下面的报告解决方案利用了 DirectAccess 服务器上的 IPsec 的内置审核功能以及网络策略服务器 (NPS) 的健康注册机构 (HRA) 功能的审核功能。这些审核功能会在系统和安全事件日志中生成事件,我们将提取这些事件并进行报告。在制定此方法时,我们发现默认生成的是 HRA 事件,而 IPsec 事件可能需要明确启用。您可以在命令提示符窗口中使用以下命令来启用 IPsec 事件:
auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Main Mode" /success:enable /failure:enable
auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Quick Mode" /success:enable /failure:enable
auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Extended Mode" /success:enable /failure:enable
DirectAccess 健康报告
为了开始处理 Woodgrove National Bank 的 NAP 和 DirectAccess 事件,我们下载并安装了 Microsoft 的 Log Parser 2.2。Log Parser 是这种项目中必不可少的工具,因为您必须浏览新的事件来源并制定相应的架构。简而言之,Log Parser 可以导入和导出多种数据格式,包括 Windows 事件日志 (.evtx)、CSV 和 SQL。
下一步是捕获所需的事件,包括:
DirectAccess 服务器安全日志中与 IPsec 安全关联相关的事件
HRA 服务器(如果使用 NAP 则是多台服务器)安全和系统日志中与健康注册机构相关的事件
收集这些事件的最好方法是实现自动化与集中化。Windows 事件转发功能就是这样一种选择。而在大型的生产部署中,Microsoft System Center 可能更加常用。在本示例中,我们不想为生产服务器加入新的关联功能,因此使用了简单的脚本来收集事件。
要使用这种方法,我们面对的挑战来自两个方面。首先,我们要关联多个数据源,因此大致在同一时间收集来自所有数据源的数据就很重要。其次,我们只需获取日志的快照,而高流量的事件日志滚动更新很快,因此一些关联事件的丢失就无法避免,尤其是在快照时间段的边缘时刻。这并不会导致实验失败,但会使微调查询变得更困难一些。
对于每个 IPsec 主模式安全关联(在一台 DirectAccess 服务器上),我们预计会看到 NAP 健康流量(在一台 HRA 服务器上)。在 NAP 报告模式中,客户端计算机可能已经合规也可能并不合规。在 NAP 强制模式中,客户端计算机应该已经合规。否则,客户端如何获得有效的证书以通过 DirectAccess 服务器的身份验证并建立安全关联 (SA)?假设我们在下午 3 点同时截取所有 DirectAccess 和 HRA 服务器上的日志,有可能我们只看到主模式安全关联 (MM SA) 事件,而看不到健康事件。
更有可能的是,我们可以看到 IPsec 快速模式安全关联 (QM SA) 和 IPsec 扩展模式安全关联 (EM SA) 事件,而看不到 MM SA 或健康事件。前者的发生要比后者晚一个小时甚至更多。此外,因为各台服务器上的日志几乎肯定是按不同的频率滚动更新的,所以我们可能在 DirectAccess 服务器上获得自下午 2 点以来的事件,而在 HRA 上最早的事件也是从下午 2:30 开始的。正是由于上述这些原因,我们需要重申,在生产环境中使用集中的事件收集非常重要。
生成数据
为了生成数据,我们在 DirectAccess 服务器和 HRA 服务器上运行了脚本。我们还使用任务计划程序将脚本配置为自动运行。我们将脚本配置为在 DirectAccess 服务器和所有 HRA 同时运行一次。
在 DirectAccess 服务器上收集数据
我们使用以下脚本在 DirectAccess 服务器上捕获事件(请参见图 1):
set MPATH=c:\temp\Logs
%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\DA_Security_Events_%COMPUTERNAME%.csv FROM Security WHERE EventCategory=12549 OR EventCategory=12547 OR EventCategory=12550" -o:CSV
注意:此脚本使用了本地的 LogParser.exe(及其关联文件 LogParser.dll)。这样做是为了使用方便,我们可以轻松地在服务器之间复制脚本。
图 1 借助任务计划程序自动运行的脚本从 DirectAccess 服务器捕获的事件详细信息。
事件 | 说明 |
12547IPsec | 主模式安全关联信息 |
12549IPsec | 快速模式安全关联信息 |
12550IPsec | 扩展模式安全关联信息 |
在 HRA 服务器上收集数据
我们使用以下脚本在 HRA 服务器上捕获事件:
set MPATH=c:\temp\Logs
%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\HRA_Security_Events_%COMPUTERNAME%.csv FROM Security WHERE EventCategory=12552" -o:CSV
%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\HRA_System_Events_%COMPUTERNAME%.csv FROM System WHERE SourceName='HRA'" -o:CSV
注意:在 HRA 脚本中,事件类别 12552 对应了网络策略服务器服务。
导入数据
脚本运行之后,我们将输出的 CSV 文件收集到一台运行 SQL Server 2008 的独立计算机上。我们使用以下脚本将 CSV 数据导入 SQL:
LogParser.exe "SELECT * INTO DaSasTable FROM DA_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023
LogParser.exe "SELECT * INTO HraSecurityEventsTable FROM HRA_Security_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023
LogParser.exe "SELECT * INTO HraSystemEventsTable FROM HRA_System_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023
注意:
SQL 主机的名称是 dev1。数据库的名称是 NapDa,在 SQL Management Studio 中使用默认值创建。
DaSasTable、HraSecurityEventsTable 和 HraSystemEventsTable 三个表尚不存在。Log Parser 命令行选项 -createTable:ON 指定 Log Parser 根据输入数据(在本例中是事件日志 CSV 文件)使用合适的架构自动创建这些表。
-maxStrFieldLen:1023 设置在本例中非常重要。没有这项设置,Log Parser 将为各种事件日志的字符串字段使用默认的 varchar 字段长度 255。但是,事件日志 CSV 格式中有些数据字符串的长度要更长一些(特别是在 Strings 字段中,请参见图 2),因此保证这些字段不被截断非常重要。作为实验,默认长度 1023 看起来够用了。
图 2 显示了 Log Parser CSV 事件日志导入所产生的架构。
图 2 Log Parser CSV 事件日志导入的架构。
准备数据
创建 DirectAccess 健康报告时,提取所需数据时的主要困难是事件日志 CSV 格式是基于数据字符串的。在 GUI 中,这些数据需要隔行转换为静态字符串,以描述每个数据字段的含义。数据字符串包含所有对 DirectAccess 健康报告有意义的信息,包括用户名、计算机名称、策略组名称和 IP 地址。
数据字符串连成单个 CSV 字段,最终形成单个 SQL 列(还是字符串)。各个字符串之间用“|”字符分隔。一种可行的方法是在数据导入 SQL 之前或之后立即对字符串进行标记化。但是,我们的选择是在数据导入 SQL 后进行分析,然后提取所需的几个特定数据条目,再用这些条目填充独立的 SQL 表。
使用与 T-SQL 匹配的字符串模式完成此任务非常困难。作为备用方法,我们使用了以前的 MSDN 杂志文章正则表达式使模式匹配和数据提取变得更容易中介绍的方法:使用 C# 实现用户定义的 SQL 函数,特别是针对基于正则表达式的模式匹配。
使用 Visual Studio 2008,我们几乎完全遵照了该文中介绍的步骤,当然其他文档中有关使用 Visual Studio 开始 SQL 和 CLR 集成的介绍也很有帮助。另外,由于正则表达式 (RegEx) 本身的复杂性,因此参考有关正则表达式的文档也会有所帮助,特别是有关分组的内容,因为这是 MSDN 杂志文章中的示例代码所采用的方法。
以下示例代码就是 SQL 用户定义函数的源代码,该函数使我们的 SELECT 语句具备了正则表达式功能。此函数称为 RegexGroup,与 MSDN 杂志文章中介绍的函数一样。我们对函数主体的前两行进行了一处修改,以便检查 NULL 输入值。在加入这两行之前,我们遇到了无数的异常,因为有几个 SQL 帮助程序表的列(此处介绍的)都是 NULL 值:
usingSystem;
usingSystem.Data;
usingSystem.Data.SqlClient;
usingSystem.Data.SqlTypes;
usingMicrosoft.SqlServer.Server;
usingSystem.Text.RegularExpressions;
publicpartialclassUserDefinedFunctions
{
[Microsoft.SqlServer.Server.SqlFunction]
publicstaticSqlChars RegexGroup(
SqlChars input, SqlString pattern, SqlString name)
{
if (true == input.IsNull)
returnSqlChars.Null;
Regex regex = newRegex(pattern.Value, Options);
Match match = regex.Match(newstring(input.Value));
returnmatch.Success ?
newSqlChars(match.Groups[name.Value].Value) : SqlChars.Null;
}
};
以下 SQL 命令创建并填充两个帮助程序表,表中包含使用正则表达式从初始数据集中提取的字符串:
/* Create the User-Computer-Address mapping helper table */
/* This step should only be performed once per data set */
CREATE TABLE UserComputerAndAddr
(
[RowN] int null,
[UserName] varchar(1023) null,
[ComputerName] varchar(1023) null,
[Address] varchar(1023) null
)
/* Populate the User-Computer-Address table */
/* This step should only be performed once per data set */
INSERT INTO UserComputerAndAddr(RowN, UserName, ComputerName, Address)
SELECT RowNumber,
dbo.RegexGroup([Strings],N'(?
dbo.RegexGroup([Strings],N'(?
dbo.RegexGroup([Strings],N'(?
FROM [NapDa].[dbo].[DaSasTable]
/* Create the Computer-Health mapping helper table */
/* This step should only be performed once per data set */
CREATE TABLE ComputerHealth
(
[RowN] int null,
[TimeGenerated] datetime null,
[EventType] int null,
[ComputerName] varchar(1023) null
)
/* Populate the Computer-Health mapping table */
/* This step should only be performed once per data set */
INSERT INTO ComputerHealth(RowN, TimeGenerated, EventType, ComputerName)
SELECT RowNumber,
TimeGenerated,
EventType,
dbo.RegexGroup([Strings],N'REDMOND\\(?
FROM [NapDa].[dbo].[HraSystemEventsTable]
仔细研究第一个 SELECT 语句以及它对 RegexGroup 函数(该函数通过我们介绍的技术安装)的使用,有助于了解字符串模式。图 3 详细介绍了我们定义的三个正则表达式模式。
图 3 使用 SQL 命令定义的三个正则表达式模式。
正则表达式模式 | 注意 |
用户名 | 示例:ichiro@redmond.corp.microsoft.com |
计算机名称 | 示例:dan-dev-1@redmond.corp.microsoft.com 请注意,在此模式中我们明确排除了与 DirectAccess 服务器自身的匹配。 |
IPv6 地址 | 例如:2001:0:4137:1f6b:8c8:2f30:e7ed:73a8
|
这些正则表达式共同创建了一个表,这个表由用户、计算机和地址信息组成。这些信息来自 DaSasTable 中的每一行(即从 DirectAccess 计算机导出的 IPsec SA 事件)。
创建并填充 UserComputerAndAddr 表后,会创建第二个表,用于将计算机名称与 HraSystemEventsTable 表中每一行的事件类型进行对应。如果您查看计算机名称的模式,您会发现在此日志中,计算机名称的格式不同于 DirectAccess 日志中的格式。在本例中,我们搜索 REDMOND\dan-dev-1 这样的字符串。图 4 详细介绍了 EventType 字段中可能存在的不同事件。
图 4 EventType 字段中可能存在的事件类型。
事件类型 | 说明 |
0 | 成功。计算机提交了健康的 NAP 合规声明。 |
1 | 失败。计算机不符合 NAP 策略。 |
在此部署方案的健康报告中,我们应该只会看到事件类型 0,这是因为 NAP 是在强制模式下使用的。正如您将在下文中看到的,我们还要筛选成功的 IPsec 安全关联。如果客户端不合规,它应该不能获取有效的 IPsec 证书并建立 SA。另一方面,如果您的组织已经用报告模式部署了 NAP,您将看到有一些不合规的计算机进行了连接。连接到网络的合规计算机与不合规计算机的相对比例将是报告中的一项重要统计信息。
注意:在创建表来容纳正则表达式的结果时,我们建议您使用永久的 SQL 表。如果您使用临时表(就像我们在下一步所演示的),正则表达式查询的速度将会变慢。
构建报告
正则表达式分析完成并创建帮助程序表后,我们现在可以集中精力来构建健康报告。一旦准备好数据,编写报告查询就变得相对容易。
本示例报告将列出所有在 2010 年 5 月 5 日下午 3 点到 4 点之间建立了 DirectAccess 连接的用户。除了用户名,报告还会列出计算机名称和健康状况。
为了找出这些用户,我们将从查询该时段内成功的(事件类型 8)QM SA(事件类别 12549)开始。在此方案中,QM SA 事件非常有用,因为 IPsec 已经配置为要求进行第二项身份验证(用户的凭据)。我们之所以选择了这种报告方式,是因为 QM SA 的存在时间相对较短(在本例中是一小时,不活动超时值是五分钟),因此很适合审核访问。相反,MM SA 只要求使用计算机凭据,而且默认情况下可存在八小时(如果审核是 DirectAccess 部署方案中的重要组成部分,我们建议缩短 MM 的生命期)。
遗憾的是,QM 事件不包括用户名或计算机名称,而只包括 IP 地址。要将 IP 地址对应到计算机名称和用户名,我们可以在 SQL 查询中使用几条 SELECT 语句。以下查询中的第一条 SELECT 语句将返回指定时段内新的 QM SA 中出现的地址列表。第二条 SELECT 语句使用这些地址来映射日志中其他地方出现的与该地址相关的用户名和计算机名称。(这种用户/计算机/地址的关联出现在 EM SA 事件中。这些事件对于此练习非常重要,因为它们包含所有三种值;如果您不要求 IPsec 二次身份验证,将无法进行这种类型的报告。)
复制代码
/* The following steps build the report, based on the three imported tables
* plus the two helpers above. These steps can be run any number of times as
* you refine your query.
*/
/* Create a temporary table to populate as the final report */
CREATE TABLE #SaHealthReport
(
[UserName] varchar(1023) null,
[ComputerName] varchar(1023) null,
[HealthEventType] int null
)
/* Run a query to find all IPsec Quick Mode Security Associations established
* within a given period. Populate a temporary table with the client IPv6
* addresses. */
SELECT DISTINCT[Address] INTO #TempAddresses
FROM [NapDa].[dbo].[DaSasTable] JOIN [NapDa].[dbo].[UserComputerAndAddr]
ON RowN = RowNumber
WHERE [EventType]=8 AND
[EventCategory]=12549 AND
([TimeGenerated] BETWEEN'2010-05-10 15:00:00.000' AND '2010-05-10 16:00:00.000')
/* Map the QM SA addresses to user and computer names and insert those into
* the final report. */
INSERT INTO #SaHealthReport(UserName,ComputerName)
SELECT UserComputerAndAddr.UserName,UserComputerAndAddr.ComputerName
FROM [NapDa].[dbo].[UserComputerAndAddr] JOIN #TempAddresses
ON #TempAddresses.Address = UserComputerAndAddr.Address
WHERE (UserComputerAndAddr.UserName IS NOT NULL) AND (UserComputerAndAddr.ComputerName IS NOT NULL)
/* Populate the health column of the report. */
UPDATE #SaHealthReport
SET HealthEventType = ComputerHealth.EventType
FROM #SaHealthReport JOIN [NapDa].[dbo].[ComputerHealth]
ON #SaHealthReport.ComputerName = ComputerHealth.ComputerName
/* Display all rows and columns of the report. */
SELECT DISTINCT *
FROM #SaHealthReport
填充 SaHealthReport 报告表的最后一步是关联 HRA 健康信息与计算机及用户身份信息,这样就与 DirectAccess 服务器有了显著区别。在这种混合模式中加入 HRA 服务器信息是一种有力的工具,使您可以确定远程连接到网络的计算机是否会(由于不合规而)带来风险。请参见上述 SQL 查询中的 UPDATE 语句:DirectAccess 和 HRA 数据的关联是使用计算机名称完成的。
图 5 显示了完成后的健康报告可能会返回的数据示例。
图 5 完成后的健康报告示例
UserName | ComputerName | HealthEventType |
Ichiro | ichiroadmin1 | 0 |
Grinch | whoville-cli | 0 |
Raquel | omybc | 0 |
使用一些自定义的脚本和 LogParser 工具,您可以相对轻松地在 IPsec(包括 DirectAccess)和 NAP 部署上建立起报告机制。此方法可帮助企业开始为业务线服务创建安全框架,而无论这些服务是位于本地还是位于云计算环境中。