自己的博客通过RSS——–>自己的微博
自己的微博——–>嘀咕的API
qq,msn等签名—->嘀咕
嘀咕———>嘀咕的博客/论坛展示脚本显示到各个站
嘀咕———->嘀咕的滴神功能分发这些更新到开心001.新浪微博,uchome等
嘀咕———->通过API通知自己的微博t.myf5.net
自己的博客通过RSS——–>自己的微博
自己的微博——–>嘀咕的API
qq,msn等签名—->嘀咕
嘀咕———>嘀咕的博客/论坛展示脚本显示到各个站
嘀咕———->嘀咕的滴神功能分发这些更新到开心001.新浪微博,uchome等
嘀咕———->通过API通知自己的微博t.myf5.net
之前我自己将wasc-wafec-v1.0_web应用防火墙评估标准.pdf翻译成中文,并整理成excel方式在公司内部发了下,一直没有公开发出,一来是觉得翻译的还不够好,二来觉得有些地方自己也未领悟深透。今天偶然在网上发现有人也翻译了这个标准,并公布了出来,就直接转载过来,下面为转载内容。
前言
Web应用防火墙 (WAF) 代表了一种新的信息安全技术,用于保护Web站点(或者说Web应用程序),使其在受攻击的情况下表现出更强的抵抗力。 在抵御Web攻击方面,WAF 提供了防火墙和IDS等常规信息安全产品所不具备的能力。WAF不需要修改Web应用程序的源代码。随着目前针对Web应用的攻击手段越来越复杂化,为WAF制定一个规范的评价标准显得重要起来,有了这个标准,我们就可以去准确地比较和评价WAF产品。
本项目的目的是研究出一套WAF的评价标准,同时研究出一套测试方法,使得有经验的工程师可以使用本文中提到的知识独立的对WAF产品的优劣进行测试和评价。这里需要指出的是,由于WAF技术上的实现方式多种多样,对于WAF产品来说,并不要求其支持本文中提到的所有具体技术。
总之: 这篇文章的目的是要引起测试人员对WAF产品可能使用的一些技术的重视。我们列出的评价项目清单很长,你可以以其为基础,从中抽出部分项目对特定产品的进行测试。
评价项目如下:
1. 部署方式
2. HTTP协议支持
3. 检测技术Detection Techniques
4. 防御技术Protection Techniques
5. 审计Logging
6. 报告Reporting
7. 管理Management
8. 性能Performance
9. XML
在以后的版本里,我们准备新增和加以充实的条目还有:
· 主动学习(Compliance),认证( certifications)和协同工作(interoperability)
· 更深入的研究对性能 的评价(尤其是网络层性能)
· 更深入的研究对XML相关功能的评价指标
撰稿者
本文的诞生源自团队的努力。以下是为本文无私贡献了宝贵时间和经验的兄弟姐妹们:
· Robert Auger (SPI Dynamics)
· Ryan C. Barnett (EDS)
· Charlie Cano (F5)
· Anton Chuvakin (netForensics)
· Matthieu Estrade (Bee Ware)
· Sagar Golla (Secureprise)
· Jeremiah Grossman (WhiteHat Security)
· Achim Hoffmann (Individual)
· Amit Klein (Individual)
· Mark Kraynak (Imperva)
· Vidyaranya Maddi (Cisco Systems)
· Ofer Maor (Hacktics)
· Cyrill Osterwalder (Seclutions AG)
· Sylvain Maret (e-Xpert Solutions)
· Gunnar Peterson (Arctec Group)
· Pradeep Pillai (Cisco Systems)
· Kurt R. Roemer (NetContinuum)
· Kenneth Salchow (F5)
· Rafael San Miguel (daVinci Consulting)
· Greg Smith (Citrix Systems)
· David Movshovitz (F5)
· Ivan Ristic (Thinking Stone) [Project Leader]
· Ory Segal (Watchfire)
· Ofer Shezaf (Breach Security)
· Andrew Stern (F5)
· Bob Walder (NSS Group)
译者
李毅< http://blog.csdn.net/bill_lee_sh_cn>
本文译文地址< http://blog.csdn.net/bill_lee_sh_cn/archive/2009/08/27/4488641.aspx>
联系我们
Web应用防火墙评价标准项目对所有人开放,如果你想参与或是评论请联系Ivan Ristic (<ivanr@webkreator.com>).
评价项目
第1部分 – 部署方式
这一部分描述了WAF在既定环境中的部署问题
1.1 运行模式
该WAF可以支持被动(旁路监听)和主动(串接等)模式吗?
请指出该WAF支持以下主动模式中哪种或哪几种?
1. 透明网桥模式. 是否支持 fail open?【译者注:“fail open”是指当该WAF宕机或停止工作时,网络流量仍然可以穿过它,只是不再被检查】
2. 路由模式.
3. 反向代理模式(Reverse Proxy). 通过修改DNS将网络访问流量定向到WAF上。
4. 插件模式(Embedded).这时 WAF作为一个插件被直接安装在Web服务器上。 支持哪几种Web服务器?请指出与Web服务器如何结合: 有的插件形式WAF插在Web服务器的通讯之前,所有的检查和过滤任务都是自己完成的,而有的则依赖Web服务器的功能去完成这些任务.(这两种方式各有自己的优缺点。)
1.2 SSL
SSL通常用来保护与Web应用交互的通讯数据。这种机制在达到保护通讯数据的同时也对防御保护系统 (如IDS、WAF等)的正常使用造成了困难。如果WAF无法得到被加密的原文,它就没有办法实施保护。
请描述该WAF如何得到被加密的原文数据:
1. 作为SSL的一端(Terminates SSL). 需要重新规划网络结构使得由WAF来完成SSL操作。 WAF 自己对HTTP数据进行加密和解密,而WAF同Web服务器之间的通讯可以使明文或也使用SSL加密。
2. 被动SSL解密(Passively decrypts SSL).在WAF上拷贝一份Web服务器的私钥从而使WAF 可以解密SSL通讯数据. 原始的SSL通讯数据可以不受影响的到达服务器。
3. 不受SSL影响. 这一般发生在作为Web服务器插件的WAF情况下, 该WAF的工作位置在SSL已经被Web服务器解密成明文之后。
客户端证书:
1. 在被动模式下支持客户端证书吗?
2. 在主动模式下支持客户端证书吗?
3. In termination mode, can the content from client certificates be sent to the application using some alternative transport method (e.g. request headers).
<
p>其他
无论是在计算机杂志还是在Internet上,目前最热门的话题莫过于“Web Services”。各个平台之间的锋争,各个新产品的发布,众多新标准的制订,大都和Web Services有关。
Web Services的起源
Web应用的巨大成功和不断发展,使其渗透到商业领域和个人生活的各个方面。人们只要使用浏览器,就可以享受到各种各样的Web服务,例如网上购物,网上交易,网络游戏,预定车票,网上聊天和交友等等。与此同时,由于Web技术所带来的优势(统一的客户端和较好的维护性),使一些传统的应用纷纷转型到BS结构上。
然而,在发展中,逐步暴露了一些问题。所有这些Web页面都是为人准备的,是让人去阅读,去输入,去判断。因此各种反映视觉效果的内容占用了大量的网络带宽,例如各种图片,字体信息,文字排版样式等。而真正含有高价值的一些信息,被深深埋在这些显示信息中,很难被其他应用和程序所使用。更重要的是,各种web服务之间缺少交互和通讯的机制。
随着应用程序之间通讯的需求越来越大,这就需要制定统一的标准和协议。HP公司是最先提出这个观点的公司,他们制定了有关“e-Speak”的标准来保证应用程序之间的交互,并声称将成为下一代Internet信息交互的标准。而随后,MicroSoft意识到此计划的美好前景,便推出了.Net战略;IBM很快就发布了Web Services Toolkit(WSTK),和Web Services Development Environment(WSDE),申明对Web Services的全力支持。与此同时,Oracle也开发出自己的Dynamic Services,并和Oracle 8i Release 2集成在一起。在这以后,W3C统一制定了Web Services的各种标准。而SUN公司在宣布了自己的Web Services的框架以后,将Web Services的标准溶入J2EE的环境,使Web Services有了广泛支持的基础和平台。
Web Services的基本原理
Web Services 是通过一系列标准和协议来保证程序之间的动态连接。其中最基本的协议包括:SOAP, WSDL, UDDI
SOAP: 是“Simple Object Access Protocol”的缩写,SOAP是消息传递的协议,它规定了Web Services之间是怎样传递信息的。简单的说,SOAP规定了:
1. 传递信息的格式为XML。这就使Web Services能够在任何平台上,用任何语言进行实现。
2. 远程对象方法调用的格式。规定了怎样表示被调用对象以及调用的方法名称和参数类型等。
3. 参数类型和XML格式之间的映射。这是因为,被调用的方法有时候需要传递一个复杂的参数,例如,一个Person对象。怎样用XML来表示一个对象参数,也是SOAP所定义的范围。
4. 异常处理以及其他的相关信息.
WSDL:是“Web Services Description Language”的缩写.意如其名,WSDL是Web Services的定义语言。当你实现了某种服务的时候(如,股票查询服务),为了让别的程序调用,你必须告诉大家你的服务的接口.例如,服务名称,服务所在的机器名称,监听端口号,传递参数的类型,个数和顺序,返回结果的类型等等.这样别的应用程序才能调用你的服务。WSDL协议就是规定了有关Web Services描述的标准。
UDDI: 是Universal Description, Discovery, and Integration的缩写。简单说,UDDI用于集中存放和查找WSDL描述文件,起着目录服务器的作用。
如上图,一个Web Services的生命周期是:
实现一个Web Services,使其能够接受和响应SOAP消息(现在有很多工具都可以帮助实现)。
撰写一个WSDL文件用于描述此Web Services。(现在有很多工具可以自动生成WSDL文件)。
将此WSDL发布到UDDI上。
其他的应用程序(客户端)从UDDI上搜索到你的WSDL。
根据你的WSDL,客户端可以编写程序(现在有很多工具可以自动生成调用程序)调用你的Web Services。
Web Services的缺点
由于是基于XML的应用,Web Services与生俱来地在拥有XML带来的一切优势的同时,不可避免地继承了XML所带来的一些限制。
Web Services通常需要大量的CPU资源。因为XML数据要经过多步处理才能被系统使用。首先是效验(validate),检查它的格式是否符合XML的规范,以及根据应用程序定义(DTD或Schema)检查是否符合语义上的规范;然后还要进行解析(parse),从XML文档分解出单个的元素;最后还要转换成应用程序所需要的二进制表达(例如,把“12” 转换成整型12的二进制表示)。
Web Services还意味着占用较多的内存资源。在进行XML解析的时候,会产生大量的临时内存对象。特别是在处理DOM对象的时候。这些大量的临时对象对于象JAVA这类自动回收内存的语言和系统其实是一种负担,大量的临时对象将会使系统每隔一段时间就会进行内存回收,从而降低系统的性能。当然,现在有的Web Services的产品(如axis)采用了SAX技术,大大减少了内存的占用量。详细信息请参考:(http://xml.apache.org/axis/index.html)。
网络资源的消耗也是Web Services应用的一些限制。因为基于XML数据的传递通常数据量要比二进制的协议(如RMI/IIOP)要大的多。这种额外的消耗在网络资源比较紧张或网络传输比较频繁的应用中会产生一定的影响。
除了XML带来的限制,Web Services本身也具有一些缺点:
到目前为止,Web Services还可以说是一种无状态(stateless)的服务。
所谓stateless就意味着不保存客户端服务调用者的任何信息。这是由Web Services的本质所决定的。Web Services在本质上是要为应用程序之间提供数据通讯的标准,为企业应用之间动态地提供大颗粒度的服务,所以Web Services并不适合于非常精细的基于会话的方法调用以及复杂的事务(transaction)处理之中。
也许有人会对我这点提出异议!因为,现在有很多Web Services的产品(如WASD),不但可以保存session的信息,使服务成为有状态(stateful)的服务,而且还实现了remote interface,可以在Web Services的会话中传递远程对象的句柄,让客户端可以操纵递远程对象(详细信息请参考:http://www.systinet.com )。原理上说,这并不难实现,因为在XML数据中,可以互相传送任何数据,包括sessionID和transactionID,有了这些ID,从技术角度上说,实现有状态(stateful)的服务和事务处理并不复杂。但是,这样功能缺少标准的支持,当前版本的WSDL还无法表示这些复杂的服务。在企业内部,你可以任意使用这些特殊的功能,可以自己定义会话状态的交互协议,因为服务者和服务调用者之间的通讯都在你的控制之中;然而要将这些服务发布到Internet上,其他的应用程序是无法根据标准去识别这些特殊功能。
数据绑定也存在一些不足。
因为所有的数据传递都用XML格式,因此,需要在二进制数据和XML数据之间有个转换。但是,并不是所有的二进制数据都能方便地用XML来表示,并不是所有的JAVA对象都能被XML所表示。因此,经常在转换过程中会出现语义丢失的情况。
技术要求高,学习曲线较长。
每一个Web Services的产品,都有丰富的工具,能够根据Web Services的定义(如WSDL文件)方便地生成客户端的程序;能够将一般的服务程序,很容易就包装成Web Services服务。因此,各个Web Services的产品都声称自己的平台容易使用,根本不需要了解XML,也不需要了解什么WSDL,UDDI,SOAP就能使用发布Web Services。特别是]
]>
一个网站,如果网站目录权限设置的不严格,很可能导致黑客绕过路径限制进入系统中的其他目录,对于一些有在线编辑和管理文件功能的网站,这种危害会被放大,攻击者可以轻松的编辑一个网页木马程序从而轻易的掌握整个服务器。
对于此类攻击,一方面在程序上应该严格测试,另一方面应该在服务器目录权限上下功夫,禁止web匿名用户访问网站目录以外的地方。
其次可以利用WAF类产品进行严格的path访问限制或业务访问逻辑,从而避免危害。下面是一个path bypass攻击示例。
1.该网站具有在线文件编辑功能,仔细分析器URI,发现系统是根据URI中的参数传递path ,则可以通过构造特殊的path参数实现对其他网站目录的访问

