关于接入CF后的部分主动防御措施（不完全指南）
L7层防御
个人博客等静态页面为主的站点开一下CF的全站缓存可以大幅度提升用户访问速度以及获得极大防御能力

其它方面我们可以主动做的有：可以做一个搜集全网代理IP的软件，搜集验证这些IP后导入CF入站防火墙，可以屏蔽绝大部分来自L7层（俗称：cc攻击）低成本攻击来源（也可以在CF入站防火墙里限制威胁指数过高的IP访问，省了自己去找IP的麻烦，有一定程度误判）
配合软防限制请求频次（注意业务需要）主动推送到CF入站防火墙
合理启用CF的rate limit可以抵挡大部分攻击压力，
遇到有针对性的攻击，必要的话可以选择性开启CF的五秒盾or全站验证码模式（主动挨打，牺牲用户体验），分析日志，该拉黑的拉黑，存疑的扔验证码里去测试，顺路也能找到业务薄弱点进行手动加固和优化

L3/4层攻击
源站未泄露并做了入站防扫的话，接入CF后，来自L3/4层的所有攻击可以无视

对于主要以动态请求为主的站点可以考虑部署CF的RailGun（需要一定配置要求）相关资料自行查阅

当然源站自身（资金）才是一切的关键，要有一定软防策略以及配置：分布式负载（尽量拆分业务：前端/后端/数据库）避免单点故障，尽量选择GCP，AWS，AZ等拥有大带宽以及算力储备的云平台

关于Cloudflare API预期更新：
按账号限定在指定域名在某一方面管理使用权限（比如：目前的RailGun）
或按域名分发管理员权限，而不必直接使用全局API KEY操作账号下所有域名，避免失手（被黑/被盗/内部滥用）打碎一篮子鸡蛋（账号下所有域名一锅端）的问题出现
此特性将大幅度提升账号整体安全性，
此特性近期即将进行公测，
SuCloud宿云将会同步支持这种方式
#CF预告

北京时间6月13日 05:00-07:00
维护Cloudflare面板以及API
届时用户将无法对域名进行配置/功能切换与更改
#预告

请注意：DNSsec flag验证问题！
有一部分使用Cloudflare CNAME接入并同时使用Cloudflare DNS的朋友并没有注意到自己的域名在海外没有得到正常解析（DNSsec未通过验证的查询在8.8.8.8/1.1.1.1等海外公共DNS中，将会抛弃解析结果返回空值）

特征：
国内DNS目前因未全面启用DNSsrc flag验证机制（1.2.4.8等国内公共DNS直接是忽略且不验证策略）所以可以正常解析域名IP并正常访问；
但是海外（以及使用8.8.8.8/1.1.1.1作为DNS的用户）访问流量锐减，谷歌爬虫报错增多，域名无解析结果返回

检测命令：
/dig@SuCloudBot 域名

解决办法：
a，将DNS改为切换接入后域名所在账号指定的Cloudflare NS值（登录SuCloud宿云查看DNS选项卡）
b，使用第三方DNS（国内主流DNS大部分都选择不验DNSsec模式，只应答DNSsec验证请求，所以都是足够正常使用的）
c，可以考虑配置域名DS，全面启用DNSsec（切记：启用DNSsec在转移解析时也会需要验证以及缓存生效时间，错误配置将会导致域名无法正常解析）
#注意事项

CloudFlare Argo Tunnel开放免费版
CloudFlare 为 Argo 用户提供内网隧道回源服务——ArgoTunnel，可以用于内网转发、隐藏源站等

注意：免费版限速，仅供测试和尝鲜，Cloudflare没有 SLA 保证

来源出处：https://blog.cloudflare.com/a-free-argo-tunnel-for-your-next-project/
#消息

#部分用户反馈
Pro计划用户只看到SSL签发有一张ECC证书
Pro及以上用户专属的全设备兼容的RSA证书在一部分子域名上没有签发

原因：
之前非Pro状态转移接入，该子域名已签发有ECC证书，升到Pro及以上后并不会主动触发新的证书签发更新

解决办法：
a，个别子域：切换一下CDN状态即可立即签发；点两下DNS解析右侧的云朵：关闭CDN然后再开启CDN，刷新SSL页面即可查看到RSA证书签发状态
b，多个子域情况下：在SSL（加密）页面，禁用该域名所有SSL证书（Disable Universal SSL）重新打开恢复启用即可刷新全域SSL

