针对昨天发生的DNS解析异常情况
SuCloud宿云简单更新了状态页面：
现在可以通过首页进入节点状态页面查看到Cloudflare近期（当前一个月内）发生的所有事件
遇到Cloudflare异常：
可以在页面上很方便的追踪查看当前Cloudflare所有关键服务具体异常状态以及具体处理进度

刷新页面将实时获取状态更新
数据源自官方:CloudflareStatus.com

关于接入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去完成解析更新