2.截取request请求 
3构造新的request

4 结果,网页已经显示的是别的网站下的文件内容

这样就可以轻松的注入木马文件了。
www.myf5.net原创,转载请注明
CSS cross site scripting 跨站脚本 也叫XSS。OWASP将其列为WEB安全的头号风险,主要由于该类攻击及其常见和容易被利用。所谓跨站攻击其实也就是代码(js,vs,html等)注入,利用程序自身对输入、输出的内容不能进行彻底的过滤和编码而导致的浏览器脚本执行,从而损害访问者。利用CSS可以实现cookie窃取,钓鱼,会话劫持,插入木马,权限提升等工作。常见的跨站类型有reflected, stored, and DOM injection。
防范方法:
1.使用WAF等应用防火墙设备
2.程序员应严格的对input,output和将要被存储到服务器的数据进行严格的过滤并进行并使用正确的编码,而不是简单的过滤一些常见的敏感字符,任何一个泄露都可能会被利用,因为CSS攻击是相当灵活的。
3.应使用白名单方式对各种变量 输入 输出进行合法检验,而不应该使用黑名单。
4.使用微软anti-xss 库或者php anti-xss库
攻击示例:
跨站 cookie 截取:

一个后台提交的页面,由于没有进行充分的过滤,在输入上面的代码后,点击提交,用户当前的浏览页面将被定向到一个站点,该站点用来采集用户在这个网站的SESSION和cookie。这样该用户的cookie和会话信息将被攻击者获取。点击提交后的效果如下:

