【玩转EdgeOne】安全防护篇

互联网现状

随着互联网的飞速发展，当今网络安全问题日趋严重。比如DDoS攻击造成服务器宕机、WAF渗透引发的数据泄露以及黑产中应用猖獗的爬虫。而想针对这些网络攻击进行防护，其投入资金成本，人员成本都是巨大的，同时新的的0day漏洞也在不断出现。

edgeone作为加速+安全二合一的新产品，本次就产品交互、防护能力部分做了些体验。

产品交互

EdgeOne左侧的导航把DDOS，CC，WAF，BOT攻击分成了DDOS防护、web防护和bot管理三个页面进行单独配置，没有揉在一起，配置起来还是很清晰的。

域名首次接入EdgeOne，会自动绑定到web防护和Bot管理的“站点全局策略”下，自动行用上全局策略。

全局站点策略比较类似于配置模板，相当于对它进行配置以后，所有挂在这个策略下的域名，能直接复用配置的规则。当域名较多的时候，这个功能很实用，否则如果每个域名都要配置同一份防护规则，但只能一个一个单独去创建，这个工作量不敢想，更炸裂的是，好不容易都配完碰到需要变更的情况。

域名的差异化配置也支持，选择指定域名解绑全局策略，就能对单个域名做配置。批量配置和精细化配置都能兼顾。

防护能力

DDOS防护能力本次就不体验了，流量太贵了。

CC防护

EdgeOne把CC防护拆成了三块，严格来说这里的自定义规则和速率限制规则属于请求频率控制，也是CC的范畴。

高频访问请求限制

这个是下拉配置，默认给了四个等级，除了关闭规则以外，频率控制从40次/10秒 ~ 2000次/5秒，咦？这个能力来抗域名级的ddos直接就够用了。

使用jemter对域名做一次请求并发，更新防护等级为紧急，然后用jemter在8秒内发起45次请求（排除网络问题引起请求失败的干扰）。

从实际请求情况来看，有5次请求被拦截下来，可能跟网络响应顺序有关，这五次拦截并非在最后5次请求中，不过在功能上防护效果满足预期。

其实从这里可以看出，如果域名采用了CDN加速，在别人无法拿到服务器源IP地址的情况下，CC频率防护足以解决绝大部分DDOS的攻击危机。为什么只能说是绝大部分，其实还有一种slowpost攻击方式，即通过修改请求头部篡改征求正文长度，而实际每次发送少量数据和增加发送等待的方式保持长时间的连接不断开来消耗服务器的连接资源，使通过少量的请求来达到服务器访问连接拒绝。

edgeOne也提供了针对slowpost的防护--慢速攻击防护，不过需要开启高版本套餐，这里测试不了。

自定义规则&&速率限制规则

基础访问管控、精准匹配策略和速率限制规则都是基于请求头部，域名，路径，协议或请求参数相关的精细化的防护规则，需要用户自定义规则。

edgeone对请求是否使用的代理，是根据X-Forwarded-For头部和头部值来判断的，这里先简单介绍一下XFF这个头部原理。

网联网上，所有的网络通信都有记录，会记录请求的原始IP地址、端口、协议、跳转源路径、目标地址、代理ip等等信息，当一个请求从原始IP出发，经过多次代理服务跳转最终达到目标地址时，通常会被记录在X-Forwarded-For这个头部中。当然XFF这个头部并不是RFC标准协议头部，因此也会出现在其他的非标头部下，这里不展开。尽管XFF不是一个标准头部，但是普遍用的还是它

X-Forwarded-For头格式：

X-Forwarded-For: client, proxy1, proxy2 ······ 

X-Forwarded-For头部记录客户端IP地址的时机是在请求经过代理服务器时，代理服务器会将客户端的IP地址添加到X-Forwarded-For头部中。

XFF伪造

X-Forwarded-For头部记录的IP地址是在请求经过代理服务器时记录的，而不是在服务器的出口记录的。因此，当客户端直接伪造X-Forwarded-For头部值时，请求会被服务器认为是来自代理服务器的请求，而X-Forwarded-For头部通常是由代理服务器添加，因此，服务器会将客户端的IP地址添加到X-Forwarded-For头部的第二个位置，而不是第一个位置，以标识客户端的真实IP地址。

如上图：仍然假设client ip为10.0.0.1，client在请求server时，伪造XFF

# SHELL
CURL 43.153.12.9/server/getheaders -H "X-Forwarded-For: 127.0.0.1"

# PYTHON
import requests
headers = {"X-Forwarded-For": " 127.0.0.1"}
requests.get("http://43.153.12.9/server/getheaders" headers=headers)

在请求时，Client接收到了XFF头部X-Forwarded-For: 127.0.0.1，认为本次请求在到达Client之前已经经过了代理，因此请求在client出口前，会在XFF头部中拼接自己的ip，于是值就变成了X-Forwarded-For: 127.0.0.1, 10.0.0.1

