openstar|基于OpenResty的高性能WAF

openstar|基于OpenResty的高性能WAF

个人隐私保护, 技能树

openstar概览

OpenStar是一个基于OpenResty的高性能WAF，还相应增加了其他灵活、友好、实用的功能，是增强的WAF。 app_Mod 支持规则组 连接符支持 or , 参考doc/demo.md文档.

WAF防护

在OpenStar中的WAF防护模块，采用传统的字符串的匹配如正则过滤、包含等（有人会问现在不是流行自主学习么；正则、包含等会有盲点、会被绕过；WAF的误报和漏报问题等等……）。规则不是万能的，但是没有规则是万万不能的 这里我简单说明一下，自主分析学习引擎是我们的日志分析引擎做的（预留了api可实时增加拦截），这里是高性能、高并发的点，就用简单快速的方法解决，且根据业务实际调整好防护策略，可以解决绝大多数WEB安全1.0和WEB安全2.0类型的漏洞（90%+的问题）。 WAF 防护从header,args,post,访问频率等，分层进行按顺序防护，详细在后面的功能会详细说明

  • WEB安全1.0 在1.0时代下，攻击是通过服务器漏洞（IIS6溢出等）、WEB应用漏洞（SQL注入、文件上传、命令执行、文件包含等）属于服务器类的攻击，该类型漏洞虽然经历了这么多年，很遗憾，此类漏洞还是存在，并且重复在犯相同的错误。
  • WEB安全2.0 随着社交网络的兴起，原来不被重视的XSS、CSRF等漏洞逐渐进入人们的视野，那么在2.0时代，漏洞利用的思想将更重要，发挥你的想象，可以有太多可能。
  • WEB安全3.0 同开发设计模式类似（界面、业务逻辑、数据），3.0将关注应用本身的业务逻辑和数据安全，如密码修改绕过、二级密码绕过、支付类漏洞、刷钱等类型的漏洞，故注重的是产品本身的业务安全、数据安全、风控安全等。安全不仅仅是在技术层面、还应该在行政管理层面、物理层面去做好安全的防护，才能提供最大限度的保护。 安全行业多年的从业经验：人，才是最大的威胁；无论是外部、内部、无心、有意过失。（没有丑女人、只有懒女人）我想可以套用在此处，纯属个人见解。

CC/采集防护

什么是CC攻击，简单的说一下，就是用较少的代价恶意请求web（应用）中的重资源消耗点（CPU/IO/数据库等等）从而达到拒绝服务的目的；数据采集，就是内容抓取了，简单这么理解吧

非官方学术类的解释，先将就理解下 关于本文对CC攻击的分析和相关的防护算法，都是我在实战中分析总结，并形成自己的方法论，不足之处、欢迎指正。

攻击类型

  • 行为（GET、POST等） 目前主要还是这两中method攻击为主，其他的少之又少。
  • 被攻击的点1：用户可直接访问的URL（搜索、重CPU计算、IO、数据库操作等）2：嵌入的URL（验证码、ajax接口等）3：面向非浏览器的接口（一些API、WEBservice等）4：基于特定web服务、语言等的特定攻击（慢速攻击、PHP-dos等）

面对CC攻击我们需要根据实际情况采用不同的防护算法，比如攻击的点是一个ajax点，你使用js跳转/验证码肯定就有问题

防护方法

  • 网络层 通过访问ip的频率、统计等使用阀值的方式进行频率和次数的限制，黑名单方式
  • 网络层+应用层 在后来的互联网网络下，有了的CDN加入，现在增加的网络层的防护需要扩展，那么统计的IP将是在HTTP头中的IP，仍然使用频率、次数、黑名单的方式操作。

但是很多厂家的硬件流量清洗等设备，有的获取用户真实IP从HTTP头中取的是固定字段（X-FOR-F），不能自定义，更甚至有的厂家就没有该功能，这里就不说具体的这些厂家名字了PS: 在传统的4层防护上，是没有问题的

  • 应用层 TAG验证、SET COOKIE、URL跳转、JS跳转、验证码、页面嵌套、强制静态缓存等 防护是需要根据攻击点进行分别防护的，如攻击的是嵌入的url，我们就不能使用JS跳转、302验证码等这样的方法；在多次的CC防护实战中，如使用url跳转、set cookie，在新型的CC攻击下，这些防护都已经失效了。后面我会分享一下我的防护算法，并且在OpenStar中已经可以根据情况实现我所说的防护算法。 浏览器是可以执行JS和flash的，这里我分享一些基于JS的防护算法，flash需要自己去写（比js复杂一些），可以实现flash应用层的安全防护和防页面抓取（开动你的大脑吧）

1：客户端防护 使用JS进行前端的防护（浏览器识别、鼠标轨迹判断、url有规则添加尾巴（args参数）、随机延迟、鼠标键盘事件获取等）其实这里非常复杂，如浏览器的识别 ie 支持 !-[1,] 这个特殊JS，一些JS方言，一些浏览器有自定义标签等等；

