[微软教程] 安全部署审查

安全部署审查发布日期: 1/10/2005 | 更新日期: 1/10/2005
6 R1 w; C& ]3 t/ @, X0 ?" X& |0 ]& T6 v2 M. B7 ]
, V  O2 R5 L) G3 P& Q9 i6 z
3 w  `5 ?+ [  o2 b

: E8 P0 c% X4 R- C查看全部的安全性指导主题( N$ L- z( j( z$ y* m8 }4 {
Microsoft Corporation
0 g/ y$ O9 [0 n: e; N% \" Z( G' }8 \# o5 Z

6 Z* X& K' z: K& a* g本单元概要在 ASP.NET Web 应用程序部署在实际服务器上之后,必须确保最后的部署安全地实现,而且 Web 应用程序环境尽可能安全和得到保护。
+ b4 R6 @$ ]% ^) j如果底层的基础结构不安全而且容易受到威胁,那么创建 ASP.NET Web 应用程序时的所有努力,即设计时安全、默认时安全和部署时安全(即能够在高度安全和受保护的服务器环境中工作)也无法保护应用程序。脆弱的网络或者主机配置设置会产生可能而且将被利用的缺陷。 - |5 i! Y- a9 B; U# ~+ L5 @
本单元包含一个覆盖了网络和主机安全配置问题的全面列表。这提供了一个方法和框架,有助于执行安全审核。2 y: U9 r6 E- P
返回页首$ L; r3 i2 z2 w8 A  B) B, Y
目标使用本单元可以:
1 ^" H3 i4 D% M5 `
确保您的 ASP.NET Web 应用程序安全地部署,并且正寄宿在安全的环境中。 ) h) {0 ?- S' n1 C. L
创建一个执行部署审查和安全审核的方法和框架。
9 H0 l; q- C! k. @7 h  t9 _
通过询问安全问题的一个全面列表快速定位安全问题。 ( C' R" u+ M9 d
审查以下的已部署配置:网络和主机、基础 Windows 2000、IIS 和 .NET Framework、Web 应用程序和 Web 服务、企业服务、远程处理和 SQL Server。 2 p) a8 Y, N5 c9 ^. j+ i
返回页首$ b( W* f" v; k+ r; }0 m
适用范围本单元适用于下列产品和技术: , o' g' C7 u8 ^! ?# u. F6 I
Microsoft® Windows® Server 2000 操作系统 # f: S% l: b1 d$ W4 r# r( y7 n
Microsoft .NET Framework 1.1 和 ASP.NET 1.1 0 O* }9 w% k9 c0 }/ F5 |5 W/ N
Microsoft SQL Server™
0 o( e$ h: P. h4 \  ^
返回页首
) Y& |( }3 e$ ~: v+ ?( R1 {如何使用本单元使用本单元可以确保 ASP.NET Web 应用程序安全地部署,并且寄宿在安全的环境中。
* C- H6 M( |3 e8 A" T5 E
要想充分利用本单元:
  r$ ]0 o6 F6 `& I1 A) I
阅读“安全代码审查”单元,遵循其中的方法确保 Web 应用程序在开发时就是安全的。
' V2 i2 ~, m6 z  s  d1 l: q
使用配置类别。使用本单元中标识的类别可以帮助使您的安全审查工作更加集中。
8 E! S, w# S1 z0 e: g9 t. j4 e
使用本指南第 IV 部分中与本单元配套的保护单元: ' }4 s( _- a0 _% _0 Q
保护网络的安全
4 h2 J+ N' z! ?
保护 Web 服务器的安全
' }5 L9 s2 r3 t- I
“保护应用程序” & j) g/ p, j; U& v$ }- N
“保护数据库服务器”
1 X) n$ a) s  O$ f9 l+ z
保护 ASP.NET 应用程序的安全7 J. U# J8 e1 z
寄宿多个 Web 应用程序% v8 R9 z& A  Z; m
使用配套的核对表   D5 N1 a4 p0 b2 n$ l& o
核对表:保护网络的安全
& x6 ~/ ^5 R& w( b+ ^. c
核对表:保护 Web 服务器的安全
+ A1 O4 l* g2 H0 N5 \1 R7 v8 O
“核对表:保护数据库服务器”
6 s, i$ G. K" o5 @. x
核对表:托管代码的安全审查
' Z- l7 ]+ y, b$ `
本页内容
本单元概要
目标
适用范围
如何使用本单元
概述
Web 服务器配置
IIS 配置
Machine.Config
Web 服务
企业服务
远程处理
数据库服务器配置
网络配置
小结
返回页首" {$ z3 b* s0 B1 w7 w
概述Web 应用程序的安全依赖于应用程序部署所在的底层基础结构的安全。脆弱的网络或者主机配置设置将产生可能和将要被利用的缺陷。本单元中覆盖的部署审查检查了网络和主机的配置。主机包括 Windows 2000 Server,根据服务器角色的不同,还可能包括 IIS、Microsoft .NET Framework、企业服务和 SQL Server。+ m3 o5 X1 {( H: L3 N6 [9 f6 |
部署审查过程中需要涉及的主要配置元素如图 1 中所示。
; i6 F/ F, Q+ H% l! `
% d& ?' G) S1 H8 G+ z( ] 1. 部署审查的核心元素2 F# q) E) f( |+ Z8 |3 g6 [

+ N3 c0 f7 Q/ g1 f$ V& ^4 g; R# t% ~8 n1 ~# ^3 A
返回页首
' O" H3 ]1 |4 L; rWeb 服务器配置审查中此阶段的目的是标识 Web 服务器上基础操作系统配置中的缺陷。这不包括 IIS 配置,后者需要单独处理。有关本部分中审查问题所提出问题的进一步背景信息,请参阅“保护 Web 服务器的安全”单元。
8 u! W, G' c& x$ O; B要帮助集中和组织审查过程,将审查问题划分为以下配置类别:
+ ^. e1 `8 i" C4 ]
修补程序和更新
6 y# L- Z, T0 f2 ?- t
服务
. b1 E  R1 k# U0 c- x+ i
协议. |5 j1 t( W( Z: M
帐户* a: N( }& ]& B" l
文件和目录( Z" `* J0 C% P, C2 {, E7 ]
共享
  X! q+ Q; U7 @7 M6 y) @; g
端口! I* Z% Q( _& `. C4 ?
注册表
7 _2 c3 y. U8 K" c  C& j
审核和日志记录
( l3 R( v5 f0 H( O% r9 u5 e; V
修补程序和更新8 G* a* d* l  H6 e
验证您的服务器是否使用最新的服务包和软件修补程序进行了更新。需要分别检查操作系统组件和 .NET Framework。审查以下问题: 1 o3 M% Q+ b3 s+ r
运行 MBSA 了吗?
3 y' o6 a9 q  l% t$ r* R确保您已经运行 MBSA 工具标识了常见的 Windows 和 IIS 缺陷,并标识了遗漏的服务包和修补程序。
# y! M5 n1 \- T; b: x通过修补已标识的缺陷,并安装最新的修补程序和更新,对 MBSA 的结果做出响应。有关更多信息,请参阅“保护 Web 服务器的安全”单元中的“第 1 步. 修补程序和更新”。
/ f( [7 g4 G& t8 c
安装 .NETFramework 更新了吗?# K. H+ c" u8 z; l! z2 g
要确定 .NET Framework 的当前版本,请参阅 Microsoft 知识库文章 318785,“INFODetermining Whether Service Packs Are Installed on the .NET Framework”。然后将 .NET Framework 的已安装版本与当前服务包做比较。为此,使用文章 318836 中列出的 .NET Framework 版本,“ INFO How to Obtain the Latest .NET Framework Service Pack”。
9 ~. F5 c0 Q4 a! Q
服务) y2 V  i& }8 H: N1 U( @
确保只启用必需的服务。检查是否所有其他服务都已经禁用,这样能够减少服务器的受攻击面。为了查看哪些服务正在运行和启用,使用服务和应用程序 Microsoft 管理控制台 (MMC) 管理单元,可以从“计算机管理”中访问。要禁用一个服务,一定要先停止它,然后将其启动类型设置为手动。
6 n' Z# i* r! G) C% d6 [审查以下问题以验证您的服务配置:
3 V4 Y/ \4 H3 ~2 {8 Q
运行不必要的服务了吗?5 L. N  N! S4 m
通过使用服务管理单元,审查每个正在运行的服务,确认每个服务都是必需的。标识为什么必需,哪些解决方案要依赖于它。确保禁用所有不必要的服务。
4 H* x! Z$ S& b) v+ w/ ]5 ^2 S' l
禁用 Telnet 服务了吗?
* R8 o" w6 [' o8 {& q5 B0 OTelnet 经常用于远程 IIS 管理。但是它是一个不安全的协议,容易遭到许多攻击。检查是否禁用了 Telnet 服务。要获得更安全的管理解决方案,应该使用终端服务。
5 u+ g1 t$ y5 t) B2 v
禁用 FTPSMTP NNTP 服务了吗?
+ X1 ?5 c9 Q7 X: G! K这些服务都是不安全协议,有已知的缺陷。如果您不需要,就应该禁用它们。如果您需要使用它们,则应该寻找安全的替代方案。这些服务都在服务 MMC 管理单元中列出,即 FTP 发布服务,简单邮件传输协议 (SMTP) 和网络新闻传输协议 (NNTP)。 9 ?0 D* J% d* ~, W6 |% F6 a
IISLockdown 禁用这些服务。
% r) |4 n! F' ~# f# O  U+ c* _6 g
使用 ASP.NET 会话状态服务了吗?2 f* H& j2 L; S# G+ S
要想知道应用程序是否使用了这个服务,可以查看应用程序的 Web.config 文件中的 <sessionState>元素。如果 Web.config 不包含这个元素,检查 Machine.config 中它的设置。如果 mode 属性设置为“StateServer”而且 stateConnectionString 指向本地机器例如本地主机地址,就需要在 Web 服务器上使用会话状态服务,如下所示:
- H/ w! F! @1 r3 x+ w3 M2 p( o: U<sessionState mode="StateServer"          stateC />如果您没有在 Web 服务器上使用该服务,就应该禁用它。在服务 MMC 管理单元中它是以“ASP.NET State Service”的形式列出的。 & G; {& b0 o# P" b* M/ r
有关如何保护 ASP.NET 会话状态的更多信息,请参考“保护 ASP.NET 应用程序的安全”单元中的“会话状态”。
2 [* z0 w) I% O0 d1 v4 C% p
协议  s2 d3 I( M  `
审查服务器上启用了哪些协议,确保没有启用不必要的协议。使用以下问题辅助审查服务器上的协议:
1 {+ B0 f% r2 ?* u. j8 q! H
使用 WebDAV 了吗?9 e5 A$ C- @8 ^7 V$ Y! i
如果您使用 Web 分布式创作和版本控制协议 (WebDAV) 发布内容的话,那么应该确保它是安全的。如果您不使用它,应该禁用此协议。 3 B& J0 @9 Z8 |* |6 b: t
有关如何保护 WebDAV 的信息,请参阅 Microsoft 知识库文章 323470,“How To:Create a Secure WebDAV Publishing Directory”。有关禁用 WebDAV 的信息,请参阅文章 241520,“How to Disable WebDAV for IIS 5.0”。 7 r. o5 z; N* b6 b0 h: D
加固 TCP/IP 堆栈了吗?3 e3 M  w( j" W8 d9 @* S8 H
确保加固了 TCP/IP 堆栈,以防止网络级拒绝服务攻击,包括 SYN flood 攻击。为了检查服务器上的堆栈是否加固,使用 Regedt32.exe 并检查以下注册表项: ) O4 @' U/ ?& B6 a! ]5 s  t  ^
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters如果存在以下子项,则表示已经加固了 TCP/IP 堆栈:SynAttackProtectEnableICMPRedirectEnableDeadGWDetect% X& Z* N" R% A+ c( r. F( g- N0 h
有关完全加固堆栈所必需的项和相应项值的完整列表,请参阅本指南“如何做”部分中的“How To Harden the TCP/IP Stack”。
. T' T) J5 o+ H- k7 _
为面向 Internet 的网卡禁用 NetBIOS SMB 了吗?
& F! j- Q2 B% v/ z检查是否禁用了 TCP/IP 上的 NetBIOS,并且禁用了 SMB,以防止主机枚举攻击。有关更多信息,请参阅单元“保护 Web 服务器的安全”中的“协议”。
! W5 D* y: R8 z" E/ I/ D1 F
帐户
! t9 k2 V4 C6 u& a. Z; r审查服务器上使用的所有 Windows 帐户,以确保不存在不必要的帐户,而且所有必要的帐户都配置为最低特权和必需的访问权限。以下问题有助于标识帐户缺陷: % r/ M6 c- j8 x
删除或者禁用所有未用的帐户了吗?- F* g7 Q" j4 k
执行审核以验证所有帐户都在使用,而且是必需的。删除或者禁用任何不必要的帐户。本地管理员帐户和 guest 帐户无法删除。应该禁用 guest 帐户并将 Administrator 帐户改名,确保它有坚固的密码。 . F' _7 q) U  k3 e1 D1 x
禁用 Guest 帐户了吗?
2 C; K9 V0 X$ p+ M' C要检查是否禁用了 guest 帐户,显示计算机管理工具中的 Users 文件夹,并检查是否 guest 帐户旁显示有叉号图标。如果没有禁用,显示 Properties 对话框并选择 Account is disabled$ i1 }3 r" [1 f) o
重命名默认管理员帐户了吗?) A' i$ N5 y% Q2 C' e2 M. ]
默认的本地 administrator 帐户是攻击的主要目标。验证已经重命名了 administrator 帐户,并赋予其坚固的密码。
5 v8 z9 {: g& _" q# l4 o! h9 P9 Y
创建自定义匿名 Web 帐户了吗?
* x$ K# S2 P' U) l5 Z' y+ F, x检查是否禁用了默认 IUSR_MACHINE 帐户,并且已经配置了替代的 anonymous user 帐户供 Web 应用程序使用。 , z+ f5 C, ]) `( }) B
使用坚固的密码策略了吗?0 ?( Z2 _, L$ S
使用本地安全策略工具审查密码策略。有关推荐的密码策略的信息,请参阅“保护 Web 服务器的安全”单元中“第 5 步:帐户”。 7 F& s1 H! V1 J$ Q9 d- e) t# ~
限制远程登录了吗?) n* l+ g" q9 L  @1 \, B: h4 B
检查本地安全策略工具中的用户权限指派,以确保 Everyone 组没有被授予“从网络访问本计算机”的用户权限。
; u9 j8 O& ?9 m" Q
禁用空会话了吗?
0 s; q$ p2 ~( S1 v检查是否禁用了空会话,以防止您的服务器创建匿名(未经过身份验证的)会话。为了检查这一点,运行 Regedt32.exe 并确认 RestrictAnonymous 项设置为 1,如下所示。 . i# h% U4 C* m% R% j
HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous=1
文件和目录
2 O1 f& C: H5 b! T' G以下审查问题能够验证是否适当地使用 NTFS 权限锁定了一些帐户,例如匿名 Web 用户帐户。 - y- c6 i8 L, F$ L% _: d' m
IIS 安装在 NTFS 卷上吗?
7 X+ y- z, d2 R; U" k% a% T这使您能够使用 NTFS 配置资源的 ACL 以限制访问。不要构建使用 FAT 分区的服务器。 , ^2 D' C$ ]: r' R5 F5 m8 v1 _
限制 Everyone 组了吗?! z& U& J" z! u+ X( X3 D
使用 Windows 资源管理器确保 Everyone 组不具备访问以下目录的权限: 4 E& q9 t+ t. }
根目录 (:\) , p$ q) A, S( Z/ L2 b. p, W
系统目录 (\WINNT\system32)
/ |- H# ~, W" s8 R
框架工具目录 (\WINNT\Microsoft.NET\Framework\{version}) % O& [* K, F6 W) n: Z6 f
Web 站点根目录和所有内容目录(默认时是 \inetpub\*)
( v, `3 X* c4 i+ }0 j# }: H+ e
限制匿名 Web 用户帐户了吗?
4 k9 W7 g7 X; \7 ?确保匿名 Internet 用户帐户不能写入 Web 内容目录。使用 Windows 资源管理器查看每个内容目录的 ACL。还要检查 %windir%\system32 目录的 ACL,以确保它不能访问系统工具和实用工具。
' o5 x; D& k8 P. V# v( ~6 i; j 如果您运行 IISLockdown,Web 匿名用户组和 Web 应用程序组可以用来限制访问。默认时,Web 匿名用户组包含 IUSR 帐户,而 Web 应用程序组包含 Internet Web 应用程序管理器 (IWAM)。从管理的角度来看,限制访问一个组比限制单独的帐户要好。
( {! h3 [  x/ `
保护或者删除实用工具和 SDK 了吗?
! z' ~( Q& r1 o4 V3 I8 [* e验证服务器上没有实用工具或者软件开发包 (SDK)。确保没有安装 Visual Studio.NET 和任何 .NET Framework SDK。还要确保使用 NTFS 权限限制了对强大系统工具(例如 At.exe、Cmd.exe、Net.exe、Pathping.exe、Regedit.exe、Regedt32.exe、Runonce.exe、Runas.exe、Telnet.exe 和 Tracert.exe)的访问。最后,确保服务器上没有安装调试工具。IISLockdown 自动限制 Web 匿名用户组和 Web 应用程序组对系统工具的访问。
: y& X( p2 y, n: V' s9 J) w
删除未用的 DSN 了吗?
! K, T! G  V) U& i) j/ h+ m验证所有未用的数据源名 (DSN) 已经从服务器删除,因为它们可能包含明文数据库连接详细信息。   b5 E  s2 n: _4 g3 g
共享  r" H/ ]$ q4 B' S4 B) e- I
审查以下问题以确保不存在文件共享不必要地公开服务器: ; i5 x; V) }" K6 ~/ T1 j: d
服务器上有什么共享?3 Q9 m' G! G1 E2 M
要审查共享和相关的权限,运行计算机管理 MMC 管理单元,选择 SharedFolders 之下的 Shares。检查是否所有共享都是必需的。删除任何不必要的共享。 : e7 m0 O$ l/ `# C
Everyone 组能够访问共享吗?! R7 A  [* f% N& Q
验证 Everyone 组没有被授予访问共享的权限,除非故意如此,还要验证已经配置特定的权限来代替。 ! V' ]7 i6 K- y( g& z' x
删除管理共享了吗?6 H% I" H& n# o  [' g$ ]
如果您不允许远程管理服务器,那么检查是否管理共享(例如 C$ 和 IPC$)已经删除。 $ d# `  L! x- ~% n" [
端口
- I6 f) s/ O; d8 }1 C; ]; G审查服务器上的活动端口,以确保不存在不必要的端口。要验证正在侦听哪些端口,运行以下 netstat 命令。% v6 y( f0 n/ S. e# {2 c  V& Z
netstat -n -a这个命令生成以下输出:, a8 [. K6 w# x( A5 h
0 ^  u1 z3 S# h0 i
2. Netstat 的输出
8 k4 Y) G5 G5 Y) V: j& o$ K* g# ~

2 d5 ?) d) |0 X  d0 A这个输出列出了所有端口以及它们的地址和当前状态。确保您知道每个侦听端口公开的服务,并验证每个服务都是必需的。禁用任何未用的服务。7 j6 f# D  p" }( G" O+ `7 U9 g
要从 netstat 输出筛选出特定的字符串模式,可以将其与操作系统 findstr 工具结合使用。以下示例筛选了处于“LISTENING”状态的端口的输出。
( z& {2 j- @# \netstat -n -a | findstr LISTENING您还可以使用 Portqry.exe 命令行实用工具验证 TCP/IP 端口的状态。有关工具和如何下载的更多信息,请参阅 Microsoft 知识库文章 310099,“Description of the Portqry.exe Command-Line Utility”。
: k. A7 ?% ]  l2 t6 \. h还要审查以下问题:
9 ?; v! q/ \' E/ Z) i$ ?
面向 Internet 的端口被限制为 TCP 80 443) |7 h; ?2 x6 ?' ]1 N
Intranet 流量是受限的或者进行了加密: K3 _: D* z  N7 C
注册表
; m( S5 k7 O) L2 D+ W通过以下问题审查注册表配置的安全: / L( w, f+ h) H7 i$ w3 ]* x
限制远程注册表管理了吗?- i8 N5 [) K/ Q) l$ g1 u: n
使用 Regedt32.exe 以审查 WinReg 注册表项的 ACL,这能够控制是否可以远程访问注册表。 : y2 z$ l) R+ a, V5 b1 i" y
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winregWindows 2000 上默认时远程注册表访问权限仅限于 AdministratorsBackup operators 组的成员。为了尽量提高安全性,通过使用空的自由访问控制列表 (DACL) 限制对注册表的所有远程访问。
5 `2 t0 R+ E; z" H& Y0 c2 M 有些服务需要远程访问注册表。请参阅 Microsoft 知识库文章 153183“How to Restrict Access to the Registry from a Remote Computer”,查看是否您的场景要求有限的远程注册表访问。
+ t# N3 I, ~$ b7 N5 {4 h0 h* m
保护 SAM 了吗?
/ A, C' s6 u/ e9 [) T+ [这只适用于独立服务器。检查是否通过如下所示在注册表中创建了项(而不是值)NoLMHash,从而限制了安全帐户管理器 (SAM) 数据库中的 LMHash 存储区: ( J& T+ R8 \4 e' a
HKLM\System\CurrentControlSet\Control\LSA\NoLMHash
审核和日志记录
) k8 q0 H: E# ], a2 w+ [' n6 C- b通过以下问题审查 Windows 审核的使用。 & X* {0 R( u1 T7 H- T5 E
记录所有失败的登录企图了吗?
& s! Q2 h) T2 R& f5 |& _% t使用本地安全策略工具检查是否启用了对失败登录企图的审核。
* i% Z. r% p* I: \& \5 G' w& `
记录所有文件系统的失败操作了吗?
* u, |0 C& B# W3 r1 |3 s4 y使用本地安全策略工具检查是否启用了对象访问审核。然后检查是否整个文件系统都启用了审核。
2 r# Z! m! V! V+ \) G
返回页首+ v3 R3 _+ X  n) I
IIS 配置提供审查和提高 IIS 配置设置的安全性,可以有效地减少 Web 服务器的受攻击面。有关本部分中讨论的审查点的更多信息,请参阅“保护 Web 服务器的安全”单元。6 _- j" K% c9 j( }9 v
本部分中审查问题已经按以下配置类别组织。 & M# |7 O8 U2 V# q* p6 Y
IISLockdown% Q& P. z% S  r% g7 }0 V
URLScan
* K  ~1 J+ f( \, ?  M9 Y' X
站点和虚拟目录
$ \5 i; u0 Z" M  F7 ?
ISAPI 筛选器
1 ]  S9 h$ c  N1 [' x% C2 p+ B
IIS 元数据库- W" j! k, Z2 O1 y: m( {
服务器证书, W( _; D/ K: Y
IISLockdown4 H" E! m& @% _: d# f/ t. \
IISLockdown 工具能够标识和关闭功能,以减少 IIS 的受攻击面。为了查看它是否运行在您的服务器上,检查 IISLockdown 生成的以下报告:1 s" v; k  |2 m
\WINNT\system32\inetsrv\oblt-rep.log有关 IISLockdown 的更多信息,请参阅本指南“如何做”中的“如何使用 IISLockdown”。9 c2 Z# C4 M5 y  Y
URLScan
9 B; Z: r3 {5 U; E1 ]URLScan 是一个随 IISLockdown 安装的 ISAPI 筛选器。它有助于防止可能有害的请求到达服务器并导致破坏。检查是否已经安装并已经适当地进行了配置。
; Y  S. h& t" o$ n$ b为了查看是否安装了 URLScan7 z+ g" b! _) u) v; h
1.5 u$ V3 ^) y8 c9 {* R: r3 {
启动 Internet 信息服务& u; C9 m* O- f- s' {) _& m
2./ F7 u; S% f. s- x& L
鼠标右击服务器(而不是 Web 站点),然后单击 Properties  o+ x4 \& A% f7 a
3.
/ O; J( ?5 q' c$ x$ T. g
单击紧靠 MasterPropertiesEdit 按钮。& s, [6 q0 J5 H' K; \! ]: X3 g
4.% i+ V5 K( O- `6 Z- L6 j- w9 \
单击 ISAPIFilters 选项卡,查看是否列出了 URLScan。 % H( U1 R7 [/ s  ]6 `8 h
为了检查 URLScan 配置,使用记事本编辑以下 URLScan 配置文件。9 K6 d) i# _' A7 A9 c
%WINDIR%\System32\Inetsrv\URLScan\URLScan.ini有关 URLScan 的更多信息,请参阅本指南“如何做”部分中的“如何使用 URLScan”。
& W7 C# m; i2 n7 f* r站点和虚拟目录! M. j4 ~  w# S& x6 I0 L
本部分中的审查问题与 Web 站点的特定配置和应用程序的虚拟目录相关。本部分中,将审查以下类别:
" g, p) \* q; E! \
Web 站点位置
' H  `* o) e1 Q: x
脚本映射
) |% l' o5 ^$ j
匿名 Internet 用户帐户
, n6 d( E6 C: S$ U
审核和日志记录
( O6 f# o1 F* u. c; C
Web权限
8 Q5 y2 w5 L- @. k- c
IP 地址和域名限制2 ~3 `- O* z* k3 @: |$ l
身份验证
! I9 n! R7 m. J0 w
父路径设置' G8 J8 }- L  ]
Microsoft FrontPage 服务器扩展
6 q" }- @) z5 B' c% Q8 y4 O
Web 站点位置' Q9 U: K# ]8 |: _0 k7 a* d9 z
检查 Web 站点的根目录是否安装在非系统卷中。通过重新定位您的 Web 站点根目录到非系统卷,能够防止攻击者使用目录遍历攻击访问系统工具和可执行文件,例如 Cmd.exe。
4 o+ f) S* j) B' V6 l" o* U脚本映射
7 o' o( Q4 w6 ?( s0 p1 k5 {检查是否映射所有不必要的文件扩展名到 404.dll,后者在运行 IISLockdown 时安装。
, Y: J2 j+ \: @/ ?' a4 n8 r& t7 i- Z要审查脚本映射$ r& e2 m. S. e
1.) C5 _' `! w2 n3 m9 J1 Q
启动 Internet 信息管理器5 M& \# o; G/ m' t. a3 U3 D# ^
2.
4 ?0 B: _- e! C1 \- m$ u$ w$ l
鼠标右击 Web 站点并单击 Properties1 ^6 ?/ K2 |, J6 B$ {( r
3.
' E) X  U) O7 G- ]' Y
单击 Home Directory 选项卡,然后单击 Application Settings 组中的 Configuration 按钮。
/ K2 m& I, X8 ]- w; n) P6 T7 ]
匿名Internet 用户帐户# \! A  \+ G% g( M8 J
验证您的应用程序是否配置为使用了非默认匿名 Internet 用户帐户。如果您的服务器上有多个 Web 应用程序,检查是否每个应用程序都被配置为使用不同的匿名帐户。这使您能够配置权限并跟踪每个 Web 应用程序的活动。4 B8 l9 W$ X& H& n1 w$ r) Q6 I
审核和日志记录
- g7 m$ P- c! _$ O' u0 E9 V检查您是否配置 IIS 审核,以帮助检测进行中的攻击,并诊断攻击踪迹。以下审查问题有助于标识 IIS 审核中的缺陷: ( c: L( R1 ^0 u- \9 ~& r
日志文件定位在不同的非系统卷了吗?
+ p5 q7 K$ a$ i7 m鼠标右击 IIS 中的 Web 站点,单击 Web Site 选项卡。单击 Properties 按钮以检查日志文件位置。检查是否日志文件位于一个使用非默认名称的非默认位置(最好在非系统卷上)。 # Z- a4 o4 `8 b4 L& q8 c3 |
限制访问日志文件了吗?
0 i& ?8 J, d- g  |使用 Windows 资源管理器查看日志文件目录上的 ACL。检查是否 ACL 授予管理员和系统帐户完全控制,但是没有授予其他用户访问权限。 ; N; d/ F7 R6 x6 W' s' @# S1 f6 p
Web 权限
7 X. i: |) C# P( r+ d审查为 Web 站点和每个虚拟目录配置的默认 Web 权限。检查是否满足以下条件:
1 P% a) s; ~3 T* s" i( A/ J1 C
包括限制 Read 权限的目录。 $ h6 N  |4 X; Q# ^7 P9 G
允许匿名访问的虚拟目录配置为限制 Write 和 Execute 权限。
" g) k/ v% j- e6 U0 o
Write 权限和脚本源代码访问权限只被授予允许内容创作的内容文件夹。还要检查允许内容创作的文件夹是否要求身份验证和安全套接字层 (SSL) 加密。
7 w7 M7 y$ i; p- l7 H4 n4 t' P
IP 地址和域名限制
4 @8 Z/ s9 L& m$ m" t4 ~" \使用 IP 和域名限制来限制对 Web 服务器的访问了吗?如果是这样的话,考虑到 IP 欺骗的风险了吗?
, Z: U/ C  V! T身份验证9 D+ _) S- }' N$ L5 P
检查 Web 站点和虚拟目录的身份验证设置。确保只有站点中可以公开访问的区域支持匿名访问。如果您选择了多个身份验证选项,需要彻底测试应用程序上的效果和身份验证优先级。# ~, w: ^7 Z6 S* G$ m1 o/ b
如果选择的是基本身份验证,检查是否整个站点使用了 SSL 保护凭据。
, }7 R$ N; h7 j9 K; o父路径设置
' w6 s# R* O$ V; o+ N4 b检查是否已经禁用了父路径设置,防止在脚本和应用程序的函数调用(例如 MapPath)中使用“..”。这有助于防止目录遍历攻击。
* @1 ]) b* |8 d6 U要审查父路径设置
4 ~# O" g2 C/ e: P; q# z- N; b
1." s; l# ~% I0 d! e6 `) B
启动 Internet 服务管理器
' Q) v& B0 p/ p) K  b4 l
2.& O5 \+ s6 ^. g
鼠标右击 Web 站点,并单击 Properties) J3 o  ~$ F7 q! q6 c4 K6 J7 I
3.
" e. y$ v! Z0 w
单击 HomeDirectory 选项卡。
5 c( e( y1 k- n3 i0 N
4.; ?" q, ?" e, d. U6 \& U! Q
单击 Configuration1 j7 {1 Z) a+ d
5.4 ?" Q0 z5 P: z: ^
单击 AppOptions 选项卡。 2 ]; K+ c! o- y0 `. q$ w
6.* _. O' `/ ~7 K" L8 D4 D
检查是否清除了 Enableparentpaths 复选框。
3 C' f" C* `7 n* }% p
FrontPage 服务器扩展 (FPSE)
1 Z" k( H) \  H( V' IFrontPage 服务器扩展可以用于访问、创作和管理基于 FrontPage 的 Web 站点。应该使用这些扩展的最新版本以避免安全缺陷。如果您不使用 FPSE,那就禁用它们以减小受攻击面。$ e8 `$ k1 b' ~& {! e
有关更多信息,请参阅“保护 Web 服务器的安全”单元中“第 11 步:站点和虚拟目录”。
3 r+ S5 P0 `1 SISAPI 筛选器- o3 ~; m1 h9 B3 H+ u
确保没有安装未用的 ISAPI 筛选器,以防止这些筛选器中任何潜在的缺陷被人利用。
& U' l$ W6 ^5 I要审查 ISAPI 筛选器
6 w% W2 X' ~$ |7 Z/ b$ ^
1.
. n% Y" U& _! T5 D8 B' i
启动 Internet 信息管理器, Z; |5 e9 Y# u9 [$ g% [' Q  x
2.
$ V+ `7 b, v" f
鼠标右击 server(而不是 Web 站点),然后单击 Properties
" h4 _: k2 ^) @. f8 q& k4 q9 W
3.
4 R( C6 _0 W/ X( ]5 I2 Z3 n
单击紧靠 MasterPropertiesEdit 按钮。
( }* g' x0 T1 H3 X' e$ C7 O
4.
9 S9 m; z% ]: u0 _
单击 ISAPIFilters 选项卡以查看已安装的筛选器。
8 {0 K$ ]8 t; }, F: Z/ I  V
IIS 元数据库
  a0 W' h! E% q' U; Z3 eIIS 元数据库包含 IIS 配置设置,其中有许多但不是所有都是通过 IIS 管理工具配置的。文件本身必须保护,对无法使用 IIS 配置工具维护的特定设置应该进行检查。审查以下问题以确保配置了适当的元数据库:
1 g4 v) v3 V0 \# Q* M
限制访问元数据库了吗?2 j& \/ z0 P7 `" q4 b2 T' V
检查是否元数据库文件上的 ACL 允许系统帐户和管理员有完全控制访问权限。其他帐户都不应该拥有这种访问权限。元数据库文件和位置是:
. \4 d# v# }3 v+ M8 n/ z$ p& ~%windir%\system32\inetsrv\metabase.bin
暴露内部 IP 地址了吗?$ J; t) N* \9 }* K
默认时, IIS 在 HTTP 响应头的内容-位置部分中返回服务器内部 IP 地址。应该通过设置 UseHostName 元数据库属性为 true 防止出现这种情况。要检查是否已经设置,从 \inetpub\adminscripts 目录运行以下命令:
% ?. P2 C3 {# Z2 t( B# M- N. ]adsutil GET w3svc/UseHostName确认属性值已经设置为 true。如果属性没有设置,这个命令将返回消息“The parameter 'UseHostName' is not set at this node”。有关更多信息,请参阅“保护 Web 服务器的安全”单元中“第 14 步:IIS 元数据库”。
$ [2 O; m2 `  B5 _
服务器证书9 `4 X; W: u. A% a  @& S2 H
如果您的应用程序使用 SSL,确保 Web 服务器上安装了有效的证书。为了查看服务器证书的属性,单击 IIS 中 Web 站点 Properties 对话框 Directory Security 页上的 View Certificate。审查下列问题:
% l6 o+ {( V. L: v  |
您的服务器证书到期了吗?3 v7 w6 o6 e; ?
证书链中所有公钥直到可信的根,都是有效的吗?
4 C1 Q3 s# }, B) J% B. m! b3 L+ g
您的证书撤消了吗?
8 Z4 j( Z6 d. F3 Q) `0 W" {
检查是否它没有位于一个证书撤消列表 (CRL) 上,此列表来自颁发该证书的服务器。 , x9 Y- d0 x% c, M1 a
返回页首: A! S& g& S, W
Machine.Config服务器上所有应用程序的 .NET Framework 配置都在 Machine.config 中维护。为了进行安全审查,本部分自顶向下查看 Machine.config 中的设置,并只考虑那些与安全相关的设置。$ t! r: O( }3 t8 m/ e( [$ @
大多数安全设置都包含在 <system.web> 元素之下,但是也有显著的例外,即 Web 服务配置和 .NET Remoting 配置就没有包含在内。Web 服务和 .NET Remoting 配置的审查过程将在本单元后面讲述。' |! f2 w2 N$ T' q* {9 S1 ?' @
有关以下审查问题所提出问题的更多信息和背景,请参阅“保护 ASP.NET 应用程序的安全”单元。以下元素将在本部分中审查: 6 S  v' B" _: B4 G7 `0 P
<trace> . c) I  C9 n& v) p2 A* J# J" A4 F1 q
<httpRunTime>
8 [8 \0 o1 m5 x7 d- ~3 N/ b1 n
<compilation>
8 ]- v4 u* W2 B
<pages> * N+ W+ Q6 x! d" e$ {" ]
<customErrors> 6 b: j$ g8 f; u& `, g: D. U- N! ~
<authentication>
/ _9 n5 G0 ]& e) c- p) L2 N+ Z
<Identity> - S' j7 G! }) k  k! L5 K3 d
<authorization> & x7 B- a7 k& I8 `2 h% V$ l' L+ {
<machineKey> 7 k2 w" n7 h) l1 g' |( G
<trust> 2 e8 L& A8 J0 D; u
<sessionState>
! ^0 A% C7 a8 q& a% K8 a, m
<httpHandlers> ! u0 i+ y5 u; ?* b& o! Z
<processModel> 1 M1 J' z; A8 f* P0 a, U" ?' s
<trace>
* A6 y$ ^- l0 }4 d  Y; _通过以下设置确保禁用跟踪。
' y4 ^% G( J: O) K5 W. k0 [9 t<trace enabled="false" ... /><httpRunTime>7 ]1 H4 }9 d- L/ z
验证 <httpRunTime> 元素的 maxRequestLength 属性的值。您可以使用这个值防止用户上传非常大的文件。最大允许值是 4 MB。
2 ?- K' ^3 b5 O( c5 P- W<compilation>  u3 j& _3 u; @- v
检查是否没有编译调试二进制文件。确保 debug 属性设置为 false
% O8 E: V. V0 E$ {; l! @( l<compilation debug="false" ... /><pages>8 H. G8 p9 C# S# T
<pages> 元素控制着默认页级配置设置。从安全的角度看,应该审查查看状态和会话状态设置。 0 ]# |! B( ]) \  l6 O, n( g
使用查看状态了吗?( p4 S, A' @: |; m$ C
如果 enableViewState 设置为 true,确保 enableViewStateMac 也设置为 true,以保护网络的安全上的查看状态。还要确保审查了 <machineKey> 配置,因为这能够指定与相关的密钥一同使用的加密和散列算法。
$ P; b6 o% u& ?8 D% W8 ?. K/ k* t" `9 D
使用会话状态了吗?8 \" y1 u/ y6 i- a9 j0 O% [
如果 enableSessionState 设置为 true,确保您审查了 <sessionState> 元素配置。
. F2 G( w6 c. I! J5 e0 y  ]
<customErrors>. H1 H. U' C: ^/ H- w- }$ {
确保 mode 属性设置为 On 以确保详细的异常信息没有泄漏给客户端。还要检查是否通过 defaultRedirect 属性指定了默认误页。
# [; w9 ^  o3 d% [<customErrors mode="On" defaultRedirect="/apperrorpage.htm" /><authentication>
8 m( H' H' H5 Z" s) |' q3 |# e3 X这个元素控制着应用程序的身份验证机制。检查 mode 属性,查看配置了哪个身份验证机制,然后使用特定的审查问题检查配置的身份验证模式。
1 J, I8 }# ~2 G9 t4 V<authentication mode="[Windows|Forms|Passport|None"] />窗体身份验证
9 U/ G( A3 B" q5 N审查以下问题以验证窗体身份验证的配置。 , ?. x; X" x9 C  H( O! C$ D5 H4 V, o. t
加密身份验证 cookie 了吗?
$ j3 @- v$ k. r# ]) U2 g" r即使在 SSL 信道上的 cookie 也应该进行加密,并检查完整性,以检测篡改,因为可以通过跨站点脚本 (XSS) 攻击窃取 cookie。检查 <forms> 元素的 protection 属性是否设置为 All7 [# G$ i1 V5 b$ ?
<forms protection="All" .../>   All indicates encryption and verification
在窗体身份验证中使用 SSL 了吗?$ W2 J) |$ t7 w1 D+ s
SSL 能够防止会话劫持和 cookie 重放攻击。检查 <forms> 元素的 requireSSL 属性。
: O8 H" P! l# B' B- q' j<forms requireSSL="true" ... />
限制身份验证 cookie 生存期了吗?# L- V' q6 a( N! P& _4 y
尽量减少 cookie 的超时,以限制攻击者能够使用 cookie 访问应用程序的时间。检查 <forms> 元素的 timeout 属性。
, @% n5 C+ W; B( W( l6 H* U% @& I, r<forms timeout="10" ... />
使用滑动到期时间了吗?
# ]; |/ S* s" J0 T/ r检查 slidingExpiration 属性。slidingExpiration="true" 意味着 cookie 在其最初的持续时间之后一个固定时间到期。超时时钟不会在每个请求之后重置。使用滑动到期时间对于所有页上不使用 SSL 保护 cookie 的应用程序尤其有用。
1 F- m6 e; V) V0 t6 `& F
使用唯一 cookie 路径和名称了吗?
7 R2 ?9 i! _$ S! z% Y检查是否每个 Web 应用程序使用了不同的 cookie 名称和路径。这能够确保已经对一个应用程序进行了身份验证的用户在使用在同一 Web 服务器上寄宿的另一个应用程序时,不会被当成已身份验证的用户处理。检查 <forms> 元素上的 pathname 属性。 % [' c) r( K* L0 p7 j) v
<forms name=".ASPXAUTH" path="/" ... />
使用<credentials>元素了吗?
* Y7 J! M* d, H您不应该在产品服务器上使用 <credentials> 元素。这个元素只用于开发和测试目的。凭据应该存储在 Microsoft Active Directory® 目录服务或者 SQL Server 中。 ) A8 h( t( M" D: |! i! D2 I0 m
您如何存储凭据?
( I# U4 [9 q7 A2 A5 v如果您的应用程序使用 Windows 身份验证,凭据将存储在 Active Directory 中,后者将凭据的管理问题传给操作环境。如果您的应用程序使用窗体身份验证,确保您使用 SQL Server 或者 Active Directory 凭据存储区。
) ]! }! ^$ U1 E: w+ P1 ?
存储密码散列值了吗?" c9 o+ r: f/ B; }' z
确保密码没有存储在数据库中。相反,存储带有附加 salt 值的密码散列值以阻止词典攻击。 / J9 b8 [+ b! p- a
使用坚固的密码了吗?
3 G! S" N! ~- @$ J您的应用程序应该强制使用坚固的密码。实现这一点的很好方式,是在窗体登录页中使用正则表达式。 : w& [+ Q. \6 J& v+ H6 f: u) C
以下问题有助于验证在 <Identity> 元素上指定的模拟配置:
: u! D5 z" t' w* Y* U* M
模拟原始调用方了吗?/ q2 A: U9 K6 O& R% I3 x4 B7 `
如果 impersonate 属性设置为 true,且您没有指定 userName 或者 password 属性,模拟经 IIS 身份验证的标识,该标识可能是匿名 Internet 用户帐户。 : k+ Y# I$ U5 l7 S
确保 ACL 配置为允许模拟的标识只访问那些需要获得访问权限的资源。   H. m" y  L9 O$ W" I1 N+ v4 u! U
模拟固定标识了吗?  J) S! f2 I6 u" q( z3 n
如果您模拟和设置了 userNamepassword 属性,模拟一个固定标识,这个标识是用于资源访问的。
: k, F; Q  Q% q确保您不在 <Identity> 元素上指定明文凭据。相反,在注册表中使用 Aspnet_setreg.exe 存储加密凭据。
2 x/ S5 [3 ^! f, G在 Windows 2000 上,这个方法将强制您将“Act as part of the operating system”用户权限授予 ASP.NET 进程帐户,这是不推荐的。有关替代方法,请参阅“保护 ASP.NET 应用程序的安全”单元。 ) r) n  L; c7 K8 M- _: U
这个元素控制着 ASP.NET URL 授权,具体而言就是 Web 客户端获取访问特定的文件夹、页和资源的权限的能力。 ( m! v/ c$ L3 X( o1 k
使用正确格式的用户名和角色名了吗?
9 \. b+ F$ \# m$ A! g) @. y当有 <authentication mode="Windows" /> 时,将授权 Windows 用户和组帐户进行访问。
4 c9 T5 n) b6 J用户名的形式是“DomainName\WindowsUserName”。角色名的形式是“DomainName\WindowsGroupName”。 ) G/ v. b; a& L& O: p
本地管理员组称为“BUILTIN\Administrators”。本地用户组称为“BUILTIN\Users”。
$ Z0 u: u! x( `0 j8 ]: d当有 <authentication mode="Forms" /> 时,将授权经过应用程序身份验证的标识。通常,针对从数据库检索的角色进行授权。角色名是特定于应用程序的。
4 X' H; W! s; S4 l) f+ @2 h& ^9 M<machineKey>* A/ @. `; `# [3 B: C: u
这个元素是用来指定加密和验证密钥,以及用来保护窗体身份验证 cookie 和页级查看状态的算法的。   _3 w2 p9 y! x
在同一服务器上运行多个应用程序吗?1 e* a9 U2 c7 U5 E3 d8 [( m( j
如果是这样的话,使用 IsolateApps 设置以确保每个 Web 应用程序都生成不同的密钥。 ' N4 a$ N( M* o( J3 i3 s
<machineKey validati             decrypti validation="SHA1"/>
运行在 Web 服务器场中吗?1 c! F: T7 U4 p- [! e. k
如果是这样的话,确保您使用特定的机器密钥,将它们复制到场中的所有服务器。
! ?$ |! ^% |0 O2 N$ I% a
保护查看状态了吗?
# a7 L6 s; s) U! j) G2 H如果您保护查看状态,例如,通过设置 <pages> 元素的 enableViewSetMac="true",在 <machineKey> 元素上设置 validation="SHA1"(安全散列算法)或者 "3DES"。如果您还要通过设置 <forms> 元素的 protection="All" 加密窗体身份验证 cookie 的话,三重数据加密标准 (3DES) 设置是必需的。 ( P2 M; Q3 j* c* U
<trust>5 v4 j9 @" e2 [
<trust> 元素确定了用来运行 ASP.NET Web 应用程序和 Web 服务的代码访问安全信任级。
3 d8 _% a8 C8 z& p
运行的是什么版本的 .NET Framework
# w/ v. c$ V! d- Q/ X& s( F$ z; W5 D如果您运行 .NET Framework 1.0,那么信任级必须设置为 Full。如果版本等于或者大于 1.1,可以将其更改为以下设置之一: + p1 ?; B- j) ]
<!--  level="[Full|High|Medium|Low|Minimal]" --><trust level="Full" originUrl=""/>  
使用什么信任级?9 @. G, {8 V/ F; N8 A1 ^
根据安全策略和与开发小组的协议,可以在 Web.config 或者 Machine.config 中为应用程序设置适当的信任级。
+ k8 N0 Z8 L, M' u- f& v7 f2 p6 n<sessionState>
% s" _3 T3 h0 F, q4 r% q+ U* [2 CsessionState 元素配置应用程序的用户会话状态管理。审查以下问题: 0 d5 ]2 X& h* P2 \* O# I# \9 p7 Z. _: _
使用远程状态存储区了吗?
' J- |3 a4 G+ c/ @通过查看 mode 属性检查状态存储区。
, I# z) c7 [- f<sessionState mode="Off|Inproc|stateServer|SQLServer" ... />如果您使用远程状态存储区,而且 mode 属性设置为 stateServer 或者 SQLServer,应该分别检查 stateConnectionStringsqlConnectionString 属性。因此凭据并不包括在数据库连接字符串中,确保连接字符串是以加密格式在注册表中使用 Aspnet_setreg.exe 工具保护的,或者用 Windows 身份验证连接 SQL Server 状态存储区。 , q$ }+ s: ]9 {, s7 T
以下配置说明了当使用 Aspnet_setreg.exe 加密注册表中字符串时,stateConnectionString 的样子。
/ e9 H. r2 |. j* s<!-- aspnet_setreg.exe has been used to store encrypted details --><!-- in the registry. --><sessionState mode="StateServer"          stateC />
对状态数据库使用 Windows 身份验证了吗?
/ A7 A3 l* y$ B$ \8 R3 ]如果您使用 SQL Server 状态存储区,应该检查是否使用 Windows 身份验证连接状态数据库。这意味着凭据并不存储在连接字符串中,凭据不会在网络上传输。 6 ^- p$ S7 f8 t6 y+ L6 z) s  o
如果您必须使用 SQL 身份验证,确保连接字符串在注册表中加密,而且数据库服务器上安装了服务器证书,确保凭据在网络上加密。. E! @4 |4 e: ]" T
<httpHandlers>; A% k1 n. }) R* k0 o# h
这个元素列出了处理特定文件类型请求的 HTTP 处理程序。检查以确保您禁用了所有未用的文件类型。  J+ C1 c+ d1 Z6 {* B/ S, r' e
映射未用的文件类型到 System.Web.HttpForbiddenHandler 以防止对它们的 HTTP 检索。例如,如果您的应用程序不使用 Web 服务,将如下映射 .asmx 扩展名:
' y1 Z# ?+ M$ U  M<httpHandlers>  <add verb="*" path="*.asmx" type="System.Web.HttpForbiddenHandler"/></httpHandlers><processModel>7 M; W5 g3 k" O$ M  k$ _8 \/ a5 G
ASP.NET 辅助进程运行所用标识是通过 Machine.config 中 <processModel> 元素的设置控制的。 以下审查问题有助于验证进程标识设置: 6 t" M& L, E* ^7 B, q5 _0 T1 @6 e- C
使用什么标识运行 ASP.NET
$ N9 |! [, k0 m8 `/ U检查 userNamepassword 属性。理想情况下,使用以下配置使 ASP.NET 进程运行在最低特权 ASPNET 帐户下。
, M) @, T! N' A, j- J6 R' Z# z: W<processModel userName="Machine" password="AutoGenerate" . . ./>
加密<processModel>凭据了吗?
' k- P) d4 s" u( f  ?2 a% L如果您使用自定义帐户,确保帐户凭据没有以明文在 Machine.config 中指定。确保 Aspnet_setreg.exe 实用工具已经用来在注册表中存储加密凭据。如果已经使用了该工具,userNamepassword 属性与如下所示的设置类似: 7 u: l- k$ L; ^
<processModel        userName="registry:HKLM\SOFTWARE\YourSecureApp\processModel\                  ASPNET_SETREG,userName"        password="registry:HKLM\SOFTWARE\YourSecureApp\processModel\                  ASPNET_SETREG,password" . . ./>
使用最低特权帐户了吗?
, H( c6 f( n+ m) b默认 ASPNET 帐户是设计来运行 ASP.NET 的最低特权本地帐户。为了将其用于远程资源访问,需要在远程服务器上创建一个重复的帐户。或者,您也可以创建一个最低特权域帐户。
* Q. Q3 I' z4 g3 y检查是否帐户不是用户组的成员,并在本地安全策略工具中查看用户权限指派,以确认没有向其授予任何扩展或者不必要的用户权限。确保没有向其授予“Act as part of the operating system”用户权限。 - t3 ]; _+ G5 b* A+ w
返回页首% P1 o; }! Q6 _8 a( ]0 L% G
Web 服务审查中此阶段的目的是标识 Web 服务配置中的缺陷。有关本部分中审查问题所提出的问题的进一步的背景信息,请参阅“保护应用程序服务器的安全”单元和“保护 ASP.NET 应用程序的安全”单元。. g3 \, ~# S8 K( C; x$ }* ~
使用以下问题帮助审查 Web 服务的安全配置:
7 C0 i% N  T% l; `, a0 A
禁用文档协议了吗?6 X9 L  A  n3 d: y1 J
如果您不想公开 Web 服务终结点,则可以从 Machine.config 的 <protocols> 元素中删除 Documentation 协议并手工分发 Web 服务描述语言 (WSDL) 文件到特定的 Web 服务使用者。
0 s3 o" ]" }8 D7 w# [9 r
禁用 HTTP Get Post 协议了吗?
' Q$ ?: H0 ~. p通过禁用(注释掉)Machine.config 文件的 <protocols> 元素中 HttpGetHttpPost 协议,将有助于减少 Web 服务的受攻击面。 : f! j( Q+ J5 z8 `
限制对 WSDL 的访问了吗?" m  F8 ~4 b& z
如果您在 Web 服务器上存储所生成的 .WSDL 文件,将它们分发给使用者,确保文件由适当的 ACL 进行了保护。这防止了恶意用户更新或者代替 WSDL,从而指向与期望 URL 不同的终结点。
/ T% ?' P4 f: [) d5 n; S
SOAP 请求或者响应中传递敏感数据了吗?# G6 A4 L( L& s# m
如果您的 Web 服务处理敏感数据,您如何保护网络的安全上的数据并应对网络侦听威胁呢?使用 SSL 或者 IPSec 加密信道,或者通过使用 XML 加密加密部分消息了吗? ! u, T( I* d4 o& D
您如何对调用方进行身份验证?$ A4 {! ~" o% U) ^- c
如果您的 Web 服务公开了受限的操作或者数据,它需要对调用方进行身份验证以支持授权。审查 Web 服务是如何对其客户端进行身份验证的。 " f1 l) n7 M4 H! U# K- A3 h7 j' {
SOAP 头中传递凭据了吗?
6 k6 g' h$ F0 F: Y  Y& j& l/ R& j3 i如果您在 SOAP 头中传递凭据,它们是以明文传递的吗?如果是,确保使用了加密信道。
. T% b: b* {) B- o
返回页首5 R7 J8 l2 q4 g1 Z6 p! @3 j
企业服务本部分标识了当审查企业服务应用程序和组件时,应该考虑的关键审查点。有关本部分中所提出问题的更多信息,请参阅“保护应用程序服务器的安全”单元。
1 c+ |! w( Q9 W& r0 \当审查企业服务应用程序时,考虑以下问题:
7 r! ^! c( J3 h+ E# q; z
帐户
/ n* n2 Q3 D7 U" y" Y
文件和目录
1 s0 |) F* [7 q0 X& s' E2 r
身份验证7 Y2 n# l# \: ]" ?* X, ?; n
授权
3 o; |; Y" d  L' j8 D4 B
远程服务组件# H- t$ m8 K# ~
帐户
4 @- H, z; T) e$ U6 B* A/ S如果您使用企业服务服务器应用程序,应该检查使用了哪个帐户来运行应用程序。这显示在组件服务中应用程序的 Properties 对话框的 Identity 页中。需要审查以下问题: . g! y) `# f* U. _
使用最低特权帐户了吗?; {# e3 e% W4 T+ K- P: l
检查用来运行企业服务服务器应用程序的帐户,确保它们配置为最低特权帐户,有受限的用户权限和访问权限。如果您使用进程帐户访问下游数据库,应该确保数据库登录在数据库中受限。
- M* n2 Q/ u6 {# A+ [" y3 B4 D
使用交互式帐户了吗?
" c$ W; L& v: `5 I在产品服务器上不要使用交互式帐户。这个帐户只是为了在开发和测试期间使用的。
- s% d4 c9 l" w. g
文件和目录
& S0 N; T' Z  E' {  g8 D" m0 |审查以下问题,以确保您适当地使用 NTFS 权限保护与企业服务应用程序相关的各种文件: ' ]" E& ]& Z3 ^. ]( Z
保护 COM+ 编录了吗?/ |7 L$ I: p1 U
COM+ 编录保留着 COM+ 应用程序的配置数据。确保以下保留着编录文件的文件夹使用受限的 ACL 进行了配置。 $ o! F! q  V8 T/ ~) e
%windir%\registration配置以下 ACL: & E/ q. }0 H) ?
Administrators: Read, WriteSystem: Read, WriteEnterprise Services Run-As Account(s): Read
保护 CRM 日志文件了吗?
# p; G5 ^, ~5 C# Y7 |如果您的应用程序使用补偿资源管理器,CRM 日志文件 (.crmlog) 应该用 NTFS 权限保护,因为日志文件可能包含敏感的应用程序数据。 % P4 G0 @5 n8 F/ H6 q
保护您的应用程序 DLL 了吗?. \, {5 S' ~) {* h5 q8 [3 Z
确保用来保存应用程序 DLL 的文件夹通过以下受限的 ACL 进行了配置。 + G' }6 l5 b  I  X" Q8 Y  {
Users: ExecuteApplication Run as account: ExecuteAdministrators: Read, Write and Execute有关更多信息,请参阅“保护应用程序服务器的安全”单元。
6 A+ D8 R: h2 |3 t4 ^. \: E7 h
身份验证! Q' v7 [2 B0 k. J  Q' \
服务组件可以寄宿在一个库应用程序中,该库应用程序运行在客户端进程地址空间,或者在运行在不同 Dllhost.exe 实例中的服务器应用程序中。这是通过组件服务中的应用程序的 Properties 对话框的 Activation 页上指定的激活类型确定的。企业服务库应用程序的客户端进程通常是一个 ASP.NET Web 应用程序进程。7 [: A5 a" y8 ~0 }+ B# G  h% B
以下讨论的设置都是在组件服务中应用程序的 Properties 的对话框 Security 页上指定的。
, W! S/ d( `* G; I" q% m  m服务器应用程序
8 d! s+ f! n/ I: O3 ~如果 Activation 类型设置为服务器应用程序,审查以下问题:
/ m: L' {' Y9 T4 o9 r* B; C
防止匿名访问了吗?
; o0 E) X- q6 O" b+ w% O9 I检查是否您的应用程序至少使用调用级身份验证,确保客户端每次进行方法调用时都进行身份验证。这能够防止匿名访问。 5 ?" q1 [# f: |, R/ \2 i" |1 h
使用什么模拟级?
  M5 X( n7 j$ e8 \" U; I! K9 x检查以确保您至少使用标识级模拟,以允许下游系统标识您的服务组件。默认时,这是应用程序 run-as 帐户决定的进程标识。如果您的服务组件使用编程模拟,这可以是一个模拟的标识。只在需要下游系统能够使用您的服务组件标识访问远程资源时,才使用委托级。
" ?+ O6 [! X. y
库应用程序
: D. R: L( V0 C9 y如果激活类型设置为库应用程序,身份验证和模拟设置将从宿主进程继承。本部分中的审查问题假设 ASP.NET 进程是宿主进程。 , o0 C1 J) h# A. U1 K
禁用身份验证了吗?
: l- l( ?# v5 v" }  S. ]* x为了检查,查看应用程序的 Properties 对话框的 Security 页上设置的 Enable authentication 复选框。您不应该禁用身份验证,除非有特定的需求,例如需要处理来自远程服务组件的未经身份验证的回调。 7 A; ~+ p0 O  _% L: S3 O
使用什么身份验证级?
; w! x) y0 `; O4 l在 Machine.config 中的 <processModel> 元素上指定的身份验证级,控制着对远程服务组件或者 DCOM 组件外出调用使用的身份验证级。使用这个值和远程服务器配置的值中较大的一个。检查 <processModel> 元素的 comAuthenticationLevel 设置: & f7 j+ B) S. P3 L" T- O, j9 ^; ~
使用什么模拟级?
: S5 {1 r0 v  ?2 }' Z0 G% |这将影响从库组件到其他远程组件的外出调用。检查 Machine.config 中 <processModel> 元素的 comImpersonationLevel 属性。
! _5 k9 n) A3 w+ [4 h<processModel comImpersonationLevel=              "Default|Anonymous|Identify|Impersonate|Delegate" .../>
授权# ~7 X5 W$ D( t1 n
企业服务应用程序中的服务组件使用基于 COM+ 角色的安全来授权调用方。审查以下问题以确保适当授权: 4 x8 v% g4 v7 X$ u$ U* _: S
启用访问检查了吗?5 ?6 }+ y2 j) O  ?4 D, _: v
这控制着是否启用 COM+ 授权。检查组件服务中应用程序的 Properties 的对话框 Security 页上是否选择了 Enforce access checks for this application
$ z! Y! j7 P8 M+ ~
使用什么安全级?
' D) Q: h2 }1 `$ X2 M0 W2 S. r检查在组件服务中应用程序的 Properties 的对话框的 Security 页上指定的 Security level。应用程序应该使用进程级和组件级访问检查以支持细粒度的授权。这允许应用程序使用角色来控制对特定的类、接口和方法的访问。 + B5 M$ @+ _2 R/ Z/ u1 R
进程级和组件级访问检查必须为库应用程序启用,否则无法使用基于角色的授权。
# h% i2 a) U7 n' h' x4 q
实施组件级访问检查了吗?, a3 m' B9 g0 C9 u
为了在组件级、接口级和方法级支持授权检查,每个组件都必须在 COM+ 编录中适当地进行配置。检查应用程序中的每个组件,以确保选择了组件的 Properties 对话框 Security 页上的 Enforce component level access checks
; k6 d. K) ^' p/ o' ~" f7 v
远程服务组件+ e8 z' i: u  T! T( @
以下问题在您使用远程服务组件并通过网络通信时适用。典型的场景是 ASP.NET 客户端与远程应用程序服务器上的一个企业服务应用程序通信。 & m6 b  ?& E% w" c8 o! E
传递敏感数据吗?# ?5 M4 G8 A4 j
如果是这样的话,采用了什么机制来应对网络侦听威胁呢?确保客户端和服务器之间的链路在传输级(例如通过 IPSec)进行了加密。还可确保您的企业服务应用程序为数据包私密级身份验证进行了配置,这将强制对发送到应用程序和从应用程序而来的所有数据包使用 RPC 加密。   q! p" ]% J8 ~
通过防火墙通信吗?
3 j1 t. G; f8 e企业服务使用 DCOM,后者继而又要使用 RPC 通信。RPC 通信要求端口 135 在防火墙上打开。审查您的防火墙和企业服务配置,确保只打开了最少的额外端口。 ( o! g6 v: L: S# Q# v
DCOM 动态分配的端口范围可以是受限的,还可以用静态终结点映射来指定单独的端口。有关更多信息,请参阅“保护应用程序服务器的安全”单元。 ( p# _  U7 l6 _8 m
返回页首
4 r1 n1 |+ K; _  ]$ G远程处理本部分标识了在审查应用程序对 .NET Remoting 的使用时应该考虑的关键审查点。有关本部分中所提出问题的更多信息,请参阅“保护应用程序服务器的安全”单元。" i7 s9 K( B0 M9 O! F. A6 D
当审查 .NET Remoting 解决方案时,首先标识使用哪一台主机运行远程组件。如果您使用带 HttpChannel 的 ASP.NET 主机,需要检查是否 IIS 和 ASP.NET 安全进行了适当配置,来为您的远程组件提供身份验证、授权和安全通信服务。如果您使用自定义主机和 TcpChannel,需要审查保护组件的方式,因为这个主机和信道组合需要自定义身份验证和授权解决方案。
; T  ]5 V$ w& j' l0 m# Q端口的注意事项" y# x/ S$ ~1 s' q. n1 ^: V
远程处理并非设计用于 Internet 客户端。检查您的组件侦听的端口是否不能被 Internet 客户端直接访问。这一(类)端口通常在服务器端配置文件中的 <channel> 元素上指定。
$ i$ T- p9 Y) L% p9 ~5 O: f寄宿在带 HttpChannel ASP.NET
  X- w" ]( \: o6 ?如果您使用 ASP.NET 主机,审查以下项:
