如何保障Web服务器安全

不但企业的门户网站被篡改、资料被窃取，而且还成为了病毒与木马的传播者。有些Web管理员采取了一些措施，虽然可以保证门户网站的主页不被篡改，但是却很难避免自己的网站被当作肉鸡，来传播病毒、恶意插件、木马等等。笔者认为，这很大一部分原因是管理员在Web安全防护上太被动。他们只是被动的防御。为了彻底提高Web服务器的安全，笔者认为，Web安全要主动出击。具体的来说，需要做到如下几点。 一、在代码编写时就要进行漏洞测试 现在的企业网站做的越来越复杂、功能越来越强。不过这些都不是凭空而来的，是通过代码堆积起来的。如果这个代码只供企业内部使用，那么不会带来多大的安全隐患。但是如果放在互联网上使用的话，则这些为实现特定功能的代码就有可能成为攻击者的目标。笔者举一个简单的例子。在网页中可以嵌入SQL代码。而攻击者就可以利用这些SQL代码来发动攻击，来获取管理员的密码等等破坏性的动作。有时候访问某些网站还需要有某些特定的控件。用户在安装这些控件时，其实就有可能在安装一个木马(这可能访问者与被访问者都没有意识到)。 为此在为网站某个特定功能编写代码时，就要主动出击。从编码的设计到编写、到测试，都需要认识到是否存在着安全的漏洞。笔者在日常过程中，在这方面对于员工提出了很高的要求。各个员工必须对自己所开发的功能负责。至少现在已知的病毒、木马不能够在你所开发的插件中有机可乘。通过这层层把关，就可以提高代码编写的安全性。 二、对Web服务器进行持续的监控 冰冻三尺、非一日之寒。这就好像人生病一样，都有一个过程。病毒、木马等等在攻击Web服务器时，也需要一个过程。或者说，在攻击取得成功之前，他们会有一些试探性的动作。如对于一个采取了一定安全措施的Web服务器，从攻击开始到取得成果，至少要有半天的时间。如果Web管理员对服务器进行了全天候的监控。在发现有异常行为时，及早的采取措施，将病毒与木马阻挡在门户之外。这种主动出击的方式，就可以大大的提高Web服务器的安全性。 笔者现在维护的Web服务器有好几十个。现在专门有一个小组，来全天候的监控服务器的访问。平均每分钟都可以监测到一些试探性的攻击行为。其中99%以上的攻击行为，由于服务器已经采取了对应的安全措施，都无功而返。不过每天仍然会遇到一些攻击行为。这些攻击行为可能是针对新的漏洞，或者采取了新的攻击方式。在服务器上原先没有采取对应的安全措施。如果没有及时的发现这种行为，那么他们就很有可能最终实现他们的非法目的。相反，现在及早的发现了他们的攻击手段，那么我们就可以在他们采取进一步行动之前，就在服务器上关掉这扇门，补上这个漏洞。 笔者在这里也建议，企业用户在选择互联网Web服务器提供商的时候，除了考虑性能等因素之外，还要评估服务提供商能否提供全天候的监控机制。在Web安全上主动出击，及时发现攻击者的攻击行为。在他们采取进一步攻击措施之前，就他们消除在萌芽状态。 三、设置蜜罐，将攻击者引向错误的方向 在军队中，有时候会给军人一些伪装，让敌人分不清真伪。其实在跟病毒、木马打交道时，本身就是一场无硝烟的战争。为此对于Web服务器采取一些伪装，也能够将攻击者引向错误的方向。等到供给者发现自己的目标错误时，管理员已经锁定了攻击者，从而可以及早的采取相应的措施。笔者有时候将这种主动出击的行为叫做蜜罐效应。简单的说，就是设置两个服务器。其中一个是真正的服务器，另外一个是蜜罐。现在需要做的是，如何将真正的服务器伪装起来，而将蜜罐推向公众。让攻击者认为蜜罐服务器才是真正的服务器。要做到这一点的话，可能需要从如下几个方面出发。 一是有真有假，难以区分。如果要瞒过攻击者的眼睛，那么蜜罐服务器就不能够做的太假。笔者在做蜜罐服务器的时候，80%以上的内容都是跟真的服务器相同的。只有一些比较机密的信息没有防治在蜜罐服务器上。而且蜜罐服务器所采取的安全措施跟真的服务器事完全相同的。这不但可以提高蜜罐服务器的真实性，而且也可以用来评估真实服务器的安全性。一举两得。 二是需要有意无意的将攻击者引向蜜罐服务器。攻击者在判断一个Web服务器是否值得攻击时，会进行评估。如评估这个网站的流量是否比较高。如果网站的流量不高，那么即使被攻破了，也没有多大的实用价值。攻击者如果没有有利可图的话，不会花这么大的精力在这个网站服务器上面。如果要将攻击者引向这个蜜罐服务器的话，那么就需要提高这个蜜罐服务器的访问量。其实要做到这一点也非常的容易。现在有很多用来交互流量的团队。只要花一点比较小的投资就可以做到这一点。 三是可以故意开一些后门让攻击者来钻。作为Web服务器的管理者，不仅关心自己的服务器是否安全，还要知道自己的服务器有没有被人家盯上。或者说，有没有被攻击的价值。此时管理者就需要知道，自己的服务器一天被攻击了多少次。如果攻击的频率比较高，管理者就高兴、又忧虑。高兴的是自己的服务器价值还蛮大的，被这么多人惦记着。忧虑的是自己的服务器成为了众人攻击的目标。就应该抽取更多的力量来关注服务器的安全。 四、专人对Web服务器的安全性进行测试 俗话说，靠人不如靠自己。在Web服务器的攻防战上，这一个原则也适用。笔者建议，如果企业对于Web服务的安全比较高，如网站服务器上有电子商务交易平台，此时最好设置一个专业的团队。他们充当攻击者的角色，对服务器进行安全性的测试。这个专业团队主要执行如下几个任务。 一是测试Web管理团队对攻击行为的反应速度。如可以采用一些现在比较流行的攻击手段，对自己的Web服务器发动攻击。当然这个时间是随机的。预先Web管理团队并不知道。现在要评估的是，Web管理团队在多少时间之内能够发现这种攻击的行为。这也是考验管理团队全天候跟踪的能力。一般来说，这个时间越短越好。应该将这个时间控制在可控的范围之内。即使攻击最后没有成功，Web管理团队也应该及早的发现攻击的行为。毕竟有没有发现、与最终有没有取得成功，是两个不同的概念。 二是要测试服务器的漏洞是否有补上。毕竟大部分的攻击行为，都是针对服务器现有的漏洞所产生的。现在这个专业团队要做的就是，这些已发现的漏洞是否都已经打上了安全补丁或者采取了对应的安全措施。有时候我们都没有发现的漏洞是无能为力，但是对于这些已经存在的漏洞不能够放过。否则的话，也太便宜那些攻击者了。