2：服务端防护 url添加的尾巴（args参数）是服务器动态生成的token，而不是使用静态的正则去匹配其合法性。

3：特定攻击 该类特定攻击，可以通过特征快速匹配出来（慢速攻击、PHP5.3的http头攻击）

简单场景

1：用户可直接访问的url（这种是最好防的）

第一阶段：

  • 网络层：访问频率限制，超出阀值仅黑名单一段时间
  • 应用层：js跳转、验证码、flash策略（拖动识别等）

2：嵌入的url（ajax校验点、图片验证码）

第一阶段：

  • 网络层：访问频率限制，超出阀值仅黑名单一段时间
  • 应用层：载入被攻击的url页面，重写页面，使用js方操作链接被攻击的url。js随机在url尾巴增加有一定规则的校验串，服务端对串进行静态正则校验。

第二阶段：

  • 网络层+应用层：用户ip在http头中，需要从http头取ip，在进行频率限制 （其实做好了，这一层的防护，基本不用进入第三阶段的应用层防护了）
  • 应用层：校验串使用服务端生成的token，进行严格服务器token验证检查

第三阶段：

  • 应用层：js增加浏览器识别（不同agent匹配不同JS方言代码）、JS随机延迟、鼠标轨迹验证、键盘鼠标事件验证等js增加验证后，在进行校验串生成。

说明：多次实战CC处理经验，很少到第三阶段，当然储备好这些JS脚本非常重要，纯JS肯定也是有限的，所有我就提出了使用控件，甚至是和浏览器厂商合作等更精准的防护方法。这样对CC攻击、页面抓取、刷单等有非常好的防护效果。

应用层的防护是在网络层+扩展的网络层防护效果不佳时使用，一般情况基本用的不多，因为在OpenStar的防护下，极少数情况下，需要第三阶段防护。在防页面抓取时，发挥你的想象（js是个好帮手，善用）使用OpenStar就可以帮你快速实现；当然使用flash防抓取效果更好（不够灵活）。

下载

wget

git clone

已经打包的一些脚本，请参考bash目录

安装

  • 安装OpenResty 这里不做过多重复描述，直接看链接OpenResty
  • 配置nginx.conf 在http节点，引用waf.conf。注：原ngx相关配置基本不用修改，该优化优化、该做CPU亲缘绑定继续、该动静分离还继续、该IO、TIME等优化继续不要停。
  • 配置waf.conf 修改lua_package_path，使用正确的路径即可；修改那些lua文件的路径，多检查几遍。
  • 设置目录权限 OpenStar目录建议放到OR下，方便操作，该目录ngx运行用户有读写执行权限即可。因为要写日志，暂时没有用ngx.log，后续可能会改动。
  • lua文件修改 在init.lua中，修改conf_json参数，base.json文件绝对路径根据自己的情况写正确。
  • api使用 2016年6月7日 23:31:09 更新啦，引用waf.conf，后就可以直接使用api接口了，通过监听5460端口来给管理用啦，界面也在筹划中，期待有人可以加入，帮我一起整界面。

已经打包的一些脚本，请参考bash目录，运行前请阅读一下，感谢好友余总帮助写的脚本

使用

配置规则

一般情况下匹配某一规则由3个参数组成，第二个参数标识第一个参数类型,第三个参数表示是否取反，默认为nil 即 false 表示不取反

hostname：["*",""] = ["*","",false]

==>表示匹配所有域名（使用字符串匹配，非正则，非常快）

hostname：["*\\.game\\.com","jio"]

==>表示使用正则匹配host（ngx.re.find($host,参数1，参数2)）

hostname：[["127.0.0.1","127.0.0.1:8080"],"list"]

==>表示匹配参数1 列表 中所有host

hostname：[{"127.0.0.1":true,"127.0.0.1:5460":true},"dict"]

==>表示匹配 字典 中host为true的host

uri：["/admin","in"]

==>表示匹配uri中包含/admin的所有uri都会被匹配（string.find($uri,参数1,1,true)）

ip：[["127.0.0.1/32",""113.45.199.0/24""],"cidr"]

==>表示匹配的ip在这两组ip段/ip中

args：["*","",["args_name","all"],false] args：["*","",["args_name","end"]] = ["*","",["args_name","end"],false] args：["*","",["args_name",1]]

说明：第3个参数表示取args参数table的key名称，第3个参数2表示取args[args_name]为table时，匹配任意(all)，匹配最后一个(end),匹配第几个(数字)，默认取第一个

==>表示匹配的GET的args参数名为args_name,使用第4个参数模式进行匹配，匹配规则就是第一个和二个参数。其中第1、2参数支持前面描述的规则方式。

table类型的匹配规则比较麻烦，暂时想着是这样处理，有好的想法可以告诉我

执行流程

openstar|基于OpenResty的高性能WAF
  • init阶段

