来源: 互联网  发布时间: 2013-12-24

FastCGI的IIS模块可以让流行的应用框架在IIS上支持FastCGI协议以提供高性能和可用性的访问服务,FastCGI面向现有的网络服务器提供高性能的CGI替代标准。具体PHP 安装方法我记录下来,其中包括出现的一个错误.
环境:
操作系统:Windows 2003 Server
PHP版本:PHP5.25


1.下载FastCGI For IIS6
http://www.microsoft.com/downloads/details.aspx?FamilyID=2d481579-9a7c-4632-b6e6-dee9097f9dc5&displaylang=en

下载之后,双击运行进行安装.

2.下载PHP5.25 Windows版
http://www.php.net

下载.zip格式的版本,下载后解压至D:\PHP目录,并给IIS启动帐户组或用户赋予读取和运行权限.

3.注册PHP到FastCGI
在命令行下运行
cscript fcgiconfig.js -add -section:"PHP" -extension:php -path:"D:\PHP\php-cgi.exe"

fcgiconfig.js 默认存放目录是:C:\WINDOWS\system32\inetsrv

4.设置
将D:\PHP\php.ini-recommended重命名为为D:\PHP\php.ini
打开D:\PHP\php.ini，修改：
extension_dir = "D:\PHP\ext"
fastcgi.impersonate = 1
cgi.fix_pathinfo=1
cgi.force_redirect = 0

其它根据实际需要对php.ini进行设置修改
然后执行：
cscript fcgiconfig.js -set -section:"PHP" -InstanceMaxRequests:500
cscript fcgiconfig.js -set -section:"PHP" -EnvironmentVars:PHP_FCGI_MAX_REQUESTS:1000
以上两项设置最大池和响应连接数，可以根据运行机器的硬件配置、使用情况修改

一切完毕之后重启IIS,赶紧写一个测试页试一下吧.

我第一次安装时,由于为了服务器的安全我删除了wsshell命令,导致在第3步时出现了如下错误:
Microsoft JScript 运行时错误: Automation 服务器不能创建对象
后通过重新注册命令:regsvr32 WSHom.ocx
问题解决

重启IIS后,打开测试页出现如下提示:

FastCGI Error
The FastCGI Handler was unable to process the request.
--------------------------------------------------------------------------------

Error Details:

Error Number: 5 (0x80070005).
Error Description: 拒绝访问。
HTTP Error 500 - Server Error.
Internet Information Services (IIS)

这个错误是由于在解压PHP之后,没有对IIS启动帐户赋予该目录的读取和运行权限.修改文件夹安全属性,问题解决.

    

    来源: 互联网  发布时间: 2013-12-24

回头把 IIS 7 下的实现方法也帖上。

环境：
操作系统：Windows 2003 Server SP2
PHP 版本：php-5.2.6-Win32

1.下载 FastCGI For IIS6

http://www.microsoft.com/downloads/details.aspx?FamilyID=2d481579-9a7c-4632-b6e6-dee9097f9dc5&displaylang=en

下载之后，双击运行进行安装。

安装后在 C:\WINDOWS\system32\inetsrv 目录下产生了五个文件。如下图：

同时在 IIS 的 “Web 服务扩展”里多了 FastCGI Handler。

2.下载 PHP5.25 Windows 版

http://www.php.net/downloads.php

下载 .zip 格式的版本，下载后解压至 D:\PHP 目录，并给 IIS 启动帐户组或用户赋予读取和运行权限。如下图：

你可以根据自己的意愿解压到别的目录。

3. 注册 PHP 到 FastCGI

打开 C:\WINDOWS\system32\inetsrv\fcgiext.ini 文件。

; This is the configuration file for the FastCGI handler for IIS 6.0.
; The FastCGI handler will look for this file in the same directory as
; fcgiext.dll.  By default, the FastCGI installer will place this file into
; the %windir%\system32\inetsrv directory.

我个人的理解是，只要“Web 服务扩展”里的 FastCGI Handler 为允许时，在加载 fcgiext.dll 时，会读取 fcgiext.ini 配置文件的内容，根据里面的配置为每个网站提供映射。

在 [Types] 下添加以下配置：

[Types]
php=PHP

[PHP]
ExePath=D:\PHP\php-cgi.exe