创新互联成立与2013年，先为建邺等服务建站，建邺等地企业，进行企业商务咨询服务。为建邺企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

web服务器安全设置

Web服务器攻击常利用Web服务器软件和配置中的漏洞，web服务器安全也是我们现在很多人关注的一点，那么你知道web服务器安全设置吗?下面是我整理的一些关于web服务器安全设置的相关资料，供你参考。

web服务器安全设置一、IIS的相关设置

删除默认建立的站点的虚拟目录，停止默认web站点，删除对应的文件目录c:inetpub，配置所有站点的公共设置，设置好相关的连接数限制， 带宽设置以及性能设置等其他设置。配置应用程序映射，删除所有不必要的应用程序扩展，只保留asp，php，cgi，pl，aspx应用程序扩展。对于php和cgi，推荐使用isapi方式解析，用exe解析对安全和性能有所影响。用户程序调试设置发送文本错误信息给客户。

对于数据库，尽量采用mdb后缀，不需要更改为asp，可在IIS中设置一个mdb的扩展映射，将这个映射使用一个无关的dll文件如C:WINNTsystem32inetsrvssinc.dll来防止数据库被下载。设置IIS的日志保存目录，调整日志记录信息。设置为发送文本错误信息。修改403错误页面，将其转向到其他页，可防止一些扫描器的探测。另外为隐藏系统信息，防止telnet到80端口所泄露的系统版本信息可修改IIS的banner信息，可以使用winhex手工修改或者使用相关软件如banneredit修改。

对于用户站点所在的目录，在此说明一下，用户的FTP根目录下对应三个文件佳，wwwroot，database，logfiles，分别存放站点文件，数据库备份和该站点的日志。如果一旦发生入侵事件可对该用户站点所在目录设置具体的权限，图片所在的目录只给予列目录的权限，程序所在目录如果不需要生成文件(如生成html的程序)不给予写入权限。因为是虚拟主机平常对脚本安全没办法做到细致入微的地步。

方法

用户从脚本提升权限：

web服务器安全设置二、ASP的安全设置

设置过权限和服务之后，防范asp木马还需要做以下工作，在cmd窗口运行以下命令：

regsvr32/u C:\WINNT\System32\wshom.ocx