a：首先加载本地的base.json配置文件，将相关配置读取到config_dict,host_dict,ip_dict中

  • access阶段（自上到下的执行流程，规则列表也是自上到下按循序执行的）

0：realIpFrom_Mod ==> 获取用户真实IP（从HTTP头获取，如设置）

1：ip_Mod ==> 请求ip的黑/白名单、log记录

2：host_method_Mod ==> host和method过滤（白名单）

3：rewrite_Mod ==> 跳转模块，set-cookie操作

4：host_Mod ==> 对应host执行的规则过滤（uri,referer,useragent等）

这里是产品中提供给独立用户使用的过滤规则。目前支持自定义规则组（任意参数，任意组合）

5：app_Mod ==> 用户自定义应用层过滤

6：referer_Mod ==> referer过滤（黑/白名单、log记录）

7：uri_Mod ==> uri过滤（黑/白名单、log记录）

8：header_Mod ==> header过滤（黑名单）

9：useragent_Mod ==> useragent过滤（黑/白名单、log记录）

10：cookie_Mod ==> cookie过滤（黑/白名单、log记录）

11：args_Mod ==> args参数过滤[实际是query_string]（黑/白名单、log记录）

12：post_Mod ==> post参数过滤[实际是整个post内容]（黑/白名单、log记录）

13：network_Mod ==> 应用层网络频率限制（频率黑名单）

  • body阶段

14：replace_Mod ==> 内容替换规则（动态进行内容替换，性能消耗较高慎用，可以的话用app_Mod中rehtml、refile这2个自定义action）

STEP 0 : realIpFrom_Mod

  • 说明： {"101.200.122.200:5460": {"ips": ["*",""],"realipset": "x-for-f"}}

通过上面的例子，表示域名id.game.com,从ips来的直连ip，用户真实ip在x-for-f中，ips是支持二阶匹配，可以参考例子进行设置，ips为*时，表示不区分直连ip了。

STEP 1：ip_Mod（黑/白名单、log记录）

  • 说明： {"ip":"111.206.199.61","action":"allow"} {"ip":"www.game.com-111.206.199.1","action":"deny"}

上面的例子，表示ip为111.206.199.61（从http头获取，如设置）白名单 action可以取值[allow、deny]，deny表示黑名单；第二个就表示对应host的ip黑/白名单，其他host不受影响。

返回

STEP 2：host_method_Mod（白名单）

  • 说明： {"state":"on","method":[["GET","POST"],"list"],"hostname":[["id.game.com","127.0.0.1"],"list"]}

上面的例子表示，规则开启，host为id.game.com、127.0.0.1允许的method是GET和POST state：表示规则是否开启 method：表示允许的method，参数2标识参数1是字符串、列表(list)、正则、字典(dict) hostname：表示匹配的host，规则同上

"method": [["GET","POST"],"list"]==> 表示匹配的method是GET和POST

"method": ["^(get|post)$","jio"] ==> 表示匹配method是正则匹配

"hostname": ["*",""] ==>表示匹配任意host（字符串匹配，非正则，非常快）

后面的很多规则都是使用该方式匹配的

返回

STEP 3: rewrite_Mod（跳转模块）

  • 说明：
    {
        "state": "on",
        "action": ["set-cookie"],
    "set_cookie":["asjldisdafpopliu8909jk34jk","token_name"],
        "hostname": ["101.200.122.200",""],
        "uri": ["^/rewrite$","jio"]
    }

上面的例子表示规则启用，host为101.200.122.200,且url匹配成功的进行302/307跳转，同时设置一个无状态cookie，名称是token。action中第二个参数是用户ip+和改参数进行md5计算的。请自行使用一个无意义字符串。防止攻击者猜测出生成算法。

返回

STEP 4：host_Mod

  • 说明： 该模块是匹配对应host进行规则匹配，在conf_json/host_json/目录下，本地的基于host的匹配规则 支持host.state状态支持[on log off],log即表示原匹配被拦截将失效，off表示不做任何规则的过滤

STEP 5：app_Mod（自定义action）

  • 说明：
{
   "state":"on",
   "action":["deny"],
   "hostname":["127.0.0.1",""],
   "uri":["^/([\w]{4}\.html|deny1\.do|你好\.html)$","jio"]
}

上面的例子表示规则启用，host为127.0.0.1，且url符合正则匹配的，拒绝访问

state：规则是否启用 action：执行动作

1：deny ==> 拒绝访问

2：allow ==> 允许访问

3：log ==> 仅记录日志

4：rehtml ==> 表示返回自定义字符串

5：refile ==> 表示返回自定义文件（文件内容返回）

6：relua ==> 表示返回lua执行脚本（使用dofile操作）

7：relua_str ==> 表示返回lua代码执行

hostname：匹配的host

uri：匹配的uri

hostname 和 uri 使用上面描述过的匹配规则，参数2标记、参数1内容

详细参见项目中的demo规则，多实验、多测试就知道效果了

