waf

X-WAF 是一款方便易用的云WAF，使用反向代理的方式介入Web服务器和访问者之间，不需要像 modSecurity 和 Naxsin 那样作为nginx的模块，需要进行编译安装 X-WAF使用 OpenResty 作为反向代理软件，并借助 OpenResty 的 Lua 作为防御脚本的编写和运作工具 所以，实际上X-WAF就是一个运行在 OpenResty 上的 Lua 脚本，并借助了 OpenResty（nginx） 的多平台适用性，可以在各种操作系统运行 部署X-WAF的过程时间是就是安装 OpenResty，加载Lua脚本，然后建立虚拟主机，并把虚拟主机的访问直接发送给原本的php、tomcat或者nginx的过程 如果是已经有基于nginx+php构建的站点，就需要把网站配置到 OpenResty 上（80或443端口），把原来的nginx里的虚拟主机的端口改为其他端口比如8080，为防止用户通过原有IP或域名+8080端口访问，甚至原有nginx主机配置里面IP都可以直接修改为127.0.0.1。而OpenResty的虚拟主机配置上就通过proxy_pass把访问发送到127.0.0.1:8080的原有nginx上 项目地址： https://waf.xsec.io/ github： https://github.com/xsec-lab/x-waf 管理后台

您可使用 AWS WAF 控制 API 网关 、Amazon CloudFront 或 应用程序负载均衡器 如何响应 Web 请求。您首先需创建条件、规则和 Web 访问控制列表 ( Web ACL )。您需要定义条件、将条件合并为规则并将规则合并为 Web ACL。 条件 条件定义您希望 AWS WAF 在 Web 请求中监视的基本特征： 可能是 恶意的脚本 。攻击者会嵌入可以利用 Web 应用程序漏洞的脚本。这称为 跨站点脚本 。 请求源自的 IP 地址或地址范围 。 请求源自的 国家/地区或地理位置。 请求的指定部分的长度 (如查询字符串)。 可能是 恶意的 SQL 代码。 攻击者会尝试通过在 Web 请求中嵌入恶意 SQL 代码从数据库提取数据。这称为 SQL 注入 。 请求中出现的字符串，例如，在 User-Agent 标头中出现的值或是在查询字符串中出现的文本字符串。您还可以使用正则表达式 (regex) 指定这些字符串。 某些条件采用多个值。例如，您可以在 IP 条件中指定最多 10,000 个 IP 地址或 IP 地址范围。 来源： https://www.cnblogs.com/cloudrivers/p/11331436.html

用途： 防止sql注入，本地包含，部分溢出，fuzzing测试，xss,×××F等web*** 防止svn/备份之类文件泄漏 防止ApacheBench之类压力测试工具的*** 屏蔽常见的扫描***工具，扫描器 屏蔽异常的网络请求 屏蔽图片附件类目录php执行权限 防止webshell上传 1.下载并解压luajit 2.0.5 wget http://luajit.org/download/LuaJIT-2.0.5.tar.gz tar -zxvf LuaJIT-2.0.5.tar.gz cd LuaJIT-2.0.5 make install PREFIX=/data/luajit（选自己的目录） 2.软连接 ln -s /usr/local/luajit/lib/libluajit-5.1.so.2 /lib64/libluajit-5.1.so.2 3.下载并解压ngx_devel_kit wget https://github.com/simpl/ngx_devel_kit/archive/v0.3.0.tar.gz tar -zxvf v0.3.0.tar.gz 4.下载并解压lua-nginx-module wget https://github.com/openresty/lua-nginx-module/archive/v0.10.14rc3.tar.gz tar

1、WAF攻击 如何绕过WAF的防御策略： 攻击方 进行SQL注入 尝试绕过WAF检测， 攻击结果： 攻击方通过构造超长数据包，成功绕过WAF规格检测，并SQL注入获取数据库名，防守无法检测 ，对应的策略是升级WAF规格，调整策略 来源： https://www.cnblogs.com/xinxianquan/p/11326017.html

举例：下面这个WAF，/*%!/*/可以绕过空格 来源： https://www.cnblogs.com/blogs-1024/p/11324735.html

什么是WAF Web应用防护系统（也称为：网站应用级入侵防御系统。英文：Web Application Firewall，简称： WAF）。利用国际上公认的一种说法：Web应用防火墙是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护的一款产品。 实现WAF 两种方式 使用nginx+lua来实现WAF,须在编译nginx的时候配置上lua 部署OpenResty,不需要在编译nginx的时候指定lua 功能列表 支持IP白名单和黑名单功能，直接将黑名单的IP访问拒绝。 支持URL白名单，将不需要过滤的URL进行定义。 支持User-Agent的过滤，匹配自定义规则中的条目，然后进行处理（返回403）。 支持CC攻击防护，单个URL指定时间的访问次数，超过设定值，直接返回403。 支持Cookie过滤，匹配自定义规则中的条目，然后进行处理（返回403）。 支持URL过滤，匹配自定义规则中的条目，如果用户请求的URL包含这些，返回403。 支持URL参数过滤，原理同上。 支持日志记录，将所有拒绝的操作，记录到日志中去。 日志记录为JSON格式，便于日志分析，例如使用ELKStack进行攻击日志收集、存储、搜索和展示 具体操作 采用第二种方式实现WAF较为方便 以下操作的前提是：Centos 7.2 系统 部署OpenResty # 安装依赖包 yum