8 k4 C4 C# B& l, q) Q
您如何保护网络的安全上的敏感数据?
; \. A& t0 C, W, q使用 SSL 或者 IPSec 吗?没有 SSL 或者 IPSec,传递到远程组件和从远程组件传来的数据容易遭到信息泄漏和篡改的威胁。审查采取了哪些措施应对网络侦听威胁。 ! ~& l5 c6 L  D0 q$ X+ J- i
您如何对调用方进行身份验证?" e1 g/ h4 o' e
确保 IIS 中禁用对应用程序的虚拟目录的匿名访问。还要检查您是否使用了 Windows 身份验证。应用程序的 Web.config 应该包含以下配置。 ( u6 |, w: m8 K% b5 E8 u0 E4 S
<authentication mode="Windows" />
使用ASP.NET 文件授权了吗?
- n/ E9 s+ q+ C, c5 V8 s+ i7 A  m如果没有,为什么呢?您可以通过创建一个 .rem 或者 .soap 文件并配置文件的 NTFS 权限,使用 ASP.NET 文件授权控制对远程处理应用程序终结点的访问。ASP.NET FileAuthorizationModule 然后将对组件的访问进行授权。有关更多信息,请参阅“构建安全远程组件”单元中的“授权”。 . H# c# {6 \* ]
使用 URL 授权了吗?
' Z; R3 U! P* ~1 U检查应用程序是否使用 <authorization> 元素。通过应用 <allow> 和 <deny> 标记,使用 ASP.NET UrlAuthorizationModule
% ~+ \) I) i0 A0 a9 I, ^3 w3 u
防止详细的错误返回客户端了吗?
5 j6 b$ N& v& }% o  h$ ]  q2 W检查应用程序的配置,确保正确配置了 <customErrors> 元素以防止详细的错误返回客户端。确保 mode 属性设置为 On,如下所示。 4 m8 S4 k  f$ n  _7 N5 Q7 x3 m; P
<customErrors mode="On" />
使用了什么标识运行 ASP.NET+ r4 a/ _8 H0 b+ L
检查是否使用了最低特权帐户运行 ASP.NET,例如默认 ASPNET 帐户,或者在 Windows Server 2003 上的网络服务帐户。
& k0 e, Y, I0 O% n+ ?( G- h+ |
寄宿在带 TcpChannel 的自定义进程中
' q5 V8 H2 ]: I- r5 Y; E5 r' q* X9 E如果您使用自定义主机进程,例如一个 Windows 服务,审查以下项。
4 w, ^: t1 b$ K, @5 I
您如何保护网络的安全上的敏感数据?
& U  N8 c6 s' {- t9 A! @保护从客户端到服务器的信道了吗?可以使用传输级 IPSec 加密,或者应用程序可以使用自定义加密接收器加密请求和响应数据。 6 C, z- T3 y0 A: h1 D9 c
您如何对调用方进行身份验证?1 r' ^1 a0 k% U0 n
TcpChannel 没有提供身份验证机制,所以必须开发您自己的机制。审查您的应用程序是如何对其调用方进行身份验证的。
6 M, J; g8 D( O3 j7 j0 \" d6 {
限制客户端了吗?
6 g. l3 k1 N- P通过 TcpChannel 的远程处理是设计用于可信服务器场景中的,其中远程组件信任其客户端。限制能够连接远程组件的客户端范围了吗(例如通过使用 IPSec 策略进行限制)? , Q7 P7 l" L% o0 _
使用最低特权进程标识了吗?
3 L6 ~( D8 P" c6 f8 S" \审查使用哪个帐户运行自定义宿主进程,并确保它配置为最低特权帐户。 4 p) Q( i7 }2 H8 v$ n+ |
返回页首1 d/ e( i3 O' b( I
数据库服务器配置审查中此阶段的目的是标识 SQL Server 数据库服务器配置中的缺陷。有关本部分中审查问题所提出的问题的进一步的背景信息,请参阅“保护数据库服务器”单元。3 C- o2 b" \- t8 ^& j0 g
要帮助集中和组织审查过程,将审查问题划分为以下配置类别:
# E' x6 a3 x! f2 V+ @( M9 V( Z
修补程序和更新
5 n+ U) h) J! o8 x$ f
服务* b: T8 y0 l5 H0 E* I( [
协议
- ~# r2 j: \0 M3 ^" h
帐户% K, T, k6 B+ h2 q9 h
文件和目录
. Y, P$ C8 m3 t: C5 x: ~
共享! [4 A. X% C+ l! f) M7 i
端口& b; I1 B1 n3 o  \4 u  U. m
注册表: z& v: n: e, F5 q, M
审核和日志记录7 o$ D8 j9 k. m# o" b! W0 x
SQL Server 安全* h, H/ J% w' ]5 I( p
SQL Server 登录、用户和角色
$ J1 U9 @9 g4 }6 V. c
修补程序和更新+ F4 S0 ^: p. C, c( o4 ?4 Y
检查是否您的服务器已经使用最新的服务包和软件修补程序进行了更新。这包括操作系统和 SQL Server 的服务包和修补程序。5 |+ V: ]! P( M% e: h% i7 {
确保您已经运行 Microsoft Baseline Security Analyzer (MBSA) 工具标识常见的 Windows 和 SQL Server 缺陷,并标识了缺少的服务包和修补程序。9 R% y- I  s" ]3 g2 M  Z, M3 n
通过修补已标识的缺陷,并安装最新的修补程序和更新,对 MBSA 的结果做出反映。有关更多信息,请参阅“保护数据库服务器”单元中的“第 1 步:修补程序和更新”。
4 l, P8 F7 `- q4 s5 ^服务
* ]5 L! k( F5 ?& \7 B确保只启用了那些必需的服务。检查是否所有其他服务都已经禁用,这样能够减小服务器的受攻击面。
6 a% v# C% x- K1 P. x  Y
运行了哪些 SQL Server 服务?4 `4 {- \2 I: x: N" W0 {. b5 H+ \9 z! ?
SQL Server 安装了四个服务。如果您只需要基本功能,那么就禁用 Microsoft 搜索服务、MSSQLServerADHelper 服务和 SQLServerAgent 服务以减小服务器的受攻击面。
4 N; [) M: I) m& n+ b
使用分布式事务了吗?
% a5 c' M0 [/ \9 M如果您的应用程序使用 COM+ 事务服务管理与 SQL Server 的事务,那么 Microsoft 分布式事务协调程序 (DTC) 服务在数据库服务器上是必需的。 2 \' r$ M5 a1 i+ I) _# _
如果您不使用分布式事务,一定要禁用 DTC 服务。 : x/ f& f3 K( J5 J! @* b
协议$ z7 a) O. q% k
通过防止使用不必要的协议,能够减小受攻击面。审查以下问题:
5 X  M3 X0 {1 j9 i, Y, O/ Y8 D% I
SQL Server 配置了哪些协议?0 s0 {& b, n! m
SQL Server 支持多个协议。使用服务器网络实用工具检查是否只启用了 TCP/IP 协议支持。
8 V& I6 W; g) Y
加固 TCP/IP 堆栈了吗?2 Z* J7 G0 m5 q0 b
要检查服务器上的堆栈是否加固,使用 Regedt32.exe 并检查以下注册表项:
* W( L3 o4 P% y2 o# `! o2 _HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters如果存在以下子项,则指示 TCP/IP 堆栈已经加固:SynAttackProtectEnableICMPRedirectEnableReadGWDetect( u7 L& j" k& X' a! Z
有关完全加固堆栈所必需的项和相应项值的完整列表,请参阅本指南“如何做”部分中的“如何加固 TCP/IP 堆栈”。
0 b4 M0 L0 f' I, n" j' E
帐户
8 n; o5 _/ {: `5 i5 G& T8 n通过询问以下问题,审查数据库服务器使用的帐户: 3 K; S6 l% h, y- B' Y
是使用最低特权帐户运行 SQL Server 吗?
" n3 A& ?; }" F) P  l/ W1 w审查使用了哪个帐户运行 SQL Server,确保它是最低特权帐户。不应该是管理性帐户或者强大的本地系统帐户。还要确保帐户不是本地计算机上用户组的成员。 : H- _  X) R( H4 m5 J6 w- a
删除或者禁用未用帐户了吗?: T. R  \- M) `' s) K% O
审核服务器上的本地帐户,检查是否所有未用的帐户都已经禁用。
. S, N, K/ p1 _1 T( g% b1 B4 s
禁用 Guest 帐户了吗?; U1 s  F+ K2 D5 N2 N
检查是否禁用了 Windows guest 帐户,以限制匿名连接您的数据库服务器。 : C) J3 N! d, W+ T
创建新的管理员帐户了吗?
8 r/ W6 F/ X3 d% g" A! D默认本地管理员帐户是攻击的一个主要