各种高级功能基本就靠这个模块来实现了，需要你发挥想象

返回

STEP 6：referer_Mod（白名单）

  • 说明： {"state":"on","uri":["\\.(gif|jpg|png|jpeg|bmp|ico)$","jio"],"hostname":["127.0.0.1",""],"referer":["*",""],"action":"allow"}

上面的例子表示，host为127.0.0.1，uri配置的正则成功，referer正则匹配成功就放行**【这里把一些图片等静态资源可以放到这里，因为使用OpenStar，不需要将access_by_lua_file 专门放到nginx的不同的location动态节点去，这样后续的匹配规则就不对这些静态资源进行匹配了，减少总体的匹配次数，提高效率】**，action表示执行的动作，allow表示规则匹配成功后，跳出后续所有规则（一般对静态资源图片），referer匹配失败就拒绝访问（白名单），防盗链为主；规则的取反可以设置防护站外的CSRF

state：表示规则是否开启 uri：表示匹配的uri hostname：匹配host referer：匹配referer action：匹配动作

referer的匹配是白名单，注意一下即可 这些匹配都是基于上面说过的二阶匹配法

返回

STEP 7：uri_Mod（黑、白名单）

  • 说明： {"state":"on","hostname":["\*",""],"uri":["\\.(css|js|flv|swf|zip|txt)$","jio"],"action":"allow"}

上面的例子表示，规则启用，任意host，uri正则匹配成功后放行，不进行后续规则匹配（该场景同图片等静态资源一样进行放行，减少后续的匹配） state：表示规则是否开启 hostname：表示匹配的host uri：表示匹配uri action：可取值[allow、deny、log]，表示匹配成功后的执行动作

一般情况下，过滤完静态资源后，剩下的都是拒绝一下uri的访问如.svn等一些敏感目录或文件

返回

STEP 8：header_Mod（黑名单）

  • 说明： {"state":"on","uri":["\*",""],"hostname":["\*",""],"header":["Acunetix_Aspect","\*",""]}

上面的例子表示，规则启用，匹配任意host，任意uri，header中Acunetix_Aspect内容的匹配（本次匹配任意内容）这个匹配是一些扫描器过滤，该规则是wvs扫描器的特征 state：规则是否启用 uri：匹配uri hostname：匹配host header：匹配header头

返回

STEP 9：useragent_Mod （黑名单）

  • 说明： {"state":"off","action":"deny","useragent":["HTTrack|harvest|audit|dirbuster|pangolin|nmap|sqln|-scan|hydra|Parser|libwww|BBBike|sqlmap|w3af|owasp|Nikto|fimap|havij|PycURL|zmeu|BabyKrokodil|netsparker|httperf|bench","jio"],"hostname":[["127.0.0.1:8080","127.0.0.1"],"list"]}

上面的例子表示，规则关闭，匹配host为127.0.0.1 或者 127.0.0.1:8080 ，useragent正则匹配，匹配成功则拒绝访问，一般host设置为："hostname":["*",""]表示所有（字符串匹配，非常快） state：规则是否启用 hostname：匹配host useragent：匹配agent action：匹配动作

返回

STEP 10：cookie_Mod（黑名单）

  • 说明： {"state":"on","cookie":["\\.\\./","jio"],"hostname":["*",""],"action":"deny"}

上面的例子表示，规则启用，匹配任意host，cookies匹配正则，匹配成功则执行拒绝访问操作 state：表示规则是否启用 cookie：表示匹配cookie hostname：表示匹配host action：可选参数[deny、allow] 表示执行动作

action后续可以能增加其他action，所以预留在这，否则黑名单根本不需要action参数

返回

STEP 11：args_Mod（黑名单）

  • 说明： {"state":"on","hostname":["*",""],"args_data":["\\:\\$","jio"],"action":"deny"}

上面例子表示，规则启用，匹配任意host，query_string参数组匹配正则，成功则执行拒绝访问动作 state：表示规则是否启用 hostname：表示匹配host query_string：表示匹配args参数组 action：表示匹配成功拒绝访问

返回

STEP 12：post_Mod（黑名单）

  • 说明： {"state":"on","hostname":["*",""],"posts_data":["\\$\\{","jio"],"action":"deny"}

上面的例子表示，规则启用，匹配任意host,post_str参数组匹配正则，成功则拒绝访问 state：表示是否启用规则 hostname：匹配host post_str：匹配post参数组 action：匹配成功后拒绝访问

返回

STEP 13：network_Mod（频率黑名单）

  • 说明： {"state":"on","network":{"maxReqs":20,"pTime":10,"blackTime":600},"hostname":["id.game.com",""],"uri":["^/2.html$","jio"]}

上面的例子表示，规则启用，host为id.game.com,url匹配正则，匹配成功则进行访问频率限制，在10秒内访问次数超过20次，请求的IP到IP黑名单中10分钟（60秒*10） state：表示是否启用规则 hostname：表示匹配host uri：表示匹配uri network：maxReqs ==> 请求次数；pTime ==> 单位时间；blacktime ==> ip黑名单时长