del C:\WINNT\System32\wshom.ocx

regsvr32/u C:\WINNT\system32\shell32.dll

del C:\WINNT\system32\shell32.dll

即可将WScript.Shell, Shell.application, WScript.Network组件卸载，可有效防止asp木马通过wscript或shell.application执行命令以及使用木马查看一些系统敏感信息。另法：可取消以上文件的users用户的权限，重新启动IIS即可生效。但不推荐该方法。

另外，对于FSO由于用户程序需要使用，服务器上可以不注销掉该组件，这里只提一下FSO的防范，但并不需要在自动开通空间的虚拟商服务器上使用，只适合于手工开通的站点。可以针对需要FSO和不需要FSO的站点设置两个组，对于需要FSO的用户组给予c:winntsystem32scrrun.dll文件的执行权限，不需要的不给权限。重新启动服务器即可生效。

对于这样的设置结合上面的权限设置，你会发现海阳木马已经在这里失去了作用!

web服务器安全设置三、PHP的安全设置

默认安装的php需要有以下几个注意的问题：

C:\winnt\php.ini只给予users读权限即可。在php.ini里需要做如下设置：

Safe_mode=on

register_globals = Off

allow_url_fopen = Off

display_errors = Off

magic_quotes_gpc = On [默认是on，但需检查一遍]

open_basedir =web目录

disable_functions =passthru,exec,shell_exec,system,phpinfo,get_cfg_var,popen,chmod

默认设置com.allow_dcom = true修改为false[修改前要取消掉前面的;]

web服务器安全设置四、MySQL安全设置

如果服务器上启用MySQL数据库，MySQL数据库需要注意的安全设置为：

删除mysql中的所有默认用户，只保留本地root帐户，为root用户加上一个复杂的密码。赋予普通用户updatedeletealertcreatedrop权限的时候，并限定到特定的数据库，尤其要避免普通客户拥有对mysql数据库操作的权限。检查mysql.user表，取消不必要用户的shutdown_priv,reload_priv,process_priv和File_priv权限，这些权限可能泄漏更多的服务器信息包括非mysql的 其它 信息出去。可以为mysql设置一个启动用户，该用户只对mysql目录有权限。设置安装目录的data数据库的权限(此目录存放了mysql数据库的数据信息)。对于mysql安装目录给users加上读取、列目录和执行权限。

Serv-u安全问题：

安装程序尽量采用最新版本，避免采用默认安装目录，设置好serv-u目录所在的权限，设置一个复杂的管理员密码。修改serv-u的banner信息，设置被动模式端口范围(4001—4003)在本地服务器中设置中做好相关安全设置：包括检查匿名密码，禁用反超时调度，拦截“FTP bounce”攻击和FXP，对于在30秒内连接超过3次的用户拦截10分钟。域中的设置为：要求复杂密码，目录只使用小写字母，高级中设置取消允许使用MDTM命令更改文件的日期。

更改serv-u的启动用户：在系统中新建一个用户，设置一个复杂点的密码，不属于任何组。将servu的安装目录给予该用户完全控制权限。建立一个FTP根目录，需要给予这个用户该目录完全控制权限，因为所有的ftp用户上传，删除，更改文件都是继承了该用户的权限，否则无法操 作文 件。另外需要给该目录以上的上级目录给该用户的读取权限，否则会在连接的时候出现530 Not logged in, home directory does not exist。比如在测试的时候ftp根目录为d:soft，必须给d盘该用户的读取权限，为了安全取消d盘其他文件夹的继承权限。而一般的使用默认的system启动就没有这些问题，因为system一般都拥有这些权限的。

web服务器安全设置五、数据库服务器的安全设置

对于专用的MSSQL数据库服务器，按照上文所讲的设置TCP/IP筛选和IP策略，对外只开放1433和5631端口。对于MSSQL首先需要为sa设置一个强壮的密码，使用混合身份验证,加强数据库日志的记录,审核数据库登陆事件的”成功和失败”.删除一些不需要的和危险的OLE自动存储过程(会造成 企业管理 器中部分功能不能使用),这些过程包括如下:

Sp_OAcreate Sp_OADestroy Sp_OAGetErrorInfo Sp_OAGetProperty

Sp_OAMethod Sp_OASetProperty Sp_OAStop

去掉不需要的注册表访问过程,包括有:

Xp_regaddmultistring Xp_regdeletekey Xp_regdeletevalue

Xp_regenumvalues Xp_regread Xp_regremovemultistring

Xp_regwrite

去掉其他系统存储过程，如果认为还有威胁，当然要小心drop这些过程，可以在测试机器上测试，保证正常的系统能完成工作，这些过程包括：