(由于测试机器安装有mcafee杀毒软件,软件直接拦截了本次攻击,如果禁止杀毒软件,结果将会如下)

攻击者可以将各个访问者的cookie记录下来,以便伪造。
如果这些注入的攻击代码被写入到数据库,例如是论坛的一个帖子内容里,这样所有访问该页面的用户的信息都将被攻击者获取,包括管理员的信息。
而如果这些代码是iframe一个木马页面,那么网站就等于被挂马了。
www.myf5.net原创,转载请注明
利用在请求中构建特殊的回车符,进而导致服务器中断正确的response的响应,并在服务器端形成一个伪造的http response,如果此时其他用户发起了http请求,将导致用户看到的是伪造的页面内容,进而攻击用户。如果这个用户是一个代理服务器则危害更大。如果构建在某个其他普通的站点页面上,则大量不同用户的点击可能导致被攻击网站的出现严重的危害。
这个攻击可利用在XSS跨站,web cache投毒,浏览器投毒上。
攻击原理:
利用网站在读取用户提交的数据后,将用户提交的数据插入http的location的 header中,并返回302跳转响应,进而导致自动访问带有特殊构造字符的URI,最终导致服务器产生了2个response,其中第2个response的内容完全可以由用户构造,用户可以插入木马等iframe连接或其他任意内容。
攻击前提:
存在cr lf字符漏洞的web服务器
攻击关键点:
必须准确的让服务器能够明确的终结第一个response。
利用content-length=0让服务器明确知道第一个response已经结束,接着构建的 http/1.1 200 ok则让服务器认为第二个response已经产生。
攻击演示:
1.正常的查询访问后,如果没有查询到,程序利用location给用户返回原始的查询页面,并在返回的时候将用户之前查询的数据放到URI中,以便后面的页面提取URI参数。