一般情况下，cc攻击的点一个网站只有为数不多的地方是容易被攻击的点，所以设计时，考虑增加通过url细化匹配。

返回

STEP 14：replace_Mod（内容替换）

  • 说明： {"state":"on","uri":["^/$","jio"],"hostname":["passport.game.com",""],"replace_list":[["联合","","联合FUCK"],["登录","","登录POSS"],["lzcaptcha\\?key='\\s\*\\+ key","jio","lzcaptcha?keY='+key+'&keytoken=@token@'"]]}

上面的例子表示，规则启用，host为passport.game.com,url是正则匹配，匹配成功则进行返回内容替换 1：将”联合”替换为”联合FUCK”； 2：将”登录”替换为”登录POSS”； 3：通过正则进行匹配（ngx.re.gsub）其中@token@表示动态替换为服务器生成的一个唯一随机字符串 state：表示是否启用规则 hostname：表示匹配的host uri：表示匹配的uri replace_list：表示替换列表，参数1 ==> 被替换内容；参数2 ==> 匹配模式（正则、字符串）如例子中前2个替换列表就是字符串匹配，使用””即可，不能没有；参数3 ==> 被替换的内容

性能评测

操作系统信息 OpenStar测试服务器：

 微软虚机，内网测试

 uname -a :
 Linux dpicsvr01 4.2.0-30-generic #36-Ubuntu SMP Fri Feb 26 00:58:07 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

 内存：
 cat /proc/meminfo | grep MemTotal
 MemTotal:       14360276 kB// 14GB

 CPU型号：cat /proc/cpuinfo | grep 'model name' |uniq
 Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz

 CPU核数：cat /proc/cpuinfo | grep "cpu cores" | uniq
 4

 CPU个数：cat /proc/cpuinfo | grep "physical id" | uniq | wc -l
 1
 ab：
 ab -c 1000 -n 100000 "http://10.0.0.4/test/a?a=b&c=d"

测试结果：

通过图片可以看到，关闭所有规则，做了2组测试，取最高的8542；

启用规则（排除app，network，replace），测试结果8388，性能下降1.81%；

启用规则（排除replace，app中未启用relua这个高消耗点），测试结果7959，性能下降6.83%；

启用规则（排除useragent，ab工具默认被拦截了，第二个测试就不完全了。）测试结果7116，性能下降16%；

总的来说，启用规则后，性能损失可以接受，根据自身的业务进行调整，还可以有所优化。

项目地址

GitHub: github.com/starjun/openstar

openstar-Enterprise使用文档

安装方法:

WAF依赖 openresty/tengine、redis(集群使用)
注：推荐使用centos 7.x
目前是唯一对外地址： https://github.com/op-sec-team/releases-openstar-Enterprise
当前有2个分支，一个是openresty版本，一个分支是tengine版本

一键安装脚本

这里介绍使用安装脚本进行快速安装

安装 redis

一组集群就需要安装一台redis！！！
使用 root 运行

# 下载 安装脚本  rds.sh （该脚本支持 centos / ubuntu )
wget -N --no-check-certificate https://raw.githubusercontent.com/op-sec-team/releases-openstar-Enterprise/master/openstar/bash/rds.sh
# 增加脚本执行权限
chmod +x rds.sh
# 进行 unix 转换
dos2unix rds.sh 
# 脚本使用
./rds.sh install  # 安装 redis   我们执行这行，开始安装redis（当然你也可以使用yum/docker）
./rds.sh start    # 启动 redis
./rds.sh  stop    # 关闭 redis
./rds.sh          # 连接 配置的 redis

目前rds.sh脚本配置安装的 redis 版本为：5.0.3；可以自行修改脚本，根据自己的需求。
在启动之前，请配置好redis的相关配置（监听ip、端口、密码、存放路径、日志路径等）

vim /opt/redis/redis-5.0.3/redis.conf  # 【注意路径是否正确】
port 6379                    # 【配置 监听的 端口】
bind 192.168.25.34    # 【配置redis监听的 ip （集群模式下，使用大家都可以访问的ip，非 127.0.0.1）】
dir /opt/redis/              # 【 配置存放 db文件的路径】
requirepass  nihaoredis123    #【配置自己的密码！！！】
logfile /opt/redis/redis.log    #【配置 redis 日志文件路径】
当然也可以使用脚本配置（提前修改rds里面的ip、port、密码等信息）  执行： ./rds.sh cfg

配置好redis后，就可以启动redis了 ./rds.sh start
还可以修改rds.sh文件中连接redis的IP，端口，密码，然后连接到redis，查看数据。

vim rds.sh
ip=127.0.0.1  #【配置需要连接redis 的 ip】
psd=nihaoredis123  #【配置连接的 密码】
port=6379  #【配置连接redis 的端口】
openstar & openresty(tengine) 安装

使用 root 运行