xp_cmdshell xp_dirtree xp_dropwebtask sp_addsrvrolemember

xp_makewebtask xp_runwebtask xp_subdirs sp_addlogin

sp_addextendedproc

在实例属性中选择TCP/IP协议的属性。选择隐藏 SQL Server 实例可防止对1434端口的探测,可修改默认使用的1433端口。除去数据库的guest账户把未经认可的使用者据之在外。 例外情况是master和 tempdb 数据库,因为对他们guest帐户是必需的。另外注意设置好各个数据库用户的权限，对于这些用户只给予所在数据库的一些权限。在程序中不要用sa用户去连接任何数据库。网络上有建议大家使用协议加密的，千万不要这么做，否则你只能重装MSSQL了。

什么是 Web安全？Web应用漏洞的防御实现

什么是 Web安全？

Web安全是计算机术语。随着Web2.0、社交网络等一系列新型的互联网产品诞生问世，基于Web环境的互联网应用越来越广泛，企业信息化的过程中各种应用都架设在Web平台上，Web业务的迅速发展也引起黑客们的窥探，接踵而至的就是Web安全威胁的凸显。

黑客利用网站操作系统的漏洞和Web服务程序的SQL注入漏洞等得到Web服务器的控制权限，轻则篡改网页内容，重则窃取重要内部数据，更为严重的则是在网页中植入恶意代码，使得网站访问者受到侵害。

Web安全的现状及原因

目前，很多业务都依赖于互联网，无论是网上银行、网上购物、还是网络 游戏 等，恶意攻击者们出于各种不良目的，对Web 服务器进行攻击，想方设法通过各种手段获取他人的个人账户信息谋取利益。正是如此，Web业务平台最容易遭受攻击。

而针对Web服务器的攻击也是五花八门，常见的有挂马、SQL注入、缓冲区溢出、嗅探、利用IIS等针对Webserver漏洞进行攻击。

一方面，由于TCP/IP的设计是没有考虑安全问题的，网络上传输的数据是没有任何安全防护。攻击者们可利用系统漏洞造成系统进程缓冲区溢出，攻击者可能获得或者提升自己在有漏洞的系统上的用户权限来运行任意程序，甚至安装和运行恶意代码，窃取机密数据。

而应用层面的软件在开发过程中也没有过多考虑到安全的问题，这使得程序本身存在很多漏洞，诸如缓冲区溢出、SQL注入等等流行的应用层攻击，这些都属于在软件研发过程中疏忽了对安全的考虑所致。

另一方面，个人用户由于好奇心，被攻击者利用木马或病毒程序进行攻击，攻击者将木马或病毒程序捆绑在一些诱人的图片、音视频或免费软件等文件中，然后将这些文件置于某些网站当中，再引诱用户去单击或下载运行，或通过电子邮件附件和QQ、MSN等即时聊天软件，将这些捆绑了木马或病毒的文件发送给用户，让用户打开或运行这些文件。

Web安全的三个细分

Web安全主要分为:1、保护服务器及其数据的安全。2、保护服务器和用户之间传递的信息的安全。3、保护Web应用客户端及其环境安全这三个方面。

Web应用防火墙

Web应用安全问题本质上源于软件质量问题。但Web应用相较传统的软件，具有其独特性。Web应用往往是某个机构所独有的应用，对其存在的漏洞，已知的通用漏洞签名缺乏有效性；

需要频繁地变更以满足业务目标，从而使得很难维持有序的开发周期；需要全面考虑客户端与服务端的复杂交互场景，而往往很多开发者没有很好地理解业务流程；人们通常认为Web开发比较简单，缺乏经验的开发者也可以胜任。

Web应用安全，理想情况下应该在软件开发生命周期遵循安全编码原则，并在各阶段采取相应的安全措施。

然而，多数网站的实际情况是：大量早期开发的Web应用，由于 历史 原因，都存在不同程度的安全问题。对于这些已上线、正提供生产的Web应用，由于其定制化特点决定了没有通用补丁可用，而整改代码因代价过大变得较难施行或者需要较长的整改周期。

这种现状，专业的Web安全防护工具是一种合理的选择。WEB应用防火墙（以下简称WAF）正是这类专业工具，提供了一种安全运维控制手段：基于对HTTP/HTTPS流量的双向分析，为Web应用提供实时的防护。

Web应用漏洞的防御实现

对于常见的Web应用漏洞，应该从3个方面入手进行防御：

1、对 Web应用开发者而言