2.在查询中刻意填入如下内容并提交
myf5%0d%0acontent-length:%200%0d%0a%0d%0ahttp/1.1%20200%20ok%0d%0a%0d%0a%0d%0a<html>hacked!</html>

3.服务器做正确响应,并将用户提交的数据放入location中的uri里

4.接着浏览器重新发送location中的uri get请求

5.服务器响应情况


防范方法:
在将用户数据放入uri之前应充分过滤,避免特殊字符。
使用WEB应用防火墙过滤cr lf
http://www.myf5.net/request/
整合 Apache Http Server 和 Tomcat 可以提升对静态文件的处理性能、利用 Web 服务器来做负载均衡以及容错、无缝的升级应用程序。本文介绍了三种整合 Apache 和 Tomcat 的方式。
首先我们先介绍一下为什么要让 Apache 与 Tomcat 之间进行连接。事实上 Tomcat 本身已经提供了 HTTP 服务,该服务默认的端口是 8080,装好 tomcat 后通过 8080 端口可以直接使用 Tomcat 所运行的应用程序,你也可以将该端口改为 80。
既然 Tomcat 本身已经可以提供这样的服务,我们为什么还要引入 Apache 或者其他的一些专门的 HTTP 服务器呢?原因有下面几个:
1. 提升对静态文件的处理性能
2. 利用 Web 服务器来做负载均衡以及容错
3. 无缝的升级应用程序
这三点对一个 web 网站来说是非常之重要的,我们希望我们的网站不仅是速度快,而且要稳定,不能因为某个 Tomcat 宕机或者是升级程序导致用户访问不了,而能完成这几个功能的、最好的 HTTP 服务器也就只有 apache 的 http server 了,它跟 tomcat 的结合是最紧密和可靠的。
接下来我们介绍三种方法将 apache 和 tomcat 整合在一起。
这是最常见的方式,你可以在网上找到很多关于配置JK的网页,当然最全的还是其官方所提供的文档。JK 本身有两个版本分别是 1 和 2,目前 1 最新的版本是 1.2.19,而版本 2 早已经废弃了,以后不再有新版本的推出了,所以建议你采用版本 1。
JK 是通过 AJP 协议与 Tomcat 服务器进行通讯的,Tomcat 默认的 AJP Connector 的端口是 8009。JK 本身提供了一个监控以及管理的页面 jkstatus,通过 jkstatus 可以监控 JK 目前的工作状态以及对到 tomcat 的连接进行设置,如下图所示:
在这个图中我们可以看到当前JK配了两个连接分别到 8109 和 8209 端口上,目前 s2 这个连接是停止状态,而 s1 这个连接自上次重启后已经处理了 47 万多个请求,流量达到 6.2 个 G,最大的并发数有 13 等等。我们也可以利用 jkstatus 的管理功能来切换 JK 到不同的 Tomcat 上,例如将 s2 启用,并停用 s1,这个在更新应用程序的时候非常有用,而且整个切换过程对用户来说是透明的,也就达到了无缝升级的目的。关于 JK 的配置文章网上已经非常多了,这里我们不再详细的介绍整个配置过程,但我要讲一下配置的思路,只要明白了配置的思路,JK 就是一个非常灵活的组件。
JK 的配置最关键的有三个文件,分别是
httpd.conf
Apache 服务器的配置文件,用来加载 JK 模块以及指定 JK 配置文件信息
workers.properties
到 Tomcat 服务器的连接定义文件
uriworkermap.properties
URI 映射文件,用来指定哪些 URL 由 Tomcat 处理,你也可以直接在 httpd.conf 中配置这些 URI,但是独立这些配置的好处是 JK 模块会定期更新该文件的内容,使得我们修改配置的时候无需重新启动 Apache 服务器。
其中第二、三个配置文件名都可以自定义。下面是一个典型的 httpd.conf 对 JK 的配置
# (httpd.conf)# 加载 mod_jk 模块LoadModule jk_module modules/mod_jk.so## Configure mod_jk#JkWorkersFile conf/workers.propertiesJkMountFile conf/uriworkermap.propertiesJkLogFile logs/mod_jk.logJkLogLevel warn |
接下来我们在 Apache 的 conf 目录下新建两个文件分别是 workers.properties、uriworkermap.properties。这两个文件的内容大概如下
## workers.properties## list the workers by nameworker.list=DLOG4J, status# localhost server 1# ------------------------worker.s1.port=8109worker.s1.host=localhostworker.s1.type=ajp13# localhost server 2# ------------------------worker.s2.port=8209worker.s2.host=localhostworker.s2.type=ajp13worker.s2.stopped=1worker.DLOG4J.type=lbworker.retries=3worker.DLOG4J.balanced_workers=s1, s2worker.DLOG4J.sticky_session=1worker.status.type=status |
以上的 workers.properties 配置就是我们前面那个屏幕抓图的页面所用的配置。首先我们配置了两个类型为 ajp13 的 worker 分别是 s1 和 s2,它们指向同一台服务器上运行在两个不同端口 8109 和 8209 的 Tomcat 上。接下来我们配置了一个类型为 lb(也就是负载均衡的意思)的 worker,它的名字是 DLOG4J,这是一个逻辑的 worker,它用来管理前面配置的两个物理连接 s1 和 s2。最后还配置了一个类型为 status 的 worker,这是用来监控 JK 本身的模块。有了这三个 worker 还不够,我们还需要告诉 JK,哪些 worker 是可用的,所以就有 worker.list = DLOG4J, status 这行配置。
接下来便是 URI 的映射配置了,我们需要指定哪些链接是由 Tomcat 处理的,哪些是由 Apache 直接处理的,看看下面这个文件你就能明白其中配置的意义
/*=DLOG4J/jkstatus=status!/*.gif=DLOG4J!/*.jpg=DLOG4J!/*.png=DLOG4J!/*.css=DLOG4J!/*.js=DLOG4J!/*.htm=DLOG4J!/*.html=DLOG4J |
相信你已经明白了一大半了:所有的请求都由 DLOG4J 这个 worker 进行处理,但是有几个例外,/jkstatus 请求由 status 这个 worker 处理。另外这个配置中每一行数据前面的感叹号是什么意思呢?感叹号表示接下来的 URI 不要由 JK 进行处理,也就是 Apache 直接处理所有的图片、css 文件、js 文件以及静态 html 文本文件。
通过对 workers.properties 和 uriworkermap.properties 的配置,可以有各种各样的组合来满足我们前面提出对一个 web 网站的要求。您不妨动手试试!
|
这是利用 Apache 自带的 mod_proxy 模块使用代理技术来连接 Tomcat。在配置之前请确保是否使用的是 2.2.x 版本的 Apache 服务器。因为 2.2.x 版本对这个模块进行了重写,大大的增强了其功能和稳定性。
http_proxy 模式是基于 HTTP 协议的代理,因此它要求 Tomcat 必须提供 HTTP 服务,也就是说必须启用 Tomcat 的 HTTP Connector。一个最简单的配置如下
ProxyPass /images !ProxyPass /css !ProxyPass /js !ProxyPass / http://localhost:8080/ |
在这个配置中,我们把所有 http://localhost 的请求代理到 http://localhost:8080/ ,这也就是 Tomcat 的访问地址,除了 images、css、js 几个目录除外。我们同样可以利用 mod_proxy 来做负载均衡,再看看下面这个配置
ProxyPass /images !ProxyPass /css ! ProxyPass /js !ProxyPass / balancer://example/<Proxy balancer://example/>BalancerMember http://server1:8080/BalancerMember http://server2:8080/BalancerMember http://server3:8080/</Proxy> |
配置比 JK 简单多了,而且它也可以通过一个页面来监控集群运行的状态,并做一些简单的维护设置。
|
ajp_proxy 连接方式其实跟 http_proxy 方式一样,都是由 mod_proxy 所提供的功能。配置也是一样,只需要把 http:// 换成 ajp:// ,同时连接的是 Tomcat 的 AJP Connector 所在的端口。上面例子的配置可以改为:
ProxyPass /images !ProxyPass /css ! ProxyPass /js !ProxyPass / balancer://example/<Proxy balancer://example/>BalancerMember ajp://server1:8080/BalancerMember ajp://server2:8080/BalancerMember ajp://server3:8080/</Proxy> |
采用 proxy 的连接方式,需要在 Apache 上加载所需的模块,mod_proxy 相关的模块有 mod_proxy.so、mod_proxy_connect.so、mod_proxy_http.so、mod_proxy_ftp.so、mod_proxy_ajp.so, 其中 mod_proxy_ajp.so 只在 Apache 2.2.x 中才有。如果是采用 http_proxy 方式则需要加载 mod_proxy.so 和 mod_proxy_http.so;如果是 ajp_proxy 则需要加载 mod_proxy.so 和 mod_proxy_ajp.so这两个模块。
|
相对于 JK 的连接方式,后两种在配置上是比较简单的,灵活性方面也一点都不逊色。但就稳定性而言就不像 JK 这样久经考验,毕竟 Apache 2.2.3 推出的时间并不长,采用这种连接方式的网站还不多,因此,如果是应用于关键的互联网网站,还是建议采用 JK 的连接方式。
在线DNS检测工具,类似与 dig
在线检查你的mx是否可以正常工作
[URL=http://]http://hexillion.com/asp/samples/ValidateEmail.asp[/URL]