企业在安全方面最关注的其实是 业务安全 、 数据安全 与 安全检查 ，这篇文章来讲解一下我对于等保过检的经验与建设。 不同于其他建设文章，本文会给出很多落实方面的建议与方法，希望企业可以通过这篇文章，顺利通过过检任务，并保证安全的投入 成本 与 收益 的比率。 一、管理 一个企业的安全性最终体现在管理与运营，随着安全越发受重视，企业在安全管理方面也要与时俱进。 1 拓扑图 很多人把拓扑图分类到技术中，但我更愿意把拓扑图分类到管理中，因为可以通过拓扑图一目了然的知道企业中每个设备的使用，每个区域的划分都很明确，过检中过检人员第一个核对的也是拓扑图，那么拓扑图方面有什么需要注意的地方呢？ 1） 标名设备品牌与型号 标名设备品牌与型号的目的是更加直观明确的看出整个体系的硬件安全情况，也方便管理，当出现厂商漏洞时可以快速进行批量补救工作，避免遗漏。还有目前个人企业没有要求国产化率，国企与事业单位已经做了相关要求，个人企业在敏感行业也要去国产化改造，比如支付过检。国产化是大趋势，这里建议后期企业建设时优先考虑国产设备，已经使用国际品牌设备的企业，建议尽早进行国产化设备改造任务与国密改 2） 标名使用区域 这里的使用区域是指物理区域，比如办公区域、业务1云区域、业务2云区域、业务3机房区域。 3） 标名业务 需要标名过检的核心业务所在位置，访问核心业务的线路，核心业务基本信息（包括服务器信息

前言： 之前想着每天都更新一篇文章，但是连续几天之后，发现有好多博客大佬，所以觉得还是不要献丑好一点，然后就学习一下关于安全防护的知识，毕竟安全意识强弱代表在互联网防护能力，类似ddos，xss,csrf等也是经常出现，比如一些基本的×××方式：SQL注入，web参数，cc。所以我就记录了下面全程的将WAF嵌入LNMP架构，应用于实战集群架构。附带lua语言写的防护模块。 实战： 服务器架构图如下： 一、web服务器集群高可用负载均衡 1.高可用使用：nginx+keepalived模式 master（web1） 192.168.0.230 slaver（web2） 192.168.0.211 VIP：192.168.0.100 2.两边安装keepalived [root@web1 ~]# yum install -y keepalived 3.创建服务器监控脚本 [root@web1 ~]# mkdir -p /server/work [root@web1 ~]# cd /server/work/ [root@web1 work]# vim check_ng.sh #!/bin/bash #write by leo d=`date --date today +%Y%m%d_%H:%M:%S` n=`ps -C nginx --no-heading|wc -l` #如果进程为0

前言 在分享这个事件前，笔者先和大家一起来了解一下CC***： 【 CC***】   者借助代理服务器生成指向受害主机的合法请求，实现DDOS和伪装就叫：CC(ChallengeCollapsar)。 CC主要是用来 页面的。CC 的原理就是 者控制某些主机不停地发大量数据包给对方服务器造成服务器资源耗尽，一直到宕机崩溃。CC主要是用来***页面的，每个人都有这样的体验：当一个网页访问的人数特别多的时候，打开网页就慢了，CC就是模拟多个用户（多少线程就是多少用户）不停地进行访问那些需要大量数据操作（就是需要大量CPU时间）的页面，造成服务器资源的浪费，CPU长时间处于100%，永远都有处理不完的连接直至就网络拥塞，正常的访问被中止。  CC 是DDOS（分布式拒绝服务）的一种，相比其它的DDOS CC似乎更有技术含量一些。这种***你见不到真实源IP，见不到特别大的异常流量，但造成服务器无法进行正常连接。 引用百度百科https://baike.baidu.com/item/cc%E6%94%BB%E5%87%BB/10959545?fr=aladdin 酸爽的时刻  某天下午，正要到下班点的时候，笔者的手机突然振动一下，打开一看，是一条阿里云发的短信。点进去一看，是公司某个项目中的服务器CPU报警的短信，报警内容震惊了!!!!!!  服务器CPU爆了，紧接着又来收到好几条短信

回顾历史  相信有些朋友看过笔者之前写的这篇文章 《如何为企业快速设计高可用的阿里云架构》 ，并对阿里云的一些服务和产品的选型有了初步的了解，其实这篇文章写得比较粗，只是对企业选型描述大概的框架，并没有用太多笔墨来描述具体实现过程、配置操作。而导致有些博友看了也不过瘾。  所以，笔者这就要和大家一起来讨论一下《 阿里云高可用架构之“CDN+WAF+SLB+ECS”》如何实现，以及具体配置过程是怎样的。为什么拿这个架构来讨论呢，主要是这个架构目前在企业中使用率比较通用、普遍，也比较有代表性。  如果在企业中要具体来配置和实现，如果没有操过的朋友可能会有点晕、还会有点胆怯，具体该如何实现呢？不用担心。下面我们一起把它玩起来。 架构图 架构层级关系 CND（入口层）-> WAF（应用层防护）-> SLB（负载层）-> ECS（服务器源站） -> RDS（数据库）  域名 cname CDN  CDN指向WAF  WAF指向SLB  SLB负载ECS   说明：在企业中当然还会有其他的服务，比较redis、oss、nfs、监控、弹性ip、日志等等服务，这些都不是本文的重点，本文的重点主要介绍CDN>WAF>SLB>ECS这几层服务的关系该如何配置，从哪一层开始配置是最为适合。 规划配置思路 无非是两种思路：从外到内、从内到外。 从外到内： 什么是从外到内呢？刚才也分析了，即从CDN开始配置