“php”表示扩展名，“PHP”是配置节名称，以“[PHP]”定义。

4. 配置 php.ini

将 D:\PHP\php.ini-recommended 复制一个，然后重命名为　D:\PHP\php.ini

打开 D:\PHP\php.ini，修改：

extension_dir = "D:\PHP\ext"
fastcgi.impersonate = 1

其它的根据实际需要对 php.ini 进行设置修改，这里只针对能跑 php，修改完记得重启 IIS。

5. 配置网站

右键网站 => 属性 => 主目录 => 配置 => 添加，如下图配置：

可执行文件路径：C:\WINDOWS\system32\inetsrv\fcgiext.dll

6. 写个 php 测试下吧

<?php
phpinfo();
?>

看到类似以下效果说明你的服务器可以跑 php 了。

打开后如果出现提示：

No input file specified.

估计是没配置 fastcgi.impersonate。

如果你还觉得麻烦，那就到 http://www.zend.com 下载 Zend Core，这个就什么都不用配置，安装完就可以使用了，连 MySQL 都有。

    

    来源: 互联网  发布时间: 2013-12-24

如笔者企业，把OA系统、邮箱系统的入口都捆绑在WEB服务器上。故WEB服务器安全是笔者众多工作中的重中之重。

为了提高WEB服务器的安全性，有众多的方法。在这里，笔者要向大家推荐的主要是三种方法。如果只想通过这三种方法来保障WEB服务器的安全当然是远远不够的。但是，若企业信息化管理人员若疏忽了这三个方面的内容，则WEB服务器的安全性是很难保障的。

利器一：为WEB应用建立独立的服务器。

由于WEB服务器可能遭受到的攻击，比ERP系统、办公自动化系统等应用服务器的几率高的多。所以，若把这些应用放在WEB应用同一个服务器中，则弱WEB服务器遭受到攻击，则很有可能殃及到ERP等关键应用。

笔者企业中虽然把OA系统的接口绑定在WEB服务器上，但是，OA系统与WEB应用仍然在不同的应用服务器上。这主要是为了方便员工从企业外部访问 OA系统。如此的好处，就是当WEB服务遭受到攻击不能使用时，最多员工无法从企业外部访问OA系统；而不影响企业内部员工的正常访问。

不过，笔者以前就犯过类似的错误。那时，企业由于资金紧张，就把WEB服务器与ERP系统服务器部署在同一个服务器上。突然有一天企业的WEB服务器遭受到了不明身份的人的攻击。他们可能只是出于好玩吧，没有对WEB服务器产生多大的危害。只是CPU与内存的使用率居高不下。当把WEB服务器跟外网断开好，就恢复正常了。但是，这就使得同一个服务器上的ERP应用无法运作。企业员工每次输入一张销售订单，从原来的3分钟变为现在的30分钟。这么慢的速度显然很难让人接受。从这个事件中，让笔者懂得了一个真理，把企业内部应用放在WEB服务器上是一个非常不明智的做法。由于WEB服务器其面向的是互联网，所以，其很容易遭受到别人的恶意攻击。殃及池鱼，受到攻击后，连企业内部的应用服务都会受到牵连。

所以，笔者第一个要提醒大家的就是，在部署服务器的时候，做好让WEB等面向互联网的应用服务跟其他面向内部的应用服务在不同的服务器上部署。这在保障WEB服务器安全的同时，也提高了企业其他应用服务的安全性。

利器二：事务日志，让你对WEB运行状况了如指掌。

其实，WEB服务器只要采取一定的保护措施，则攻击就需要一个过程，不是说在一个短时间内就可以完成的。通常情况下，这个攻击的过程往往会在WEB 服务器的事务日志中留下蛛丝马迹。如非法攻击者视图通过密码字典破解工具，尝试网站管理员的口令与密码的时候，就会在WEB服务器的日志中留下纪录。如果我们在事务审核中，设置当用户密码最多输入错误次数的话，则当超过这个最大次数的时候，服务器就会在自己的日志中纪录这条信息。此时，若网站管理人员可以看到这条信息，则他们就可以及时的采取措施，如更改复杂密码等手段，来提高服务器的安全性。

