以下是小编为大家收集的通过nginx配置文件抵御攻击WEB安全，本文共10篇，希望对大家有所帮助。
篇1：通过nginx配置文件抵御攻击WEB安全
简易版
我们先来做个比喻。
社区在搞福利，在广场上给大家派发红包。而坏人派了一批人形的机器人(没有语言模块)来冒领红包，聪明工作人员需要想出办法来防止红包被冒领。
于是工作人员在发红包之前，会给领取者一张纸，上面写着“红包拿来”，如果那人能念出纸上的字，那么就是人，给红包，如果你不能念出来，那么请自觉。于是机器人便被识破，灰溜溜地回来了。
是的，在这个比喻中，人就是浏览器，机器人就是攻击器，我们可以通过鉴别cookie功能(念纸上的字)的方式来鉴别他们。下面就是nginx的配置文件写法。
1
2
3
4
if($cookie_say !=“hbnl”){
add_header Set-Cookie“say=hbnl”;
rewrite .*“$scheme://$host$uri”redirect;
}
让我们看下这几行的意思，当cookie中say为空时，给一个设置cookie say为hbnl的302重定向包，如果访问者能够在第二个包中携带上cookie值，那么就能正常访问网站了，如果不能的话，那他永远活在了302中。你也可以测试一下，用CC攻击
器或者webbench或者直接curl发包做测试，他们都活在了302世界中。当然，这么简单就能防住了？当然没有那么简单。
增强版
仔细的你一定会发现配置文件这样写还是有缺陷。如果攻击者设置cookie为say=hbnl（CC攻击器上就可以这么设置），那么这个防御就形同虚设了。我们继续拿刚刚那个比喻来说明问题。
坏人发现这个规律后，给每个机器人安上了扬声器，一直重复着“红包拿来，红包拿来”，浩浩荡荡地又来领红包了。
这时，工作人员的对策是这样做的，要求领取者出示有自己名字的户口本，并且念出自己的名字，“我是xxx，红包拿来”。于是一群只会嗡嗡叫着“红包拿来”的机器人又被撵回去了。
当然，为了配合说明问题，每个机器人是有户口本的，被赶回去的原因是不会念自己的名字，虽然这个有点荒诞，唉。
然后，我们来看下这种方式的配置文件写法
1
2
3
4
if($cookie_say !=“hbnl$remote_addr”){
add_header Set-Cookie“say=hbnl$remote_addr”;
rewrite .*“$scheme://$host$uri”redirect;
}
这样的写法和前面的区别是，不同IP的请求cookie值是不一样的，比如IP是1.2.3.4，那么需要设置的cookie是say=hbnl1.2.3.4。于是攻击者便无法通过设置一样的cookie(比如CC攻击器)来绕过这种限制。你可以继续用CC攻击器来测试下，你会发现CC攻击器打出的流量已经全部进入302世界中。
不过大家也能感觉到，这似乎也不是一个万全之计，因为攻击者如果研究了网站的机制之后，总有办法测出并预先伪造cookie值的设置方法。因为我们做差异化的数据源正是他们本身的一些信息（IP、user agent等）。攻击者花点时间也是可以做出专门针对网站的攻击脚本的。
完美版
那么要如何根据他们自身的信息得出他们又得出他们算不出的数值？
我想，聪明的你一定已经猜到了，用salt加散列。比如md5(“opencdn$remote_addr”)，虽然攻击者知道可以自己IP，但是他无法得知如何用他的IP来计算出这个散列，因为他是逆不出这个散列的。当然，如果你不放心的话，怕cmd5.com万一能查出来的话，可以加一些特殊字符，然后多散几次。
很可惜，nginx默认是无法进行字符串散列的，于是我们借助nginx_lua模块来进行实现。
1
2
3
4
5
6
7
rewrite_by_lua '
localsay = ngx.md5(“opencdn”.. ngx.var.remote_addr)
if(ngx.var.cookie_say ~= say)then
ngx.header[“Set-Cookie”] =“say=”.. say
returnngx.redirect(ngx.var.scheme ..“://”.. ngx.var.host .. ngx.var.uri)
end
';
通过这样的配置，攻击者便无法事先计算这个cookie中的say值，于是攻击流量(代理型CC和低级发包型CC)便在302地狱无法自拔了。
大家可以看到，除了借用了md5这个函数外，其他的逻辑和上面的写法是一模一样的。因此如果可以的话，你完全可以安装一个nginx的计算散列的第三方模块来完成，可能效率会更高一些。这段配置是可以被放在任意的location里面，如果你的网站有对外提供API功能的话，建议API一定不能加入这段，因为API的调用也是没有浏览器行为的，会被当做攻击流量处理。并且，有些弱一点爬虫也会陷在302之中，这个需要注意。
同时，如果你觉得set-cookie这个动作似乎攻击者也有可能通过解析字符串模拟出来的话，你可以把上述的通过header来设置cookie的操作，变成通过高端大气的js完成，发回一个含有doument.cookie=...的文本即可。
那么，攻击是不是完全被挡住了呢？只能说那些低级的攻击已经被挡住而来，如果攻击者必须花很大代价给每个攻击器加上webkit模块来解析js和执行set-cookie才行，那么他也是可以逃脱302地狱的，在nginx看来，确实攻击流量和普通浏览流量是一样的。那么如何防御呢？下节会告诉你答案。
篇2：通过nginx配置文件抵御攻击
大家好，我们是OpenCDN团队的Twwy，这次我们来讲讲如何通过简单的配置文件来实现nginx防御攻击的效果。
其实很多时候，各种防攻击的思路我们都明白，比如限制IP啊，过滤攻击字符串啊，识别攻击指纹啦。可是要如何去实现它呢？用守护脚本吗？用PHP在外面包一层过滤？还是直接加防火墙吗？这些都是防御手段。不过本文将要介绍的是直接通过nginx的普通模块和配置文件的组合来达到一定的防御效果。
篇3：通过nginx配置文件抵御攻击
不得不说，很多防CC的措施是直接在请求频率上做限制来实现的，但是，很多都存在着一定的问题。
那么是哪些问题呢？
首先，如果通过IP来限制请求频率，容易导致一些误杀，比如我一个地方出口IP就那么几个，而访问者一多的话，请求频率很容易到上限，那么那个地方的用户就都访问不了你的网站了。
于是你会说，我用SESSION来限制就有这个问题了。嗯，你的SESSION为攻击者敞开了一道大门。为什么呢？看了上文的你可能已经大致知道了，因为就像那个“红包拿来”的扬声器一样，很多语言或者框架中的SESSION是能够伪造的，
以PHP为例，你可以在浏览器中的cookie看到PHPSESSIONID，这个ID不同的话，session也就不同了，然后如果你杜撰一个PHPSESSIONID过去的话，你会发现，服务器也认可了这个ID，为这个ID初始化了一个会话。那么，攻击者只需要每次发完包就构造一个新的SESSIONID就可以很轻松地躲过这种在session上的请求次数限制。
那么我们要如何来做这个请求频率的限制呢？
首先，我们先要一个攻击者无法杜撰的sessionID，一种方式是用个池子记录下每次给出的ID，然后在请求来的时候进行查询，如果没有的话，就拒绝请求。这种方式我们不推荐，首先一个网站已经有了session池，这样再做个无疑有些浪费，而且还需要进行池中的遍历比较查询，太消耗性能。我们希望的是一种可以无状态性的sessionID，可以吗？可以的。
rewrite_by_lua ' local random = ngx.var.cookie_random if(random == nil) then random = math.random(999999) end local token = ngx.md5(“opencdn” .. ngx.var.remote_addr .. random) if (ngx.var.cookie_token ~= token) then ngx.header[“Set-Cookie”] = {“token=” .. token, “random=” .. random} return ngx.redirect(ngx.var.scheme .. “://” .. ngx.var.host .. ngx.var.uri) end';
大家是不是觉得好像有些眼熟？是的，这个就是上节的完美版的配置再加个随机数，为的是让同一个IP的用户也能有不同的token。同样的，只要有nginx的第三方模块提供散列和随机数功能，这个配置也可以不用lua直接用纯配置文件完成。
有了这个token之后，相当于每个访客有一个无法伪造的并且独一无二的token，这种情况下，进行请求限制才有意义。
由于有了token做铺垫，我们可以不做什么白名单、黑名单，直接通过limit模块来完成。
http{ ... limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s;}
然后我们只需要在上面的token配置后面中加入
limit_req zone=session_limit burst=5;
于是，又是两行配置便让nginx在session层解决了请求频率的限制。不过似乎还是有缺陷，因为攻击者可以通过一直获取token来突破请求频率限制，如果能限制一个IP获取token的频率就更完美了。可以做到吗？可以。
http{ ... limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s; limit_req_zone $binary_remote_addr $uri zone=auth_limit:3m rate=1r/m;}
location /{ limit_req zone=session_limit burst=5; rewrite_by_lua ' local random = ngx.var.cookie_random if (random == nil) thenreturn ngx.redirect(“/auth?url=” .. ngx.var.request_uri) end local token = ngx.md5(“opencdn” .. ngx.var.remote_addr .. random) if (ngx.var.cookie_token ~= token) thenreturn ngx.redirect(“/auth?url=”.. ngx.var.request_uri) end ';}location /auth { limit_req zone=auth_limit burst=1; if ($arg_url = “”) {return 403; } access_by_lua 'local random = math.random(9999)local token = ngx.md5(“opencdn” .. ngx.var.remote_addr .. random)if (ngx.var.cookie_token ~= token) then ngx.header[“Set-Cookie”] = {“token=” .. token, “random=” .. random} return ngx.redirect(ngx.var.arg_url)end ';}
我想大家也应该已经猜到，这段配置文件的原理就是：把本来的发token的功能分离到一个auth页面，然后用limit对这个auth页面进行频率限制即可。这边的频率是1个IP每分钟授权1个token。当然，这个数量可以根据业务需要进行调整。
需要注意的是，这个auth部分我lua采用的是access_by_lua，原因在于limit模块是在rewrite阶段后执行的，如果在rewrite阶段302的话，limit将会失效。因此，这段lua配置我不能保证可以用原生的配置文件实现，因为不知道如何用配置文件在rewrite阶段后进行302跳转，也求大牛能够指点一下啊。
当然，你如果还不满足于这种限制的话，想要做到某个IP如果一天到达上限超过几次之后就直接封IP的话，也是可以的，你可以用类似的思路再做个错误页面，然后到达上限之后不返回503而是跳转到那个错误页面，然后错误页面也做个请求次数限制，比如每天只能访问100次，那么当超过报错超过100次(请求错误页面100次)之后，那天这个IP就不能再访问这个网站了。
于是，通过这些配置我们便实现了一个网站访问频率限制。不过，这样的配置也不是说可以完全防止了攻击，只能说让攻击者的成本变高，让网站的扛攻击能力变强，当然，前提是nginx能够扛得住这些流量，然后带宽不被堵死。如果你家门被堵了，你还想开门营业，那真心没有办法了。
然后，做完流量上的防护，让我们来看看对于扫描器之类的攻击的防御。
篇4：通过nginx配置文件抵御攻击
ngx_lua_waf模块
这个是一个不错的waf模块，这块我们也就不再重复造轮子了。可以直接用这个模块来做防护，当然也完全可以再配合limit模块，用上文的思路来做到一个封IP或者封session的效果。
篇5：通过nginx配置文件抵御攻击
简易版
我们先来做个比喻。
社区在搞福利，在广场上给大家派发红包。而坏人派了一批人形的机器人(没有语言模块)来冒领红包，聪明工作人员需要想出办法来防止红包被冒领。
于是工作人员在发红包之前，会给领取者一张纸，上面写着“红包拿来”，如果那人能念出纸上的字，那么就是人，给红包，如果你不能念出来，那么请自觉。于是机器人便被识破，灰溜溜地回来了。
是的，在这个比喻中，人就是浏览器，机器人就是攻击器，我们可以通过鉴别cookie功能(念纸上的字)的方式来鉴别他们。下面就是nginx的配置文件写法。
if ($cookie_say != “hbnl”){ add_header Set-Cookie “say=hbnl”; rewrite .* “$scheme://$host$uri” redirect;}
让我们看下这几行的意思，当cookie中say为空时，给一个设置cookie say为hbnl的302重定向包，如果访问者能够在第二个包中携带上cookie值，那么就能正常访问网站了，如果不能的话，那他永远活在了302中。你也可以测试一下，用CC攻击器或者webbench或者直接curl发包做测试，他们都活在了302世界中。
当然，这么简单就能防住了？当然没有那么简单。
增强版
仔细的你一定会发现配置文件这样写还是有缺陷。如果攻击者设置cookie为say=hbnl（CC攻击器上就可以这么设置），那么这个防御就形同虚设了。我们继续拿刚刚那个比喻来说明问题。
坏人发现这个规律后，给每个机器人安上了扬声器，一直重复着“红包拿来，红包拿来”，浩浩荡荡地又来领红包了。
这时，工作人员的对策是这样做的，要求领取者出示有自己名字的户口本，并且念出自己的名字，“我是xxx，红包拿来”。于是一群只会嗡嗡叫着“红包拿来”的机器人又被撵回去了。
当然，为了配合说明问题，每个机器人是有户口本的，被赶回去的原因是不会念自己的名字，虽然这个有点荒诞，唉。
然后，我们来看下这种方式的配置文件写法
if ($cookie_say != “hbnl$remote_addr”){ add_header Set-Cookie “say=hbnl$remote_addr”; rewrite .* “$scheme://$host$uri” redirect;}
这样的写法和前面的区别是，不同IP的请求cookie值是不一样的，比如IP是1.2.3.4，那么需要设置的cookie是say=hbnl1.2.3.4。于是攻击者便无法通过设置一样的cookie(比如CC攻击器)来绕过这种限制。你可以继续用CC攻击器来测试下，你会发现CC攻击器打出的流量已经全部进入302世界中。
不过大家也能感觉到，这似乎也不是一个万全之计，因为攻击者如果研究了网站的机制之后，总有办法测出并预先伪造cookie值的设置方法。因为我们做差异化的数据源正是他们本身的一些信息（IP、user agent等）。攻击者花点时间也是可以做出专门针对网站的攻击脚本的。
完美版
那么要如何根据他们自身的信息得出他们又得出他们算不出的数值？
我想，聪明的你一定已经猜到了，用salt加散列。比如md5(“opencdn$remote_addr”)，虽然攻击者知道可以自己IP，但是他无法得知如何用他的IP来计算出这个散列，因为他是逆不出这个散列的。当然，如果你不放心的话，怕cmd5.com万一能查出来的话，可以加一些特殊字符，然后多散几次。
很可惜，nginx默认是无法进行字符串散列的，于是我们借助nginx_lua模块来进行实现。
rewrite_by_lua ' local say = ngx.md5(“opencdn” .. ngx.var.remote_addr) if (ngx.var.cookie_say ~= say) then ngx.header[“Set-Cookie”] = “say=” .. say return ngx.redirect(ngx.var.scheme .. “://” .. ngx.var.host .. ngx.var.uri) end';
通过这样的配置，攻击者便无法事先计算这个cookie中的say值，于是攻击流量(代理型CC和低级发包型CC)便在302地狱无法自拔了。
大家可以看到，除了借用了md5这个函数外，其他的逻辑和上面的写法是一模一样的。因此如果可以的话，你完全可以安装一个nginx的计算散列的第三方模块来完成，可能效率会更高一些。
这段配置是可以被放在任意的location里面，如果你的网站有对外提供API功能的话，建议API一定不能加入这段，因为API的调用也是没有浏览器行为的，会被当做攻击流量处理。并且，有些弱一点爬虫也会陷在302之中，这个需要注意。
同时，如果你觉得set-cookie这个动作似乎攻击者也有可能通过解析字符串模拟出来的话，你可以把上述的通过header来设置cookie的操作，变成通过高端大气的js完成，发回一个含有doument.cookie=...的文本即可。
那么，攻击是不是完全被挡住了呢？只能说那些低级的攻击已经被挡住而来，如果攻击者必须花很大代价给每个攻击器加上webkit模块来解析js和执行set-cookie才行，那么他也是可以逃脱302地狱的，在nginx看来，确实攻击流量和普通浏览流量是一样的。那么如何防御呢？下节会告诉你答案。
篇6：大型机如何抵御 入侵WEB安全
在大型机兴起之初，它的使用环境是非常安全的，用户可以将终端系统与大型机相连，这样大型机就能控制数据存储的访问路径和权限，掌控用户的使用信息和来源。
但时至今日我们使用的是面向服务的体系架构(SOA)，在与后端系统连接之前会有一系列的计算机发出请求。用户也分为不同的级别。因此大型机的后端就无法实际确认用户真正的身份和授权的地点。所以，在分布式计算机的领域，当用户准备访问大型机数据时，安全状况就变得前景堪忧。
另外，目前真正了解大型机的专家实在寥寥可数--他们多数都已退居二线。因此当用户访问大型机并分享数据时，内忧外患也是越来越多。
大型机是座宝库
威利萨顿(willie sutton)是十九世纪二十年代闻名一时的银行大盗，在他被抓获后有人问他“威利，你为什么抢劫银行呢？”他老实回答说“因为那里有钱”。
如果威利能活到今天，我敢打赌他一定是名入侵终端数据库的 ，因为钱就在那里，或者说至少那里拥有很有价值的信息。大型机对于那些恶意的电脑 来说就是令人垂涎的攻击目标， 典型的做法是在网络协议的掩护下去读取数据。当大型机看到诸如FTP或者HTTP这样的协议时基本都会予以批准，如果这是个SQL注入攻击(SQL injection attack)，那么大型机根本就无能无力。
大型机的安全保障
与其不断安装大型机应用软件不如借此机会适时增加基础架构的功能，毕竟开发应用软件也并非易事。因此用户应该将安全功能外置诸如数据库，应用软件或者网络服务器之上，增加另外的安全层也是非常有效的方法。
这个单独的层将弥补安全鉴定的空白。举例来说，如果有 窃取了用户密码就会绕过安全验证系统，那么用户还有另外的安全层权限来访问数据。因此，增加更高权限的安全线和深度防护措施是十分关键的，
深度防护流程
首先职权分离能有助于抵御来自内部和外部的攻击。设置网络应用软件防火墙是抵御 攻击的第一道防线，这也相当于将威利萨顿挡在门外的安全电网。
其次你需要防范数据外流的风险，单独的入侵检测和审核还远远不够。你需要防止意外情况下数据被窃取，因此你要找到合适的方法对数据进行锁定。加密技术是最好的方法。如果能够正确的运用，这也是让你免受数据外泄风险的唯一方法。
入侵检测也是基本方式。如果你的系统处于危险之中，你就必须设置防护层来阻止攻击者入侵系统窃取数据。Protegrity公司拥有一项技术专利就是根据在系统上用户常规活动的历史记录为基础来限定其访问的数据流量。
举例来说，如果某人通常在一周内每天下载的数据量是500条记录，周末没有访问量。那么我们的系统就会鉴别某人的数据下载量不超过10,000条或者周末晚上不能下载数据。
最后，对你的用户实施监控。一旦你对数据进行了锁定，你就需要关注它的运行情况。是否有未经授权的请求?是否有 的攻击企图?你必须关注这些问题，如果用户出现滥用数据的情况能及时的加以制止。
由此可见大型机安全方和的三大要素：网络应用软件防火墙，加密技术和监控措施。
大型机安全防护的支柱 各个方面的安全检查
是时候对之前所忽略的安全系统进行全面的检查。举例来说，检查你的数据库，看看是否有人试图读取你数据库中的信用卡信息。如果你发现有 以有效的用户身份访问信用卡信息，我们就应该对其访问的数据量增加相应的功能设置。
如果你的用户身份存在危险，你就应该设置防护层来阻止入侵者来获取更多的信息。你也可以通过数据使用控制来对入侵进行检测或者阻止 攻击的速度。目前我们在基于行为的入侵检测技术已经获取了专利许可。我们之所以开发这项技术是因为我认为它在数据驱动防护层方面颇有成效。
对于基于行为的访问加以限制在物理世界是非常自然的事。就像按方抓药或者去自动提款机限额取钱一样的道理。这些都是非常成功的安全系统能从逻辑上限定人们的行为。我认为这种方法也同样适用于IT领域的安全防护。
篇7：Apache防止攻击WEB安全
为了防止恶意用户对Apache进行攻击，我们需要安装mod_security这个安全模块
mod_security 1.9.x模块的下载与安装
下载地址：www.modsecurity.org/download/
建议使用1.9.x，因为2.x的配置指令与1.x完全不同，解压后进入解压目录，执行：
/home/apache/bin/apxs -cia mod_security.c
编译完成后，/home/apache/modules下会生成一个mod_security.so文件
然后kate /home/apache/conf/httpd.conf
加入以下选项（如果没有的话）
#启用mod_security这个安全模块
LoadModule security_module modules/mod_security.so (这一句通常会被自动加入)
# 打开过滤引擎开关，如果是Off，那么下面这些都不起作用了。
SecFilterEngine On
# 把设置传递给字目录
SecFilterInheritance Off
# 检查url编码
SecFilterCheckURLEncoding On
# 检测内容长度以避免堆溢出攻击
#SecFilterForceByteRange 32 126
# 日志的文件和位置。一定要先建立好目录，否则apache重新启动的时候会报错。
SecAuditLog logs/audit_log
# debug的设置
#SecFilterDebugLog logs/modsec_debug_log
#SecFilterDebugLevel 1
#当匹配chmod,wget等命令的时候,重新定向到一个特殊的页面,让攻击者知难而退
SecFilter chmod redirect:www.sina.com
SecFilter wget redirect:www.sina.com
#检测POST数据，注意，请甚用这个开关，可能会导致一些post页面无法访问。详细的信息，请察看www.modsecurity.org的文档，其中有详细的post编码要求。
#SecFilterScanPOST Off
# 缺省的动作
SecFilterDefaultAction “deny,log,status:406″
# 重新定向用户
#SecFilter xxx redirect:www.sina.com
# 防止操作系统关键词攻击
SecFilter /etc/*passwd
SecFilter /bin/*sh
# 防止double dot攻击
SecFilter “\.\./”
# 防止跨站脚本(CSS)攻击
SecFilter “<( |\n)*script”
# Prevent XSS atacks (HTML/Javascript. injection)
SecFilter “<(.|\n)+>”
# 防止sql注入式攻击
SecFilter “delete[[:space:]]+from”
SecFilter “insert[[:space:]]+into”
SecFilter “select.+from”
#重定向exe和asp请求
SecFilterSelective REQUEST_URI “\.exe” “redirect:www.google.com”
SecFilterSelective REQUEST_URI “\.asp” “redirect:www.google.com”
#下面是限制了upload.php文件只能用来上传jpeg.bmp和gif的图片
#
#SecFilterInheritance On
#SecFilterSelective POST_PAYLOAD “!image/(jpeg|bmp|gif)”
#
#伪装服务器标识
SecServerSignature “Microsoft-IIS/6.0″
保存后重启apache即可！
为了防止Web服务器被DDoS攻击，我们需要安装mod_evasive这个防DDoS的模块
mod_evasive 1.10.x防DDoS模块的下载与安装
下载地址：www.zdziarski.com/projects/mod_evasive/
解压后进入解压目录，执行
/home/apache/bin/apxs -cia mod_evasive20.c
编译完成后，/home/apache/modules下会生成一个mod_evasive20.so文件
然后kate /home/apache/conf/httpd.conf
加入以下选项（如果没有的话）
#启用mod_evasive for Apache 2.x防DDoS模块
LoadModule evasive20_module modules/mod_evasive20.so (这一句通常会被自动加入)
#记录和存放黑名单的哈西表大小，如果服务器访问量很大，可以加大该值
DOSHashTableSize 3097
#同一个页面在同一时间内可以被统一个用户访问的次数，超过该数字就会被列为攻击，同一时间的数值可以在DosPageInterval参数中设置，
DOSPageCount 3
#同一个用户在同一个网站内可以同时打开的访问数，同一个时间的数值在DOSSiteInterval中设置。
DOSSiteCount 40
#设置DOSPageCount中时间长度标准，默认值为1。
DOSPageInterval 2
#DOSSiteInterval 2 设置DOSSiteCount中时间长度标准，默认值为1。
DOSSiteInterval 2
#被封时间间隔秒，这中间会收到 403 (Forbidden) 的返回。
DOSBlockingPeriod 10
#设置受到攻击时接收攻击信息提示的邮箱地址。
#DOSEmailNotify
#受到攻击时Apache运行用户执行的系统命令
#DOSSystemCommand “su - someuser -c ‘/sbin/… %s …’”
#攻击日志存放目录，BSD上默认是 /tmp
#DOSLogDir “/var/lock/mod_evasive”
SecFilterEngine On
SecFilterCheckURLEncoding On
SecFilterDefaultAction “deny,log,status:500”
#SecFilterForceByteRange 32 126
#SecFilterScanPOST On
SecAuditLog logs/audit_log
###
SecFilter “\.\./”
#####
SecFilter /etc/*passwd
SecFilter /bin/*sh
#for css attack
SecFilter “<( | )*script”
SecFilter “<(.| )+>”
#for sql attack
SecFilter “delete[ ]+from”
SecFilter “insert[ ]+into”
SecFilter “select.+from”
SecFilter “union[ ]+from”
SecFilter “drop[ ]”
篇8：简单抵御抵抗WVS扫描WEB安全
简单思路整理：
作者通过本地搭建环境，模拟wvs扫描，查看日志，从日志中分析 wvs的扫描特点，程序里面加以控制， 日志中wvs的扫描请求的特点是：
通过分析包的格式，前期的探测脚本http头带着的关键参数如下：
GET /acunetix-wvs-test-for-some-inexistent-file HTTP/1.1
Accept: acunetix/wvs
Expect:
Cookie: acunetixCookie=AAAAAAAA...N个A...AAAAAAAA
GET /ClientAccessPolicy.xml HTTP/1.1 类似这样的查找robots.txt 各种 xml常见文件
GET /favicon.ico HTTP/1.1特别有意思的就是这个favicon.ico文件，在日志文件中发现这个文件被访问了N+1多次...
POST localhost:8443/enterprise/control/agent.php HTTP/1.1
ACUNETIX /9149447 HTTP/1.1
HTTP_AUTH_LOGIN: '
HTTP_AUTH_PASSWD: acunetix
Client-IP: SomeCustomInjectedHeader:injected_by_wvs
Referer: ';print(md5(acunetix_wvs_security_test));$a='
Accept: acunetix/wvs
Acunetix-Aspect: enabled
Acunetix-Aspect-Password: 082119f75623eb7abd7bf357698ff66c
Acunetix-Aspect-Queries: filelist;aspectalerts
前期扫描一些比较奇葩的漏洞都会带以下参数
Accept: acunetix/wvs
后期的XSS和SQL扫描大概看了下特征的字符就是以下字符
Acunetix-Aspect:
Acunetix-Aspect-Password:
Acunetix-Aspect-Queries:
思路：
检测HTTP头中的
参数：值
任意包含acunetix中就禁止访问，顺便再返回一个500服务器错误，
禁止的方法想了好几种，网上有关这个的就看到当初oldjun和heige的两个思路。不过貌似都不太适合，有兴趣的同学可以自己看看。
因为分析发现扫描过程中一些SQL注入脚本或者其他脚本是不包含以上提到的关键字。
因此想到利用session或者cookie来判断是否恶意请求，判断成立就500，是不是简单粗暴！
看看代码（相当简陋）
if(isset($_COOKIE[“PHPinfoTest”]))
{
header('HTTP/1.1 500 Internal Server Error');
exit;
}else{
foreach ($_SERVER as $key =>$value) {
If(strpos(strtolower($key),“acunetix”)!==false||strpos(strtolower($value),“acunetix”)!==false){
header('HTTP/1.1 500 Internal Server Error');
setcookie(“PHPinfoTest”,“IZIEMILOULOAIXNAUHIXLOAIX”,time()+60);
exit();
}
}
}
篇9：教你如何防范Qzone攻击WEB安全
由于QQ在桌面IM领域占据着绝对霸主地位，在其身上衍生的各种产品也变得日益流行，而Qzone也逐渐成为网友书写日志和展示个性的地方，因此，Qzone的安全性也备受关注。不过，Qzone近日却爆出了一个跨站漏洞，这个漏洞非常容易被 利用。那么， 一般会如何通过这个漏洞来攻击普通用户呢？作为用户，我们又如何来防范这一漏洞的危害呢？
一、模拟 攻击
这里，我们首先来了解这个漏洞的具体情况。Qzone的跨站漏洞是网友无意中打开类似“hxxp://u ser.qzone.qq.com/QQ号码?url=任意字母”时发现的，这时网页显示为一个框架网页，中间为“无法打开网页”的空白页面（如图1）；然而，当输入类似“hxxp://u ser.qzone.qq.com/QQ号码?url=www.baidu.com”的地址时却可以正常显示，这时url后的网址其实在幕后是加载的。那么，Qzone的跨站漏洞又是如何被 作为木马的媒介的呢？
第一步： 需要对该地址进行乔装改扮一番。比如：网页木马的url为“www.muma.com/muma.exe”。 会使用URl加密技术来为木马地址作掩护，常用的方法是把url地址转换为16进制，这里以ASCII码随心换为例（如图2）进行示范。
第二步： 将Qzone的地址设置为“hxxp://u ser.qzone.qq.com/QQ号码?url=%68%74%74%70%3A%2F%2F%77%77%77%2E%6D%75%6D%61%2E%63%6F%6D%2F%6D%75%6D%61%2E%65%78%65”并在网页上贴出Qzone的地址来引诱网友点击，用户往往点击了该地址下载运行了木马还蒙在鼓里。
二、如何防范Qzone攻击
方法1：既然这一跨站漏洞这么隐蔽，用户感染的几率也不会低，
我们需要如何来防范这一漏洞可能造成的危害呢？做到不感染病毒，未雨绸缪是最有效果的。因此，我们在访问网友的Qzone前，要多长几个心眼，要观察其网址的形式。
一般正常的Qzone的地址是“hxxp://u ser.qzone.qq.com/号码”或者“号码.qzone.qq.com/”形式的，如果出现“hxxp://u ser.qzone.qq.com/QQ号码?url=”的地址就要谨慎了，Qzone也可能出现类似“hxxp://u ser.qzone.qq.com/号码/?url=http%3A//photo.qq.com/tips_jump.htm%23uin%3D号码%26albumid%3D393029702%26photoid%3D”的地址，如果地址里面完全没有QQ的地址段，那么为了防止下载运行网页木马，可以将url后的字符输入到ASCII码随心换进行转换（如果是像以上地址的格式，可以将%后的十六进制字符逐个进行转换来获得完整地址），如果url指向可执行文件就不能点击了。
方法2：为了防止系统被种植网页木马，还可以安装杀毒软件和防火墙并需要开始实时文件和网络监控，这样即使下载了网页木马也会被清除。如果发现了可疑的Qzone地址要及时举报，让 成为过街老鼠，毫无藏身之处。
小结:Qzone的跨站漏洞被用来种植木马具有受众广的特点，Qzone的地址经过加密化装后，又有几个人会仔细地进行甄别呢？因此，利用人们偷窥人家隐私空间的好奇心来传播木马是很有效果的。
其实，要防范Qzone地址在你的电脑种植木马也不难，最简单的方法就是只点击QQ资料里的Qzone地址，不去其他网站点击就可以了。另外，需要使用具有防范IE漏洞的安全工具和杀毒软件来查杀这类木马的下载安装，如：瑞星卡卡。携带木马的Qzone地址一经发现要马上通知网友，决不姑息，不让其他人成为 的牺牲品。同时，每次Qzone提示升级我们也最好升级不用嫌麻烦而取消升级，以免被 利用其他未知的漏洞。
篇10：如何防范被搜索引擎攻击WEB安全
为了产生攻击效果，这些URL必须从搜索引擎给出的搜索结果中排名靠前的域名中取得，攻击者通常会通过搜索引擎查找一些专门伪造的搜索词，这些搜索词往往能够泄露特定漏洞的存在。
搜索引擎投毒这种攻击，能够利用搜索引擎来显示搜索结果，该结果包含着对交付恶意软件的网站的一个或多个引用。有多种方法可以执行搜索引擎投毒，其中包括控制流行网站、使用搜索引擎的“赞助”链接，其目的都是为了链接到恶意网站，进而注入恶意代码。
此外，攻击者通过操纵搜索引擎来返回搜索结果（该结果包含着对感染了跨站脚本的网站的引用），也可以实施搜索引擎投毒。受感染的网页将轻信的用户重新定向到恶意网站。在该用户点击这些链接时，其计算机就有可能感染恶意软件。这种伎俩很不一般，因为它并不要求攻击者控制或攻入任何服务器。
攻击原理与步骤
首先，攻击者搭建一台在收到请求后就交付恶意软件的服务器。可通过不同的方法来交付恶意软件，如通过一个能够利用浏览器漏洞的HTML页面或其它方法。
然后，攻击者获得一系列易于遭受跨站脚本攻击的URL。为了产生攻击效果，这些URL必须从搜索引擎给出的搜索结果中排名靠前的域名中取得。攻击者通常会通过搜索引擎查找一些专门伪造的搜索词，这些搜索词往往能够泄露特定漏洞的存在。
下一步，攻击者使用这些URL，根据有漏洞的URL创建大量的专门伪造的URL，其中包括目标关键词和一段能够与恶意软件交付服务器进行交互的脚本。
然后，攻击者获得一个支持简单用户内容生成的应用程序清单，如一些论坛程序。攻击者会用各种专门仿造的URL，使网页的内容泛滥，并有可能包含多个链接，并使其接受不同的应用程序。
此后，流行的搜索引擎在扫描整个Web，就会选取专门伪造的URL，并跟踪这些URL，进而对这些网页进行索引。其结果是，目标关键词与专门伪造的URL发生了关联。由于攻击者选取了高优先级的域名作为开始，而且由于对这些URL的大量引用，受到“投毒”的搜索结果的排名当然就靠前了。
最后，搜索这些关键词且容易轻信的用户单击这些URL中的一个链接，其计算机便容易被感染恶意软件，
总之，搜索引擎投毒易于实施，却难被搜索引擎检测到。这种伎俩的目标是诱导无辜的搜索者到达恶意网站或欺诈网站。例如，攻击者利用机器人程序生成大量的用户名，在论坛上彼此发布拥有许多链接的帖子进行讨论，显得不亦乐乎。对搜索引擎来说，这倒是一个好事儿，既然有这么多用户牵涉进来，因而搜索引擎便把这种网页放在显赫的位置。在某个用户单击了其中的某个链接后，就会打开一个链接到色情或购物网站的网页。在用户再次单击后，该链接就会将恶意软件安装到用户的计算机上，进而对用户实施欺诈或其它犯罪活动。
防范
攻击者以这种方式滥用网站可以导致企业的商誉和品牌受到破坏，丢失客户和潜在的访客。而且，这种攻击对网站的可访问性造成明显的负面影响，这会导致搜索引擎将URL引用标记为“有害”或“危险”，甚至被完全地从搜索索引中删除，从而使企业遭受严重的经济损失。
从管理层面来说，系统管理员可以使用一个具备“黑名单”功能的安全网关，截获被列入“黑名单”的网站上的所有通信，从而阻止一些不确定的或具有潜在威胁的URL分类，从而阻止搜索引擎投毒的危害。此外，保护好公司自己的网站（博客和用户论坛）也很重要，因为这样做就不会使其成为搜索引擎投毒的帮凶。保护Web应用程序免受XSS攻击可以防止这些网站被攻击者用作发动搜索引擎投毒的媒介。
从用户层面来说，防止搜索引擎投毒攻击要从提升搜索用户的认识水平开始。研究发现，虽然许多人已经理解在邮件中可能包含恶意软件，却并未认识到在上网搜索时，其搜索结果也有可能是不安全的。企业必须教育雇员不能访问色情、赌博等网站，在搜索信息时，要尽量使用知名网站上的URL。
仅有防火墙或反病毒软件对于防护动态变化的恶意软件及其灵活多变的交付方式是不够的。相反，企业需要实时的保护情报，基于云的Web防御可以快速地适应新的威胁，应当作为企业的首选方案。
★Linux下PhpMyAdmin程序目录的安全管理WEB安全
文档为doc格式