# 下载安装脚本 openstar.sh  该脚本支持 centos / ubuntu ...
openresty版本 下载：
wget -N --no-check-certificate https://raw.githubusercontent.com/op-sec-team/releases-openstar-Enterprise/master/openstar/bash/openstar.sh
tengine版本 下载：
wget -N --no-check-certificate https://raw.githubusercontent.com/op-sec-team/releases-openstar-Enterprise/master/openstar/bash/tengine.sh
# 增加脚本执行权限
chmod +x openstar.sh
chmod +x tengine.sh
tengine.sh
# 进行 unix 转换
dos2unix openstar.sh
dos2unix tengine.sh
# 运行脚本
./openstar.sh(tengine.sh)

根据脚本提示进行选择吧~
openresty版本

openstar|基于OpenResty的高性能WAF

tengine版本

openstar|基于OpenResty的高性能WAF

步骤如下：
1 — 安装 openresty/tengine
3 — 安装 openstar
7 — 安装 luarocks （tengine必须安装）
8 — openstar 运行环境检查（重要一定要运行）
其他的选项更具自己的情况选择使用吧
tengine版本 注意！！！：
cjson.so 有时候脚本没有安装成功，需要您自己安装一下
/opt/tengine/luarocks/bin/luarocks install lua-cjson，
再到目录/opt/tengine/luarocks/lib/lua/5.1 看看有没有cjson.so 这个文件

完成上面的操作，我们的openstar 、openresty/tengine、redis 就完全安装完成了。
就可以启动我们的 WAF 了 /opt/openresty(tengine)/nginx/sbin/nginx
环境变量已经添加（没有使用在 /usr/bin 创建软连接的方式，而是修改 /etc/profile 添加的环境变量）
但是本连接的shell还不能直接执行 nginx 命令，我们需要重新开启一个 shell

所有脚本都在 openstar/bash/ 目录下
当wget脚本失败时，可以使用git clone该项目，在使用其中的脚本