DNS解析，用户审核日志，Argo隧道，Spectrum配置，SSL证书设置；更新设置以上功能将会出现延迟生效（最大30分钟）
03:52分：因为广播服务产生缓存风暴，现在更新设置最大生效延迟为2小时
06:13分：已解决
#事件 #Cloudflare异常

Telegram for Android v5.8.0
实测修复v5.7.1一些交互bug，同时更新了一系列功能，包括：附近的人、免通讯录添加好友、群组转让等

新特性描述：
- 添加附近的人和群组，支持创建和加入基于地理位置的聊天群组
- 转移群组/频道所有权
- 将任何用戶添加到联系人而无需知道其电话号码，在其资料页面可以选择"添加至联系人(Add As Contact)"
- 为特定的聊天切换消息预览，在"通知例外"设置中增加"搜索"和"删除全部"的功能

#Telegram更新 #TG更新 #Android #更新
推荐更新

19:02 检测到BGP劫持，部分Cloudflare IP段路由异常，正在联系修复
21:02 已解决

事件简述：AS33154（DQE：错误BGP广播）>>>AS701（Verizon：过滤/验证不严）>>>巨量的访问请求被错误的广播导向了一个狭小的路由造成严重堵塞，受影响互联网服务（Amazon、Linode、Facebook和CloudFlare等）

事件说明以及详细分析：https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/

給可能不经意被Cloudflare判定滥用清退的站长们一点经验

一些做站的朋友（特别是图床/音频/影视/下载类站点）；长时间（月为单位）大流量，高带宽占用检测为滥用（例如：存储用途）被清退

建议：
保持请求结构类型比例合理（在 分析>>>性能 页面，查看内容类型比例）：HTML类请求始终应该远大于50%，other类不宜长时间超过30%（关键）
使用多个账号和域名进行分流操作（仅预防缓解）

关于流量限制：
即使Free版用户也没有流量使用限制

避免检测为滥用而被Cloudflare清退
#提示 #站长 #结构 #流量 #限制 #注意 #清退 #滥用 #建议 #deactivated #status

本周前26日Google宣布：准备分阶段淘汰Google公共DNS的实验版DoH切换支持RFC 8484标准DoH，7月23日开始将定重向/experimental API到新的域名：dns.google，直至明年2020年6月23日将dns.google.com流量完全转移至dns.google，DoH标准目前在Firefox/Android 9/Cloudflare 公共DNS上支持/工作良好
公告：https://security.googleblog.com/2019/06/google-public-dns-over-https-doh.html
时间线：https://developers.google.com/speed/public-dns/docs/doh/migration#timeline

防止入站扫描找到隐藏在Cloudflare CDN后的源站IP
出处：关于接入Cloudflare CDN网络后如何防止源站IP泄露
@Cloudflare_CN
#安全 #防护 #扫描 #防火墙

说明：
重大停机影响了全球所有CloudFlare服务。我们看到CPU中的一个巨大尖峰导致主系统和辅助系统崩溃。我们关闭了导致CPU峰值的进程。约30分钟内服务恢复正常。我们现在正在调查事情的根本原因。

21:52，Cloudflare出现大规模502错误，受影响节点（集群）范围如图
具体原因未知，正在尝试修复（53-54分片段可访问）
22:12，海外（日本，美国，韩国等）用户访问已恢复正常
22:15，问题已解决，正在持续跟踪整体状态
22:57，确认已修复完全

PS：能看到502说明 CF前台集群依旧存活 后端服务出了问题，不慌

持续关注此事件后续

Cloudflare全球大规模502错误事件说明：由于软件部署不当导致服务中断

北京时间7月2号 21点52分左右开始持续约30分钟，全球访问CloudFlare站点的用户收到了502错误，这些错误是由于Cloudflare网络上的CPU使用率急剧上升造成的。此CPU峰值是由于上线了错误配置引起的。在回滚配置完成重启后，服务恢复正常运行，所有使用CloudFlare的域名恢复正常流量水平。

这不是一次攻击事件（不是一些人推测的那样），我们对这起事件的发生感到非常抱歉。内部团队正在开会，CTO（John Graham-Cumming）写了宕机分析这是如何发生的，以及后续如何防止这种情况再次发生。

此次全局中断的具体原因：发生在常规部署更新新的CloudFlare WAF管理的规则期间，在CloudFlare Web应用程序防火墙（WAF）中部署了配置错误的规则，其中一个规则包含有一个正则表达式，导致节点100%CPU占用。
因为WAF规则是由自动化测试套件在模拟模式下进行，它顺利通过了测试，并被一次性同步推送全球CDN节点上应用部署，因此导致全球集群机器上的CPU峰值达到100%。这100%的CPU峰值最终导致了大量用户访问时看到的502错误。在最糟糕的时候，覆盖了总体流量的82%。