所以，每一个WEB服务器的管理人员都必须要重视事务日志的重要性。同时，为了让事务日志发挥更大的作用，往往需要启用审核功能。通过审核事件跟系统日志结合起来，可以让日志服务器纪录一些常见的攻击行为。从而给企业安全人员提供参考。否则的话，企业安全人员都不知道那里受到攻击了，那么他们也就根本无法进行及时的应对。

不过话说话来，有些高手攻击企业WEB服务后，不会再事务日志上留下任何痕迹。这并不是说事务日志不管用了。而是因为他们在结合攻击后，会修改事务日志的信息。如某个攻击者窃取了管理员用户与密码后访问企业网站中的机密信息。一般情况下，这个访问纪录会在事务日志中有所显示。但是，一些高手会在推出之前修改事务日志。删除这些访问信息，或者更改访问者。让企业安全管理人员无从查起。为了让他们无法更改事务日志文件，则最好的方法就是更改事务日志文件的路径，并对其进行及时的备份。由于不知道路径的真确位置，所以，及时不法攻击者想攻击想修改日志隐藏自己的踪迹，都不可能。

笔者现在的做法是，更改WEB服务器的日志的默认路径。并且每隔三个小时对事务日志进行异地备份。同时，结合事件审核功能，当日志服务器捕捉到一些异常信息时，如某个用户一直在试图登陆WEB服务器的管理站时，就会像企业管理人员递交这个异常信息。通过日志的管理，可以把WEB服务器的一些安全隐患及时的告知给管理人员。

所以笔者这里要向大家推荐的第二把利器就是WEB服务器的日志管理 。管理员为了提高日志的安全性，要修改服务器日志的默认路径，并且定时对其进行异地备份。同时，要跟其他的功能，如安全审核、账户安全策略等工具，结合使用，可以起到事半功倍的作用。

利器三：代码，影响WEB服务器安全的最大杀手。

对于WEB服务器来说，代码是其安全的最大杀手之一。很多WEB服务器被攻破，大部分是由于代码设计不当所引起的。故管理好WEB服务器的代码，是保障WEB服务器安全的首要任务。

为了提高代码的安全性，网站开发者要养成一些好的代码编写习惯。

一是不要直接采用网络上的代码。

有些开发者为了工作上的便利，会直接拷贝其他网友提供的代码。但是，不幸的是，天下没有白吃的午餐。有些人免费提供这些代码往往带有不可告人的秘密。如现在网络上提供的一些电子商务平台与网站论坛代码，代码提供者很有可能会在代码中预留一个后门。当他觉得有必要的话，则就可以很轻易的采用这个后门对其进行攻击。所以，若企业要在WEB服务器上实现一些关键应用，如客户在线下单等等，则最好不要采用网络上现成的编码。只可以借鉴，不可以抄袭。最好的话，自己开发。

二是增加的新功能不要在WEB服。

企业在发展，WEB应用也逐渐在完善。企业市场会提出一些新的需求。当开发者在开发某个功能的时候，最好不要直接在WEB服务器上直接进行测试。有条件的企业，最好专门配置一个测试服务器，以方便程序开发人员测试新功能。特别是若把这个程序开发外包给外面的企业的话，不能够为了贪图方便，直接让对方在现用的WEB服务器上进行测试。俗话说，知人知面不知心。对方很可能在你不知情的情况下，植入一个木马都说不定。所以，防人之心不可无。企业在新功能的开发测试上还是要小心为妙。

三是尽量不要采用不安全的控件。

企业WEB应用跟娱乐网站不同。企业门户网站强调的是快速、稳定、安全；而娱乐网站则强调的是美观、靓丽、特效。为了吸引眼球，提高点击率，娱乐网站往往会采用比较多的特效。为此，他们会在WEB服务上采用比较多的控件来达到这个效果。但是，这些控件往往都有安全漏洞，跟WEB服务器的安全背道而驰。如FLASH控件等等。针对这种控件的攻击，互联网上可能每天都在发生。还说不定哪一天就落到企业的头上了。所以，企业网站只追求稳定、安全，没有必要过多的采用控件来实现特技效果。

笔者向大家推荐的第三把利器就是要做好代码的安全设计，尽量减少采用不安全的控件。企业网站应该追求稳定、反映速度等等。而过多的采用控件，跟这两个目标都是背道而驰的。