git clone --depth=1 https://github.com/op-sec-team/releases-openstar-Enterprise
# 脚本位置
/openstar/bash/*

其他说明

1.openstar 目录固定 /opt/openresty/openstar 或者 /opt/tengine/openstar目录固定放到这里，不要进行修改
2. 新开启一个shell后，使用命令 nginx -t 测试成功，查看是否测试成功
3. 查看是否安装成功

执行 nginx 命令
1：访问WAF 地址 eg: `http://192.168.76.6/.git/ ` 查看是否被拦截
2：`netstat -ant` 查看是否监听 5460 端口
3：`curl -v http://192.168.76.6/.git/` 查看一下 详细的信息
    查看 header 头是否为 `server: openstar system`
  1. bash目录下有一些 service 文件，在 centos7 下用于配置开机启动服务的，具体可以参考一些文档
    也可以直接放到启动脚本中 /etc/rc.d/rc.local 设置文件可执行
vim /etc/rc.d/rc.local
# 文件最后追加下面的内容
# 集群 master 增加 redis 启动项（安装了redis的服务器添加）
sudo sh opt/openresty(tengine)/openstar/bash/rds.sh start
# 增加 nginx 启动项
/opt/openresty(tengine)/nginx/sbin/nginx
# 配置rc.local执行权限
chmod +x /etc/rc.d/rc.local

授权注册

首次启动需要修改根目录下 regsn.json 中的code / sn / state 值为空即可（默认为空，最好检查一下），查看 sn_error.log 日志，[check_sn] 认证通过 （没有数据，可以 nginx -s reload 一下）
表示网络验证成功，如有其它问题，请QQ联系处理
注册失败，WAF将工作在bypass模式！！！
需要保证该 Master 服务器可以联网，否则网络认证将失败~

常见问题

1：openresty-1.15.8.1 版本出现 cannot load incompatible bytecode 问题
注：1.13.6.2 之后的版本都需要增加编译参数 --without-luajit-gc64
解决：修改编译参数

./configure --prefix=/opt/openresty --with-http_realip_module --with-http_v2_module --without-luajit-gc64

2：时区问题
需要配置WAF服务器时区为上海时区（北京）

ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

手动安装

当安装脚本使用存在问题后，我们如何进行手动安装，请参考该文档

redis 安装
  • centos / ubuntu
mkdir -p /opt/redis && cd /opt/redis
wget http://download.redis.io/releases/redis-5.0.3.tar.gz
tar -xvzf redis-5.0.3.tar.gz
cd redis-5.0.3
make
# 编辑 redis 配置文件  /opt/redis/redis-5.0.3/redis.conf
vim /opt/redis/redis-5.0.3/redis.conf
# 配置监听 端口 和 绑定 ip 
bind 127.0.0.1 # 根据自己情况配置，集群使用，不能用 127.0.0.1
port 6379  # 一般使用默认的即可
dir /opt/redis/   # 配置 redis db 存放路径
requirepass yourpw # 配置 redis 的密码
logfile /opt/redis/redis.log # 配置 redis 日志文件路径
# redis 配置文件配置完成之后
# openstar/bash/rds.sh 脚本 配置在配置 redis 的信息
# 后面可以使用脚本 启动 关闭  连接 redis 进行操作
openresty 安装

tengine 参考脚本中的命令

  • centos
yum install -y wget make gcc readline-devel perl pcre-devel openssl-devel git unzip zip htop goaccess dos2unix
wget https://openresty.org/download/openresty-1.13.6.2.tar.gz
tar -xvzf openresty-1.13.6.2.tar.gz
cd openresty-1.13.6.2
./configure --prefix=/opt/openresty --with-http_realip_module --with-http_v2_module
# 如果使用的是 openresty-1.15.8.1 就需要使用下面的编译语句
./configure --prefix=/opt/openresty --with-http_realip_module --with-http_v2_module --without-luajit-gc64
make && make install
  • ubuntu
apt-get install libpcre3-dev libssl-dev perl make build-essential curl git unzip zip htop goaccess dos2unix
tar -xvzf openresty-1.13.6.2.tar.gz
cd openresty-1.13.6.2
./configure --prefix=/opt/openresty --with-http_realip_module --with-http_v2_module
# 如果使用的是 openresty-1.15.8.1 就需要使用下面的编译语句
./configure --prefix=/opt/openresty --with-http_realip_module --with-http_v2_module --without-luajit-gc64
make && make install

安装版本必须使用 1.11.0 之后的，建议使用 1.13.6.2

openstar-Enterprise 安装

openresty 和 redis 都安装完成后
手动安装：

git clone https://github.com/op-sec-team/releases-openstar-Enterprise
cp -Rf releases-openstar-Enterprise/openstar /opt/openresty/
dos2unix /opt/openresty/openstar/bash/*.sh
cp -Rf ./releases-openstar-Enterprise/view-private /opt/openresty/nginx/html/
ln -sf /opt/openresty/openstar/conf/nginx.conf /opt/openresty/nginx/conf/nginx.conf
ln -sf /opt/openresty/openstar/conf/waf.conf /opt/openresty/nginx/conf/waf.conf
mkdir -p /opt/openresty/nginx/conf/conf.d
chown nobody:nobody -R /opt/openresty/
chown root:nobody /opt/openresty/nginx/sbin/nginx
chmod 751 /opt/openresty/nginx/sbin/nginx
chmod u+s /opt/openresty/nginx/sbin/nginx
cat /etc/profile |grep "openresty" ||(echo "PATH=/opt/openresty/nginx/sbin:\$PATH" >> /etc/profile && source /etc/profile)

#重开一个shell
nginx -t # 测试
nginx

登录后台

默认是无法登录后台
后台地址：http://192.168.3.33:5460/ (将ip改成自己的ip)，web管理后台是WAF管理图形化管理界面，需要大家熟练使用！！！

配置登录密码

http://192.168.3.33:5460/api/test/hash_t?str=xxxx
xxxx 你需要设置的密码
该接口会返回一个加密的密码
复制该加密后的密码 配置到 conf_json/admin_Mod.json 的 password 的内容中，重启 nginx

默认用户名：openstar
注：集群模式下，每一台机器的密码都需要这样设置，加密后的密码不同机器之间是不通用的！！！

界面介绍

  • 登录界面
openstar|基于OpenResty的高性能WAF
  • 后台主界面
openstar|基于OpenResty的高性能WAF

top页功能简介

  • 载入规则：从conf_json目录中重新载入规则到该服务器内存中（功能不常用）
  • 重启服务：重启当前服务器的 nginx 服务
  • 集群重启服务：重启整个集群的服务器的 nginx 服务（集群模式下重启 ngx 服务使用）
  • dashboard
  • 扩展配置
    • 插件管理：该功能是管理插件
    • 证书管理：这里是统一对证书进行管理，方便后面添加域名时引用
    • 配置文件管理：这里是对WAF使用的nginx配置文件的编辑操作，以及生成vhost配置文件的demo文件
  • 域名管理：这里是进行防护域名添加、编辑操作
  • 基础管理：包括WAF基本配置和高级配置
  • CDN规则
    • 添加header头配置：这里是在返回头中添加一些业务上需要的header数据
    • 限速limit配置：这里是配置下载限速的
    • 缓存proxy_cache配置：这里是配置反向代理，url缓存操作的
    • 清除缓存：这里是清除多个域名多个url缓存的
  • 网站规则：针对域名生效的访问控制规则配置
  • 全局规则：WAF全局规则配置管理入口，包括了 CDN相关功能 普通规则、高级规则、内容替换规则、配置获取用户真实IP（建议使用realip模块）、IP规则、域名方法规则、跳转配置、CC防护、拒绝信息配置
  • 授权认证配置：这里是网络认证相关配置

基本配置

简介

基本配置是WAF工作的基本配置，比如目录设置，redis设置等
配置完成后台密码后就需要进行WAF的基本配置和高级配置

入口

openstar|基于OpenResty的高性能WAF

基础配置

openstar|基于OpenResty的高性能WAF

先看一下基础配置都有哪些：

这里的配置就是配置 conf_json/bash.json

  • baseDir：不能修改，WAF的安装目录（固定目录）
  • logPath：调试日志存放路径（注：需要nobody有写的权限），在高级规则中动作为debug（由log动作变更而来）时，会将请求的原始数据记录到debug.log中，路径就是这个配置的地方
  • jsonPath：该目录是WAF所有规则存放的json文件的根路径（注：需要nobody有写的权限），右上角保存全部按钮会将WAF内存中的所有规则都分别保存到本机的磁盘上，那么路径就是这里
  • htmlPath：该目录是高级规则中动作为refile时，配置文件名所查找的路径，比如配置了2.txt，那么对于文件路径就是这里配置的/opt/openresty(tengine)/openstar/index/2.txt
  • denyMsg：是否开启自定义拦截页面的（不同的域名可以显示不同的拦截信息页面）开关，关闭的话只会显示这里配置的默认拦截页面信息；建议开启
    • 状态码：WAF执行拦截时默认拦截页面的 http 状态码，默认是：403,（建议使用403）
    • 内容框：默认拦截页面的内容，可以写html代码，可以引用图片（图片服务器不能经过WAF，图片有可能不会被显示）

修改完成后，点击应用后，会立刻生效（Slave会在 10s[可配置] 后同步该规则）

保存

保存该模块规则到服务器json配置文件（防止重启后配置丢失）
注：Slave 会自动保存配置到json文件!!!

高级配置

简介

高级配置是WAF的一些高级参数的配置，如集群配置，集群接口鉴权配置等; 其入口和基本配置一样

入口

openstar|基于OpenResty的高性能WAF

高级配置

先看一下 高级配置 的界面

openstar|基于OpenResty的高性能WAF
  • WAF 防护总开关
    这个是WAF是否开启拦截的总开关（优先级最高），这里控制WAF全局的工作模式，开启 = 拦截模式，关闭 = bypass模式，日志 = log模式，当这里设置WAF为bypass模式，后面所有的规则将不会生效。
  • 请求统计开关
    这个是是否开启一些域名计数统计的，开启即可；WAF页面中的业务报表数据就是这里控制的。
  • 集群配置
    在线上一般是需要一个集群来支撑业务，所以就需要配置集群相关的参数。
openstar|基于OpenResty的高性能WAF
  • 集群配置：顾名思义，主就选择 Master ，从就选择 Slave
    集群同步周期：主、从服务器之间同步规则的时间周期，单位秒
    Master IP：主 服务器的 ip 地址，一般情况下都是内网ip，注意不能写错了，否则后面的鉴权可能会有问题
ifconfig 查看一下 Master 服务器的 ip ，填写上去，如果有多个，就写和Slave需要通讯的 ip

Slave IPs：从 服务器 ip 列表，参考一下写法：

{} --- 没有 从 服务器
{"172.16.3.62","172.16.3.63"} --- 多个 从 服务器
  • Redis 配置
    集群配置中，规则的同步基本都是通过redis实现的（部分除外[nginx_Mod,ip_Mod，plugin_Mod …]），redis同样也存放的WAF的一些统计信息，所以需要集群模式下一定要开启该模块
openstar|基于OpenResty的高性能WAF
  • Redis配置：开关模块，默认开启即可
    IP：redis的ip地址
    Port：redis使用的端口
    密码：redis密码，线上一定要配置密码！！！ 不要使用默认配置的密码！！！
  • 本地日志设置
    这里使用默认的即可。【连接符要求是 \t】
  • API鉴权设置
    Master 服务器向 Slave 服务器更新指令时的权限验证，以及后台访问是否需要开启权限都是在这里控制，线上一定要开启！！！
openstar|基于OpenResty的高性能WAF
  • API鉴权：这个是控制后台访问是否开启权限验证的，线上一定要开启，否则你的后台谁都可以访问
    检查Master IP：集群模式下，Slave是否对Master的ip进行检查，这里和集群配置中设置的Master IP是关联的
    检查算法：目前支持MD5碰撞，HS256/HS512 的hmac签名检查
    密钥：算法中使用的关键隐私 key，线上一定要自己设置一个复杂的，不使用默认配置
    格式化配置：用于算法计算时，原始字符串的拼接，可以使用动态的参数

保存

保存该模块规则到服务器json配置文件（防止重启后配置丢失）
注：Slave 会自动保存配置到json文件!!!

问题

1：Master 规则编辑后，需要手动点击 应用 和 保存 按钮，Slave 是自动拉去Master的规则，且是自动保存

更多详细内容自行查看网站介绍:

https://www.kancloud.cn/openstar/install/1232492

Leave a Reply

您的电子邮箱地址不会被公开。 必填项已用 * 标注