X-Real-Ip协议

当客户端直接请求服务器时，客户端的IP地址会直接作为源IP地址发送给服务器，因此服务器可以直接获取到客户端的IP地址，不需要使用X-Real-IP头来标识客户端的真实IP地址。

而当客户端通过代理服务器发送请求时，代理服务器会将客户端的IP地址替换为自己的IP地址，并将客户端的IP地址保存在X-Forwarded-For头中。当请求到达服务器时，服务器只能获取到代理服务器的IP地址，无法获取到客户端的真实IP地址。为了解决这个问题，代理服务器会在请求头中添加X-Real-IP头，用于标识客户端的真实IP地址。因此，X-Real-IP头通常只在经过代理服务器的情况下出现，而在客户端直接请求服务器时不会出现。

当然，同XFF头部一样，x-real-ip也可以被篡改。

CURL 43.153.12.9/server/getheaders -H "X-Forwarded-For: 127.0.0.1" -H "X-Real-IP: 1.2.3.4"

以速率限制规则为例，配置一份关于使用代理服务请求服务的访问策略。这条配置指匹配X-Forwarded-For头部的第一个值，如果是10.0.0.1或10.0.0.2，且在10秒内请求超过1次，则执行拦截。模拟的客户端通过代理服务访问服务器，以隐藏客户端真实IP地址的目的。

首先在服务器上搭建一个服务，用来返回服务器获取到请求的原始请求头部信息。

代码片段：

# coding:utf-8
import logging
import datetime
from flask import request


class Server(object):
    def __init__(self, request_obj:request, func_name):
        """
        :param request_obj: requests对象，定义的时候要加注解，不然编译的时候类型不能被指定
        :param func_name: 路由path
        """
        self.request_headers = dict()
        self.request = request_obj
        self.func_name = func_name
        self.response = {
            "error_code": 200,
            "request_headers": self.request_headers,
            "data": []
        }

    def func_map(self):
        """
        方法映射
        """
        self.__get_headers()
        if self.func_name != "get_headers":
            getattr(self, self.func_name)()

    def __get_headers(self):
        """
        获取server接收到的请求头，并更新到Server对象的请求头属性
        """
        headers_obj = self.request.headers
        header_keys = headers_obj.keys()
        for _ in header_keys:
            self.request_headers[_] = headers_obj.get(_)

测试服务，验证不经过EdgeOne，直接通过IP地址请求服务，源站获取到的头部数据

从两次请求的响应结果来看，通过伪造XFF头部值，能够达到伪装XFF记录的目的。

下面是通过域名地址的方式验证对XFF头部值判断的结果：

在速率限制规则下，还发现可以配置JA3指纹有关的防护策略，不得不说，这简直就是APP端对抗黑产的克星。有兴趣的朋友可以体验一下。

WAF防护

waf相关的攻击被攻击方为两类，一个是服务端比如提权、挂马、sql注入等等；另一类是针对访问用户，比如通过XSS实现对访问用户电脑的数据扫描，恶意链接跳转等等。

这个攻击方式粗略来看可以分为大的几类：

1. path路径：如敏感文件读取/下载 .xxxx/.git/xxx
2. 参数：如sql注入或idap注入，xxx/?a=type=printer)(uid=*)
3. 请求头部：如造成因使用用IIS Http.sys处理Range溢出漏洞
4. 请求正文：如前两年很火的log4j漏洞 {\${::-j}\${::-n}\${::-d}}
5. 协议：如恶意文件上传：-X PUT xxxx/1.jsp

由于edgeone的waf规则太多，这里就直接梭哈，开启所有规则拦截，然后对以上五个特征位进行测试。

构造请求：

curl "test2.xxxx/.git/1"
echo ""
curl "test2.xxxx/?a=type=printer)(uid=*)"
echo ""
curl "test2.xxxx/file/1.txt" -H "Range: bytes=0-18446744073709551615"
echo ""
curl "test2.xxxx" -X POST --data {\${::-j}\${::-n}\${::-d}}
echo ""
curl -X PUT "test2.xxxx/1.jsp"

尝试对这五个特征位发起攻击，结果全部被拦截，edgeone的waf策略做的挺全面。

BOT管理

bot爬虫应该算最简单的，其特征基本都在UA里，做一些针对UA的过滤策略基本没啥大问题，如果是直接采用EdgeOne的UA特征规则，则依赖于EdgeOne的样本库全不全，这个没法了解，不过常规的如“ccbot”, "curl"， “Automated Security”这些，试了试还是能识别到的。不过话说回来，不建议像waf一样梭哈去设置拦截策略，很容易把正常请求流量误杀，除非只用做特殊网络服务，通过设置例外规则策略让指定网络或请求中包含指定特征的请求通过。

使用方式就不演示了，大家感兴趣可以自行尝试下。

使用感受

配置简单、防护能力全面。在实际使用方式上，应该能有更多可挖掘的使用方法。