我们通过以下几个方面对您的系统进行安全加固：
1. 系统的安全加固：我们通过配置目录权限，系统安全策略，协议栈加强，系统服务和访问控制加固您的系统，整体提高服务器的安全性。
2. IIS手工加固：手工加固iis可以有效的提高iweb站点的安全性，合理分配用户权限，配置相应的安全策略，有效的防止iis用户溢出提权。
3. 系统应用程序加固，提供应用程序的安全性，例如sql的安全配置以及服务器应用软件的安全加固。
系统的安全加固：
1.目录权限的配置：
1.1 除系统所在分区之外的所有分区都赋予Administrators和SYSTEM有完全控制权，之后再对其下的子目录作单独的目录权限，如果WEB站点目录，你要为其目录权限分配一个与之对应的匿名访问帐号并赋予它有修改权限，如果想使网站更加坚固，可以分配只读权限并对特殊的目录作可写权限。
1.2 系统所在分区下的根目录都要设置为不继承父权限，之后为该分区只赋予Administrators和SYSTEM有完全控制权。
1.3 因为服务器只有管理员有本地登录权限，所在要配置Documents and Settings这个目录权限只保留Administrators和SYSTEM有完全控制权，其下的子目录同样。另外还有一个隐藏目录也需要同样操作。因为如果你安装有PCAnyWhere那么他的的配置信息都保存在其下，使用webshell或FSO可以轻松的调取这个配置文件。
1.4 配置Program files目录，为Common Files目录之外的所有目录赋予Administrators和SYSTEM有完全控制权。
1.5 配置Windows目录，其实这一块主要是根据自身的情况如果使用默认的安全设置也是可行的，不过还是应该进入SYSTEM32目录下，将 cmd.exe、ftp.exe、net.exe、scrrun.dll、shell.dll这些杀手锏程序赋予匿名帐号拒绝访问。
1.6审核MetBase.bin，C:WINNTsystem32inetsrv目录只有administrator只允许Administrator用户读写。
2.组策略配置:
在用户权利指派下，从通过网络访问此计算机中删除Power Users和Backup Operators
启用不允许匿名访问SAM帐号和共享
启用不允许为网络验证存储凭据或Passport
从文件共享中删除允许匿名登录的DFS$和COMCFG
启用交互登录：不显示上次的用户名
启用在下一次密码变更时不存储LANMAN哈希值
禁止IIS匿名用户在本地登录
3.本地安全策略设置:
开始菜单—>管理工具—>本地安全策略
A、本地策略——>审核策略
审核策略更改 成功 失败
审核登录事件 成功 失败
审核对象访问失败
审核过程跟踪 无审核
审核目录服务访问失败
审核特权使用失败
审核系统事件 成功 失败
审核账户登录事件 成功 失败
审核账户管理 成功 失败
注：在设置审核登陆事件时选择记失败，这样在事件查看器里的安全日志就会记录登陆失败的信息。
所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。常见的SQL注入式攻击过程类如：⑴ 某个ASP.NET Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码。
⑵ 登录页面中输入的内容将直接用来构造动态的SQL命令，或者直接用作存储过程的参数。下面是ASP.NET应用构造查询的一个例子：
System.Text.StringBuilder query = new System.Text.StringBuilder(
"SELECT * from Users WHERE login = '")
.Append(txtLogin.Text).Append("' AND password='")
. Append(txtPassword.Text).Append("'")
⑶ 攻击者在用户名字和密码输入框中输入"'或'1'='1"之类的内容。
⑷ 用户输入的内容提交给服务器之后，服务器运行上面的ASP.NET代码构造出查询用户的SQL命令，但由于攻击者输入的内容非常特殊，所以最后得到的SQL命令变成：SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'。
⑸ 服务器执行查询或存储过程，将用户输入的身份信息和服务器中保存的身份信息进行对比。
⑹ 由于SQL命令实际上已被注入式攻击修改，已经不能真正验证用户身份，所以系统会错误地授权给攻击者。
如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询，他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。
系统环境不同，攻击者可能造成的损害也不同，这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限，攻击者就可能对数据库的表执行各种他想要做的操作，包括添加、删除或更新数据，甚至可能直接删除表。
⑴ 对于动态构造SQL查询的场合，可以使用下面的技术：
第一：替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”显然会得到与“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的结果。
第二：删除用户输入内容中的所有连字符，防止攻击者构造出类如“SELECT * from Users WHERE login = 'mas' -- AND password =''”之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。
第三：对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。 ⑵ 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。
⑶ 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。
⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。
⑸ 将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。
⑹ 检查提取数据的查询所返回的记录数量。
直接申请并安装SSL证书就行了。SSL安全证书简单讲HTTPS是一种加密传输、身份认证的网络通信协议，通过在客户端浏览器与WEB服务器之间建立一条SSL安全通道，其作用就是对网络传输中的数据进行记录和加密，防止数据被截取或窃听，从而保证网络数据传输的安全性。
1份SSL证书包括一个公共密钥和一个私用密钥：公共密钥主要用于信息加密，私用密钥主要用于解译加密信息。当浏览器指向一个安全域时，安装证书后SSL会同步确认客户端和服务器，并在两者之间建立一种加密方式和一个唯一的会话密钥，这样便可保证通话双方信息的完整性和保密性。现在互联网中大部分还是传统的HTTP传输协议，使用这类协议无法保证传输信息的安全性，相当于信息处于“裸奔”状态中，这在当前的网络里具有非常大的安全隐患。而HTTPS协议能对传输的互联网信息进行加密处理，从而在一定程度上保证了信息的安全性，也不会在传输过程中轻易被黑客获取。
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）