大部分Web应用常见漏洞都是在Web应用开发中，由于开发者没有对用户输入的参数进行检测或者检测不严格造成的。所以，Web应用开发者应该树立很强的安全意识，开发中编写安全代码；

对用户提交的URL、查询关键字、HTTP头、POST数据等进行严格的检测和限制，只接受一定长度范围内、采用适当格式及编码的字符，阻塞、过滤或者忽略其它的任何字符。通过编写安全的Web应用代码，可以消除绝大部分的Web应用安全问题。

2、对Web网站管理员而言

作为负责网站日常维护管理工作Web管理员，应该及时跟踪并安装最新的、支撑Web网站运行的各种软件的安全补丁，确保攻击者无法通过软件漏洞对网站进行攻击。

除了软件本身的漏洞外，Web服务器、数据库等不正确的配置也可能导致Web应用安全问题。Web网站管理员应该对网站各种软件配置进行仔细检测，降低安全问题的出现可能。

此外，Web管理员还应该定期审计Web服务器日志，检测是否存在异常访问，及早发现潜在的安全问题。

3、使用网络防攻击设备

前两种都是预防方式，相对来说很理想化。在现实中，Web应用系统的漏洞仍旧不可避免：部分Web网站已经存在大量的安全漏洞，而Web开发者和网站管理员并没有意识到或发现这些安全漏洞。

由于Web应用是采用HTTP协议，普通的防火墙设备无法对Web类攻击进行防御，因此需要使用入侵防御设备来实现安全防护。

确保Web安全的HTTPS

很多人说“不用HTTPS就是裸奔”

HTTP的不足：

通信使用明文（不加密），内容可能会被窃听(wireshark/fiddler)

不验证通信方的身份，因此有可能遭遇伪装

无法证明报文的完整性，所以有可能已遭篡改

TCP/IP 是可能被窃听的网络

1.通讯的加密：

SSL(Secure Socket Layer,安全套接层）或TLS(Transport Layer Security,安全层传输协议)

有兴趣深入SSL/TLS:

用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS（HTTP Secure，超文本传输安全协议）或 HTTP over SSL。

2.内容的加密：

为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制。主要应用在 Web 服务中。有一点必须引起注意，由于该方式不同于 SSL 或 TLS 将整个通信线路加密处理，所以内容仍有被篡改的风险。

不验证通讯方的身份就可能遭遇伪装

无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。

无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。

无法确定正在通信的对方是否具备访问权限。因为某些Web 服务器上保存着重要的信息，只想发给特定用户通信的权限。

无法判定请求是来自何方、出自谁手。

无法证明报文的完整性，可能已遭篡改

如何防篡改？

可以使用MD5和SHA-1等散列算法，但这仍然无法百分百保证结果的正确，因为散列码如果同时被修改的话，用户还是无法意识到文件已经被修改。还是用HTTPS吧。

HTTP+ 加密 + 认证 + 完整性保护=HTTPS

HTTP是身披SSL外壳的HTTP

相互交换密钥的公开密钥加密技术 ：

共享密钥加密的问题：

证明公开密钥的正确性的证书：

也可以通过设置-高级-管理HTTPS证书来查看所有已经安装的证书（chrome浏览器）

HTTPS的安全通信机制：

步骤 1： 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。

步骤 2： 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。

步骤 3： 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。

步骤 4： 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。

步骤 5： SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-mastersecret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。

步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。

步骤 7： 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。

步骤 8： 服务器同样发送 Change Cipher Spec 报文。

步骤 9： 服务器同样发送 Finished 报文。

步骤 10： 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。

步骤 11： 应用层协议通信，即发送 HTTP 响应。

步骤 12： 最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP的通信。

问题：为何不完全使用非对称加密算法，而是使用非对称加密算法传送密钥，对称加密算法加密内容？（性能问题）

常见对称加密算法:AES/DES

常见非对称加密算法：RSA

对称加密算法和非对称加密算法速度对比：

要进行 HTTPS 通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。证书价格可能会根据不同的认证机构略有不同。通常，一年的授权需要数万日元（现在一万日元大约折合 600人民币）。

https不是只有信徒，google的霸道也引来了很多的反抗者~

1.chrome浏览器将非https站点默认标注为“不安全”的

2.SEO，不https就掐掉流量。。。

RSS 之父 Winer 炮轰 Google 反客为主强推 HTTPS：

搭建一个https服务端：

windows server上的一个简单https例子(不想乱搞测试环境，就没弄Linux)：

标题名称：如何保证wed服务器安全 web服务器安全程序有哪些实现方式
路径分享：http://scyingshan.cn/article/dopdsed.html