教训：这样的事件对客户造成了巨大的伤害，已有的自动化测试过程的不完善，我们持续审查和改进已有测试-部署过程，以避免将来发生这样的事件

原文：Cloudflare outage caused by bad software deploy

CloudFlare单文件缓存清除操作可能会部分失败

10:11，正在解决该问题，在解决之前，请使用清除所有缓存功能，注意：执行清除所有缓存操作可能会导致回源流量激增
10:32，已定位问题，正在进行修复；在CDN系统中缓存是基础组成部分牵涉多个方面，虽然已定位问题，但需要一段时间进行无缝恢复
21:41，已修复完成

21:19，CloudFlare Web Analytics服务部分不可用。在管理面板和通过API拉取数据分析时受影响。
此事件还影响CloudFlare日志的获取。
CDN和安全配置等其它服务不受影响
北京时间7月4日：
03:42，已修复上述问题
04:27，部分用户无法查看域名下的访问流量数据以及rate limiting数据
05:58，已全部修正

北京时间7月4号，晚上23点05分左右，不少CFP被Cloudflare标注钓鱼网站并取消合作伙伴接入授权，SuCloud宿云也受影响，暂时无法完成登录验证进行后续服务，用户原本的订阅以及功能权益不受影响（除DNS解析因无法通过CF账号密码登录获得授权Key进行直接在线管理外）
功能使用请前往Cloudflare官方面板（ dash.cloudflare.com ），
DNS域名解析使用CF API或者还存活的CF第三方合作伙伴，
合作伙伴的解决办法：已被暂停或者取消合作伙伴的，尽快上线基于CF API的在线操作管理面板，未取消合作伙伴的，加强用户登录验证防止滥用，联系Cloudflare申请恢复授权，解除钓鱼阻截页面提示
第三方合作伙伴CNAME方式接入的用户：临时通过开源的CF面板/客户端或者直接使用CF API管理DNS解析，其它功能在CF官方面板上操作

简述：
主要影响目标：Cloudflare 主机托管合作伙伴（部分）
关键点：取消了合作伙伴接入验证权限，合作伙伴方因无法正常获取API Key导致自主开发的面板无法正常工作（主要受限：DNS解析管理）
谁不受影响？：正常以NS方式接入（无论是否在Cloudflare完成）的用户不受任何影响；已有订阅的功能、权益不受任何影响

注意：通过合作伙伴接入的用户的DNS解析需要绕弯一下（因为你的接入管理方可能已被取消接入授权，直接通过接入方的管理平台可能已无法正常配置解析）；需要通过CF API去完成解析更新

关于Cloudflare合作伙伴（常识普及）

1，Cloudflare不会因为合作伙伴合理存储使用用户邮箱账号/APIKey/UserKey而导致取消合作伙伴授权，接入CF共享账号授权的合作伙伴同时有个身份叫：自主托管优化服务商
例子：用户登录使用Plesk上Cloudflare拓展插件内置的管理面板；将会无限期保存Cloudflare邮箱账号/APIKey/UserKey直至Plesk管理员手动删除或清空对应数据库。Plesk闭源使用CF HOST API、CF API进行工作，正常使用Plesk面板的主机商（合作伙伴）并不会因此被Cloudflare取消接入授权，其它比如WHMCS也是如此，看不来二者知名面板代码也没关系，细心一点不需要看源码也可以自行轻松测试通过面板反馈得出结论（如果你有看完本文关于CF API Keys介绍）

2，目前已知CF取消合作伙伴授权的一般原因：长期无接入空置，接入账号存在滥用（批量添加所有权不明的域名，长期带宽滥用，撞库，批量注册CF账号等），违反Cloudflare 使用条款（比如：模仿Cloudflare提供服务）

3，Cloudflare给予合作伙伴面向用户的主要权限为：快速创建CF账号、账号密码登录验证、域名接入权限（接入方式：CNAME/NS、一票否决权：无条件移除通过该合作伙伴接入的域名）、需要额外签署合约的Railgun接入管理权限

关于用户账号安全
Cloudflare面向所有用户引入了操作审核日志系统；所有操作无论是用户、CF官方、合作伙伴，无论何时以何种方式操作改变账号下任何配置都将会记录在日志中且任何人以任何方式都不可更改该日志历史记录，以此作为审核排查的重要依据
全文出处：Cloudflare合作伙伴常识以及部分API Key介绍