IT瘾网络推荐

GDC：2026年游戏业界52%人士认为AI产生负面影响

Sun, 01 Feb 2026 21:18:49 CST

世界游戏业界专业开发者论坛Game Developers Conference（GDC）的组织者、Informa Tech于1月29日发布了一项最新调查报告“2026 STATE OF THE GAME INDUSTRY”，邀请了2300位游戏业界人士调查对于当下最火的AI技术对于游戏业界的影响，已经有52%的游戏业界人士认为AI会产生负面影响。

·“2026 STATE OF THE GAME INDUSTRY”总计收到了游戏业界人士2300人以上的有效调查问卷，其中既有一线游戏开发者，也有市场、营销、投资者等游戏业界相关人士。

·听起来似乎只有半数的游戏业界人士对AI持有悲观态度，但是对比前几年的调查，就会发现近三年对AI持有悲观态度的业内人士直线上升，相较而言，仍然对AI能够帮助游戏业界良性发展抱有信心的人士正在极速减少。

·在具体的负面影响细节调查方面，占比最多的是艺术设计达到64%，游戏设计以及剧本创作占比63%，编程为59%，实际上这些也是赞同AI参与游戏创作的开发商大力支持的主要原因。

·使用的AI模型工具最多的仍然是老牌工具ChatGPT，占比74%，占据绝对优势，其他各大巨头的主推工具各有排名。

自 3DMGame

数据中心网络高可用技术之从交换机到交换机：MLAG, 堆叠技术

Thu, 08 Aug 2024 10:04:25 CST

在上一篇文章结束对链路聚合的讨论之后，我们发现一个问题——我们只能用多条线连接到同一个 switch 上面，这样万一这个交换机挂了，连接这个这个交换机的机器（通常是一个 Rack）就一起消失了。

MLAG 技术

MLAG(Multi-Chassis Link Aggregation) 可以提供跨设备的链路聚合功能。

思科模块化交换机

Multi-Chassis 这个词很有意思，为什么叫做 Chassis （机箱）而不叫座 Multi-Switch LAG 呢？因为这个功能不仅仅是运行在 Switch 上，还记得在理解网络的分层模型中说的吗？二层和三层设备的界限已经越来越模糊了，三层设备也可以有这个功能。

现在的网络设备都是模块化的，一个机箱上面可以根据自己的需求插不同的线卡，卡上面甚至还能装不同的模块，满足不同的需求。机箱可以认为是网络设备单元，以「机箱」来说，意思就是运行于不同网络设备之间的功能。

MLAG 是一个设备的 feature，而不是协议，所以在不同厂商的产品中，MLAG，Peer Link 等术语会有所不同。

多交换机 MLAG

对于客户端 Linux 来说，不知道对端是两个设备，在 Linux 的视角下，自己的多条线路连接的就是同一个设备。

在交换机侧，就需要跨设备完成 LACP 信息的同步，两个交换机设备之间需要协调好，A 的 3号端口和 B 的 3号端口是同一个链路聚合组(LAG)。所以两个交换机之间需要一条线，来沟通控制面的信息。这条线就叫做 Peer Link。在 Peer Link 上如何传输控制信息，取决于不同厂商对于 MLAG 的实现。某些厂商的设备使用 ICCP (Inter-Control Center Communications Protocol) 来进行不同的机箱之间的连接。

这样，就可以完成从服务器到交换机的高可用了，服务器网卡、网线、交换机接口、交换机系统、交换机整机，任意一个地方出现问题，都有冗余路线，不会对服务造成太大影响。

数据中心广泛使用的就是 MLAG。

堆叠技术

在交换机之间的高可用，还有一种技术，就是交换机堆叠。这个功能在不同的厂商里也是不同的名字，比如华为的 istack，思科的 StackWise.

简单来说，这个功能可以让多个交换机虚拟成一个。只有一个主操作系统在运行，其他的交换机就像主交换机扩展出来的板卡一样。堆叠之后只有一个管理 IP 和 MAC 地址，只需要登录一个系统进行配置操作。

4个交换机完成堆叠之后，相当于一个交换机有了 4 倍的端口

堆叠之后逻辑上就是一个交换机，所以服务器可以直接连接到多个物理交换机，从逻辑上看，交换机侧也是同一个了。

交换机堆叠连接服务器

堆叠也能实现故障快速切换，在正常情况下也能充分利用线路的带宽，配置简单。但是和 MLAG 相比，稳定性上来说 MLAG 更高，因为堆叠交换机只有一个控制面，如果主交换机出现故障，比如堆叠失效，整个堆叠集群都会出错。MLAG 的故障域更小，交换机坏也就坏一台。这也带来很多维护便利，从升级维护上说，MLAG 可以让我们一台一台地操作交换机升级而不影响服务，堆叠就会更加麻烦一些。从部署上，MLAG 不受距离显示，堆叠的话，两个交换机距离越远，出错的概率越大。

说起来，思科还有一个 VDC 技术(Virtual Device Context), 支持把一个设备虚拟成多个。这些技术又是把一个物理设备拆成多个又是把多个合成一个的，可真有意思。

这个系列的二层技术介绍的差不多了，我们下一篇就开始聊三层技术。

Until next time!

数据中心网络高可用技术系列

聊聊 nostr 和审查

Fri, 03 Feb 2023 15:46:13 CST

这两天在网络上又有一个东西火了，Twitter 的创始人 @jack 新的社交 iOS App Damus 上苹果商店（第二天就因为违反中国法律在中国区下架了），这个软件是一个去中心化的 Twitter，使用到的是 nostr – Notes and Other Stuff Transmitted by Relays 的协议（协议简介，协议细节），协议简介中有很大的篇幅是在批评Twitter和其相类似的中心化的产品，如： Masodon 和 Secure Scuttlebutt 。我顺着去看了一下这个协议，发现这个协议真是非常的简单，简单到几句话就可以讲清楚了。

通讯过程

这个协议中有两个东西，一个是 client，一个是 relay，client 就是用户社交的客户端，relay 就是转发服务器。
用户不需要注册，用户只需要有一个密钥对（公钥+私钥）就好了，然后把要发的信息做签名，发给一组 relays
然后你的 Follower 就可以从这些 relays 上订阅到你的信息。

技术细节摘要

技术实现上，nostr 使用 websocket + JSON 的方式。其中主要是下面这么同个指令
- Client 到 Relay主要是下面这几个指令：
  - EVENT。发出事件，可以扩展出很多很多的动作来，比如：发信息，删信息，迁移信息，建 Channel ……扩展性很好。
  - REQ。用于请求事件和订阅更新。收到 REQ消息后，relay 会查询其内部数据库并返回与过滤器匹配的事件，然后存储该过滤器，并将其接收的所有未来事件再次发送到同一websocket，直到websocket关闭。
  - CLOSE。用于停止被 REQ 请求的订阅。
- Relay 到 Client 主要是下面几个指令：
  - EVENT。用于发送客户端请求的事件。
  - NOTICE。用于向客户端发送人类可读的错误消息或其他信息
关于 EVENT 下面是几个常用的基本事件：
- 0: set_metadata：比如，用户名，用户头像，用户简介等这样的信息。
- 1: text_note：用户要发的信息内容
- 2： recommend_server：用户想要推荐给关注者的Relay的URL（例如 wss://somerelay.com）

如何对抗网络审查

那么，这个协议是如何对抗网络审查的？

识别你的身份是通过你的签名，所以，只要你的私钥还在，你是不会被删号的
任何人都可以运行一个或多个relay，所以，就很难有人控制所有的relay
你还可以很方便的告诉其中的 relay 把你发的信息迁到另一个 relay 上
你的信息是一次发给多个relay的，所以，只要不是所有的热门realy封了你，你就可以发出信息
每个relay的运营者都可以自己制定规则，会审查哪些类型内容。用户据此选择即可。基本不会有一个全局的规则。
如果你被全部的relay封了，你还是可以自建你的relay，然后，你可以通过各种方式告诉你身边的人你的relay服务器是什么？这样，他们把这个relay服务器加到他们的client列表中，你又可以从社死中复活了。

嗯，听起来很简单，整个网络是构建在一种 “社区式”的松散结构，完全可能会出现若干个 relay zone。这种架构就像是互联网的架构，没有中心化，比如 DNS服务器和Email服务器一样，只要你愿意，你完全可以发展出自己圈子里的“私服”。

其实，电子邮件是很难被封禁和审查的。我记得2003年中国非典的时候，我当时在北京，当时的卫生部部长说已经控制住了，才12个人感染，当局也在控制舆论和删除互联网上所有的真实信息。但是，大家都在用电子邮件传播信息，当时基本没有什么社交软件，大家分享信息都是通过邮件，尤其是外企工作的圈子，当时每天都要收很多的非典的群发邮件，大家还都是用公司的邮件服务器发……这种松散的，点对点的架构，让审查是基本不可能的。其实， 我觉得 nostr 就是另外一个变种或是升级版的 email 的形式。

如何对抗Spam和骗子

但是问题来了，如果不能删号封人的话，那么如何对抗那些制造Spam，骗子或是反人类的信息呢？nostr目前的解决方案是通过比特币闪电网络。比如有些客户端实现了如果对方没有follow 你，如果给他发私信，需要支付一点点btc ，或是relay要求你给btc才给你发信息等等。

不过，我觉得也有可以有下面的这些思路：

用户主动拉黑，但很明显这个效率不高，而且体验不好
社区或是同盟维护一个黑名单，relay定期更新（如同email中防垃圾邮件也是这样搞的），这其实也是审查。
防Spam的算法过滤垃圾信息（如同email中干的），自动化审查。
增加发Spam的成本，如: PoW 工作量证明（比特币的挖坑，最早也是用于Email），发信息要花钱等。
……

总之，还是有相应的方法的，但是一定没有完美解，email对抗了这么多年，你还是可以收到大量的垃圾邮件和钓鱼邮件，所以，我觉得 nostr 也不可能做到……

怎么理解审查

最后，我们要明白的是， 无论你用什么方法，审查是肯定需要的，所以，我觉得要完全干掉审查，最终的结果就是一个到处都垃圾内容的地方！

我理解的审查不应该是为权力或是个体服务的，而是为大众和人民服务的，所以，审查必然是要有一个开放和共同决策的流程，而不是独断的。

这点可以参考开源软件基金会的运作模式。

最底端的是用户（User）参与开源社区的使用并提供问题和反馈。
用户在使用过程中了解项目情况后贡献代码和文档就可以晋升为贡献者（Contributors），
当贡献者提交一定数量贡献之后就可以晋升为提交者（Committers），此时你将拥有你参与仓库的代码读写权限。
当提交者Committers在社区得到认可后，由项目管理委员会（PMC）选举并产生PMC成员（类似于议员），PMC成员拥有社区相关事务的投票、提名和共同决策权利和义务。

注意下面几点

整个社区的决策者，是要通过自己贡献来挣到被选举权的。
社区所有的工作和决定都是要公开的。
社区的方向和决策都是要投票的，PMC成员有binding的票权，大众也有non-binding的投票权供参考。
如果出现了价值观的不同，那么，直接分裂社区就好了，不同价值观的人加入到不同的社区就好了。

如果审查是在这个框架下运作的话，虽然不完美，但至少会在一种公允的基础下运作，是透明公开的，也是集体决策的。

开源软件社区是一个很成功的示范，所以，我觉得只有技术而没有一个良性的可持续运作的社区，是不可能解决问题的， 干净整齐的环境是一定要有人打扫和整理的。

（全文完）

（转载本站文章请注明作者和出处酷壳 – CoolShell ，请勿用于任何商业用途）

The post 聊聊 nostr 和审查 first appeared on 酷壳 - CoolShell.

面向推荐的汽车知识图谱构建

Mon, 08 Aug 2022 17:36:26 CST

一、背景

1、引言

知识图谱的概念，最早由 Google 在2012 年提出，旨在实现更智能的搜索引擎，并在2013年之后开始在学术界和工业级普及。目前，随着人工智能技术的高速发展，知识图谱已广泛应用于搜索、推荐、广告、风控、智能调度、语音识别、机器人等多个领域。

2、发展现状

知识图谱作为人工智能的核心技术驱动力，能缓解深度学习依赖海量训练数据、大规模算力的问题，它能够广泛适配不同的下游任务，且具有良好的解释性，因此，全球大型互联网公司都在积极部署本企业的知识图谱。
例如2013年Facebook发布Open Graph，应用于社交网络智能搜索；2014年百度推出的知识图谱，主要应用于搜索、助理、及toB商业场景；2015年阿里推出的商品知识图谱，在前端导购、平台治理和智能问答等业务上起到关键作用；腾讯于17年推出的腾讯云知识图谱，有效助力于金融搜索、实体风险预测等场景；美团于2018年推出的美团大脑知识图谱，已经在智能搜索推荐、智能商户运营等多个业务中落地。

3、目标及收益

目前领域图谱主要集中在电商、医疗、金融等商业领域，而关于汽车知识的语义网络及知识图谱构建缺少系统性的指导方法。本文以汽车领域知识为例，围绕车系、车型、经销商、厂商、品牌等实体及相互关系，提供一种从零搭建领域图谱的思路，并对搭建知识图谱中的步骤及方法进行了详细说明，以及介绍了基于本图谱的几个典型落地应用。
其中，数据源采用汽车之家网站，汽车之家是由导购、资讯、评测、口碑等多个板块组成的汽车服务类平台，在看、买、用等维度积累了大量的汽车数据，通过构建知识图谱把以汽车为核心的内容进行组织和挖掘，提供丰富的知识信息，结构化精准刻画兴趣，支持推荐用户冷启、召回、排序、展示等多个维度，给业务提升带来效果。

二、图谱构建

1、构建的挑战

知识图谱是真实世界的语义表示，，其基本组成单位是【实体-关系-实体】，【实体-属性-属性值】的三元组（Triplet），实体之间通过关系相互联结，从而构成语义网络。图谱构建中会面临较大的挑战，但构建之后，可在数据分析、推荐计算、可解释性等多个场景展现出丰富的应用价值。
构建挑战：

schema难定义：目前尚无统一成熟的本体构建流程，且特定领域本体定义通常需专家参与；
数据类型异构：通常情况下，一个知识图谱构建中面对的数据源不会是单一类型，包含结构化、半结构化，及非结构化数据，面对结构各异的数据，知识转模及挖掘的难度较高；
依赖专业知识：领域知识图谱通常依赖较强的专业知识，例如车型对应的维修方法，涉及机械、电工、材料、力学等多个领域知识，且此类关系对于准确度的要求较高，需要保证知识足够正确，因此也需要较好的专家和算法相结合的方式来进行高效的图谱构建；
数据质量无保证：挖掘或抽取信息需要知识融合或人工校验，才能作为知识助力下游应用。
收益：
知识图谱统一知识表示：通过整合多源异构数据，形成统一视图；
语义信息丰富：通过关系推理可以发现新关系边，获得更丰富的语义信息；
可解释性强：显式的推理路径对比深度学习结果具有更强的解释性；
高质量且能不断积累：根据业务场景设计合理的知识存储方案，实现知识更新和累积。

2、图谱架构设计

技术架构主要分为构建层、存储层及应用层三大层，架构图如下：
构建层：包括schema定义，结构化数据转模，非结构化数据挖掘，以及知识融合；
存储层：包括知识的存储和索引，知识更新，元数据管理，以及支持基本的知识查询；
服务层：包括智能推理、结构化查询等业务相关的下游应用层。

3、具体构建步骤及流程

依据架构图，具体构建流程可分为四步：本体设计、知识获取、知识入库，以及应用服务设计及使用。
3.1 本体构建
本体（Ontology）是公认的概念集合，本体的构建是指依据本体的定义，构建出知识图谱的本体结构和知识框架。
基于本体构建图谱的原因主要有以下几点：
明确专业术语、关系及其领域公理，当一条数据必须满足Schema预先定义好的实体对象和类型后，才允许被更新到知识图谱中。
将领域知识与操作性知识分离，通过Schema可以宏观了解图谱架构及相关定义，无须再从三元组中归纳整理。
实现一定程度的领域知识复用。在构建本体之前，可以先调研是否有相关本体已经被构建出来了，这样可以基于已有本体进行改进和扩展，达到事半功倍的效果。
基于本体的定义，可以避免图谱与应用脱节，或者修改图谱schema比重新构建成本还要高的情况。例如将“宝马x3”、“2022款宝马x3”都作为汽车类实体来储存，在应用时都可能造成实例关系混乱、可用性差的问题，这种情况可以在设本体计阶段，通过将“汽车类实体”进行“车系”、“车型”子类细分的方法来避免。
按照知识的覆盖面来看，知识图谱可以划分为通用知识图谱和领域知识图谱，目前通用知识图谱已有较多案例，例如Google的Knowledge Graph、微软的Satori和Probase等，领域图谱则为金融、电商等具体行业图谱。通用图谱更注重广度，强调融合更多的实体数量，但对精确度的要求不高，很难借助本体库对公理、规则及约束条件进行推理和使用；而领域图谱的知识覆盖范围较小，但知识深度更深，往往是在某一专业领域上的构建。
考虑对准确率的要求，领域本体构建多倾向于手工构建的方式，例如代表性的七步法、IDEF5方法等[1]，该类方法的核心思想是，基于已有结构化数据，进行本体分析，将符合应用目的和范围的本体进行归纳及构建，再对本体进行优化和验证，从而获取初版本体定义。若想获取更大范畴的领域本体，则可以从非结构化语料中补充，考虑手工构建过程较大，本文以汽车领域为例，提供一种半自动本体构建的方式，详细步骤如下：
首先收集大量汽车非结构化语料（例如车系咨询、新车导购文章等），作为初始个体概念集，利用统计方法或无监督模型（TF-IDF、BERT等）获取字特征和词特征；
其次利用BIRCH聚类算法对概念间层次划分，初步构建起概念间层级关系，并对聚类结果进行人工概念校验和归纳，获取本体的等价、上下位概念；
最后使用卷积神经网络结合远程监督的方法，抽取本体属性的实体关系，并辅以人工识别本体中的类及属性的概念，构建起汽车领域本体。
上述方法可有效利用BERT等深度学习的技术，更好地捕捉语料间的内部关系，使用聚类分层次对本体各模块进行构建，辅以人工干预，能够快速、准确的完成初步本体构建。下图为半自动化本体构建示意图：

利用Protégé本体构建工具[2]，可以进行本体概念类、关系、属性和实例的构建，下图为本体构建可视化示例图：

本文将汽车领域的顶层本体概念划分为三类，实体、事件及标签体系：
1）实体类代表特定意义的概念类实体，包括词汇实体和汽车类实体，其中汽车类实体又包括组织机构和汽车概念等子实体类型；
2）标签体系代表各个维度的标签体系，包括内容分类、概念标签、兴趣标签等以物料维度刻画的标签；
3）事件类代表一个或多个角色的客观事实，不同类型事件间具有演变关系。
Protégé可以导出不同类型的Schema配置文件，其中owl.xml结构配置文件如下图所示。该配置文件可直接在MYSQL、JanusGraph中加载使用，实现自动化的创建Schema。

3.2 知识获取

知识图谱的数据来源通常包括三类数据结构，分别为结构化数据、半结构化数据、非结构化数据。面向不同类型的数据源，知识抽取涉及的关键技术和需要解决的技术难点有所不同。

3.2.1 结构化知识转模

结构化数据是图谱最直接的知识来源，基本通过初步转换就可以使用，相较其他类型数据成本最低，所以一般图谱数据优先考虑结构化数据。结构化数据可能涉及多个数据库来源，通常需要使用ETL方法转模，ETL即Extract（抽取）、Transform（转换）、Load（装载），抽取是将数据从各种原始的业务系统中读取出来，这是所有工作的前提；转换是按照预先设计好的规则将抽取的数据进行转换，使本来异构的数据格式可以统一起来；装载是将转换完的数据按计划增量或全部导入到数据仓库中。
通过上述ETL流程可将不同源数据落到中间表，从而方便后续的知识入库。下图为车系实体属性、关系表示例图：

车系与品牌关系表：

3.2.2 非结构化知识抽取-三元组抽取

除了结构化数据，非结构化数据中也存在着海量的知识（三元组）信息。一般来说企业的非结构化数据量要远大于结构化数据，挖掘非结构化知识能够极大拓展和丰富知识图谱。
三元组抽取算法的挑战
问题1：单个领域内，⽂档内容和格式多样，需要⼤量的标注数据，成本⾼
问题2：领域之间迁移的效果不够好，跨领域的可规模化拓展的代价⼤
模型基本都是针对特定⾏业特定场景，换⼀个场景，效果会出现明显下降。
解决思路，Pre-train + Finetune的范式，预训练：重量级底座让模型“⻅多识⼴”充分利⽤⼤规模多⾏业的⽆标⽂档，训练⼀个统⼀的预训练底座，增强模型对各类⽂档的表示和理解能⼒。
微调：轻量级⽂档结构化算法。在预训练基础上，构建轻量级的⾯向⽂档结构化的算法，降低
标注成本。
针对⽂档的预训练⽅法
现有关于⽂档的预训练模型，如果文本较短的类型，Bert可以完全编码整篇⽂档；⽽我们实际的⽂档通常⽐较⻓，需要抽取的属性值有很多是超过1024个字的，Bert进⾏编码会造成属性值截断。
针对长文本预训练方法优点和不足
Sparse Attention的⽅法通过优化Self-Attention，将O(n2)的计算优化⾄O(n)，⼤⼤提⾼了输⼊⽂本⻓度。虽然普通模型的⽂本⻓度从512提升到4096，但是依旧不能完全解决截断⽂
本的碎⽚化问题。百度提出了ERNIE-DOC[3]使用了Recurrence Transformer方法，理论上可以建模⽆限⻓的⽂本。由于建模要输⼊所有的⽂本信息，耗时⾮常⾼。
上述两种基于⻓⽂本的预训练⽅法，都没有考虑⽂档特性，如空间(Spartial)、视觉(Visual)等信息。并且基于⽂本设计的PretrainTask，整体是针对纯⽂本进⾏的设计，⽽没有针对⽂档的逻辑结构设计。
针对上述不足这里介绍一种⻓⽂档预训练模型DocBert[4],DocBert模型设计：
使⽤⼤规模（百万级）⽆标注⽂档数据进⾏预训练，基于⽂档的⽂本语义(Text)、版⾯信息
(Layout)、视觉特征(Visual)构建⾃监督学习任务，使模型更好地理解⽂档语义和结构信息。
1.Layout-Aware MLM：在Mask语⾔模型中考虑⽂本的位置、字体⼤⼩信息，实现⽂档布局感知的语义理解。
2.Text-Image Alignment：融合⽂档视觉特征，重建图像中被Mask的⽂字，帮助模型学习⽂本、版⾯、图像不同模态间的对⻬关系。
3.Title Permutation：以⾃监督的⽅式构建标题重建任务，增强模型对⽂档逻辑结构的理解能⼒。
4.Sparse Transformer Layers：⽤Sparse Attention的⽅法，增强模型对⻓⽂档的处理能⼒。

3.2.3 挖掘概念，兴趣词标签，关联到车系、实体

除了结构化和非结构化文本中获取三元组，汽车之家还挖掘物料所包含的分类、概念标签和兴趣关键词标签，并建立物料和车实体之间的关联，为汽车知识图谱带来新的知识。下面从分类、概念标签、兴趣词标签来介绍汽车之家所做的内容理解部分工作以及思考。
分类体系作为内容刻画基础，对物料进行粗粒度的划分。建立的统一的内容体系更多的是基于人工定义的方式，通过AI模型进行划分。在分类方法上我们我们采用了主动学习，对于比较难分的数据进行标注，同时采用数据增强，对抗训练，以及关键词融合方式提高分类的效果。

概念标签粒度介于分类和兴趣词标签之间，比分类粒度更细，同时比兴趣词对于兴趣点刻画更加完整，我们建立了车视野、人视野、内容视野三个维度，丰富了标签维度，细化了标签粒度。丰富且具体的物料标签，更加方便搜索推荐基于标签的模型优化，且可用于标签外展起到吸引用户及二次引流等作用。概念标签的挖掘，结合在query等重要数据上采用机器挖掘方式，并对概括性进行分析，通过人工review，拿到概念标签集合，采用多标签模型分类。
兴趣词标签是最细粒度的标签，映射为用户兴趣，根据不同用户兴趣偏好进可以更好的进行行个性化推荐。关键词的挖掘采用多种兴趣词挖掘相结合的方式，包括Keybert提取关键子串，并结合TextRank、positionRank、singlerank、TopicRank、MultipartiteRank等+句法分析多种方法，产生兴趣词候选。

挖掘出来的词，相似度比较高，需要对同义词进行识别，需要提升人工的效率，因此我们也通过聚类进行自动化语义相似识别。用于聚类的特征有word2vec，bert embding等其他人工特征。然后使用聚类方法，最后经过人工矫正我们离线产生了一批高质量的关键词。
对于不同粒度的标签还是在物料层面的，我们需要把标签和车建立起关联，首先我们分别计算出标题\文章的所属标签，然后识别出标题\文章内的实体，得到若干标签-实体伪标签，最后根据大量的语料，共现概率高的标签就会标记为该实体的标签。通过以上三个任务，我们在获得了丰富且海量的标签。对车系、实体关联上这些标签，会极大丰富我们的汽车图谱，建立了媒体和用户的关注车标签。

3.2.4人效提升：

伴随着更大规模的训练样本，如何获得更好的模型质量，如何解决标注成本高，标注周期长成为亟待解决的问题。首先我们可以使用半监督学习，利用海量未标注数据进行预训练。然后采用主动学习方式，最大化标注数据的价值，迭代选择高信息量样本进行标注。最后可以利用远程监督，发挥已有知识的价值，发觉任务之间的相关性。例如在有了图谱和标题后，可以用远程监督的方法基于图谱构造NER训练数据。

3.3 知识入库

知识图谱中的知识是通过RDF结构来进行表示的，其基本单元是事实。每个事实是一个三元组(S, P, O)，在实际系统中，按照存储方式的不同，知识图谱的存储可以分为基于RDF表结构的存储和基于属性图结构的存储。图库更多是采用属性图结构的存储，常见的存储系统有Neo4j、JanusGraph、OritentDB、InfoGrid等。
图数据库选择
通过 JanusGraph 与 Neo4J、ArangoDB、OrientDB 这几种主流图数据库的对比，我们最终选择JanusGraph 作为项目的图数据库，之所以选择 JanusGraph，主要有以下原因：

基于 Apache 2 许可协议开放源码，开放性好。
支持使用 Hadoop 框架进行全局图分析和批量图处理。
支持很大的并发事务处理和图操作处理。通过添加机器横向扩展 JanusGraph 的事务处理能力，可以在毫秒级别相应大图的复杂查询。
原生支持 Apache TinkerPop 描述的当前流行的属性图数据模型。
原生支持图遍历语言 Gremlin。
下图是主流图数据库对比

Janusgraph介绍
JanusGraph[5]是一个图形数据库引擎。其本身专注于紧凑图序列化、丰富图数据建模、高效的查询执行。图库schema 构成可以用下面一个公式来表示：
janusgraph schema = vertex label + edge label + property keys
这里值得注意的是property key通常用于graph index。

为了更好的图查询性能janusgraph建立了索引，索引分为Graph Index，Vertex-centric Indexes。Graph Index包含组合索引(Composite Index)和混合索引(Mixed Index).
组合索引仅限相等查找。（组合索引不需要配置外部索引后端，通过主存储后端支持(当然也可以配置hbase，Cassandra，Berkeley))
举例：
mgmt.buildIndex('byNameAndAgeComposite', Vertex.class).addKey(name).addKey(age).buildCompositeIndex() #构建一个组合索引“name-age”
g.V().has('age', 30).has('name', '小明')#查找名字为小明年龄30的节点
混合索引需要ES作为后端索引以支持除相等以外的多条件查询（也支持相等查询，但相等查询，组合索引更快）。根据是否需要分词分为full-text search，和string search
JanusGraph数据存储模型
了解Janusgraph存储数据的方式，有助于我们更好的利用该图库。JanusGraph 以邻接列表格式存储图形，这意味着图形存储为顶点及其邻接列表的集合。顶点的邻接列表包含顶点的所有入射边（和属性）。

JanusGraph 将每个邻接列表作为一行存储在底层存储后端中。（64 位）顶点 ID（JanusGraph 唯一分配给每个顶点）是指向包含顶点邻接列表的行的键。每个边和属性都存储为行中的一个单独的单元格，允许有效的插入和删除。因此，特定存储后端中每行允许的最大单元数也是 JanusGraph 可以针对该后端支持的顶点的最大度数。
如果存储后端支持 key-order，则邻接表将按顶点 id 排序，JanusGraph 可以分配顶点 id，以便对图进行有效分区。分配 id 使得经常共同访问的顶点具有绝对差异小的 id。

3.4 图谱查询服务

Janusgraph进行图搜索用的是gremlin语言，我们提供了统一的图谱查询服务，外部使用不用关心gremlin语言的具体实现，采用通用的接口进行查询。我们分为三个接口：条件搜索接口，以节点为中心向外查询，和节点间路径查询接口。下面是几个gremlin实现的例子：

条件搜索：查询10万左右，销量最高的车：
g.V().has('price',gt(8)).has('price',lt(12)).order().by('sales',desc).valueMap().limit(1)
输出：
==>{name=[xuanyi], price=[10], sales=[45767]}
轩逸销量最高，为45767
以节点为中心向外查询：查询以小明为中心，2度的节点
g.V(xiaoming).repeat(out()).times(2).valueMap()
节点间路径查询：荐给小明推荐两篇文章，这两篇文章分别介绍的是卡罗拉和轩逸，查询小明和这两篇文章的路径：
g.V(xiaoming).repeat(out().simplePath()).until(or(has("car", 'name', 'kaluola'),has("car", 'name', 'xuanyi'))).path().by("name")
输出
==>path[xiaoming, around 10w, kaluola]
==>path[xiaoming, around 10w, xuanyi]
发现小明和这两篇文章之间有个节点“10万左右”

三、知识图谱在推荐的应用

知识图谱中存在大量的非欧式数据，基于KG的推荐应用有效利用非欧式数据提升推荐系统准确度，进而让推荐系统能达到传统系统所无法达到的效果。基于KG的推荐可以分成以三类，基于KG表征技术（KGE）、基于路径的方法、图神经网络。本章将从KG在推荐系统中冷启、理由、排序三方面的应用和论文进行介绍。

3.1 知识图谱在推荐冷启动的应用

知识图谱能够从user-item交互中建模KG中隐藏的高阶关系,很好地解决了因用户调用有限数量的行为而导致的数据稀疏性，进而可以应用在解决冷启动问题。这一问题业界也有相关研究。
Sang 等[6]提出了一种双通道神经交互方法，称为知识图增强的残差递归神经协同过滤（KGNCF-RRN），该方法利用KG上下文的长期关系依赖性和用户项交互进行推荐。（1）对于KG上下文交互通道，提出了残差递归网络（RRN）来构造基于上下文的路径嵌入，将残差学习融入传统的递归神经网络（RNN）中，以有效地编码KG的长期关系依赖。然后将自关注网络应用于路径嵌入，以捕获各种用户交互行为的多义。（2）对于用户项目交互通道，用户和项目嵌入被输入到新设计的二维交互图中。（3）最后，在双通道神经交互矩阵之上，使用卷积神经网络来学习用户和项目之间的复杂相关性。该方法能捕捉丰富的语义信息，还能捕捉用户与项目之间复杂的隐含关系，用于推荐。
Du Y等[7]提出了一种新的基于元学习框架的冷启问题解决方案MetaKG，包括collaborative-aware meta learner和knowledge-aware meta learner，捕捉用户的偏好和实体冷启动知识。collaborative-aware meta learner学习任务旨在聚合每个用户的偏好知识表示。相反，knowledge-aware meta learner学习任务要在全局泛化不同的用户偏好知识表示。在两个learner的指导下，MetaKG可以有效地捕捉到高阶的协作关系关系和语义表示，可以轻松适应冷启动场景。此外，作者还设计了一种自适应任务，可以自适应地选择KG信息进行学习，以防止模型被噪声信息干扰。MetaKG架构如下图所示。

3.2 知识图谱在推荐理由生成的应用

推荐理由能提高推荐系统的可解释性，让用户理解生成推荐结果的计算过程，同时也可以解释item受欢迎的原因。用户通过推荐理由了解推荐结果的产生原理，可以增强用户对系统推荐结果的信心，并且在推荐失误的情况下对错误结果更加宽容。
最早可解释推荐是以模板为主，模板的好处是保证了可读性和高准确率。但是需要人工整理模板，并且泛华性不强，给人一种重复的感觉。后来发展不需要预设的free-form形式，并且加以知识图谱，以其中的一条路径作为解释，配合标注还有一些结合KG路径的生成式的方法，模型中选择的每个点或边都是一个推理过程，可以向用户展示。最近Chen Z [8]等人提出一种增量多任务学习框架ECR，可以实现推荐预测、解释生成和用户反馈集成之间的紧密协作。它由两大部分组成。第一部分，增量交叉知识建模，学习推荐任务和解释任务中转移的交叉知识，并说明如何使用交叉知识通过使用增量学习进行更新。第二部分，增量多任务预测，阐述如何基于交叉知识生成解释，以及如何根据交叉知识和用户反馈预测推荐分数。

3.3 知识图谱在推荐排序的应用

KG可以通过给item用不同的属性进行链接，建立user-item之间interaction，将uesr-item graph和KG结合成一张大图，可以捕获item间的高阶联系。传统的推荐方法是将问题建模为一个监督学习任务，这种方式会忽略item之间的内在联系(例如凯美瑞和雅阁的竞品关系)，并且无法从user行为中获取协同信号。下面介绍两篇KG应用在推荐排序的论文。
Wang[9]等人设计了KGAT算法，首先利用GNN迭代对embedding进行传播、更新，从而能够在快速捕捉高阶联系；其次，在aggregation时使用attention机制，传播过程中学习到每个neighbor的weight，反应高阶联系的重要程度；最后，通过N阶传播更新得到user-item的N个隐式表示，不同layer表示不同阶数的连接信息。KGAT可以捕捉更丰富、不特定的高阶联系。

Zhang[20]等人提出RippleNet模型，其关键思想是兴趣传播：RippleNet将用户的历史兴趣作为KG中的种子集合(seed set)，然后沿着KG的连接向外扩展用户兴趣，形成用户在KG上的兴趣分布。RippleNet最大的优势在于它可以自动地挖掘从用户历史点击过的物品到候选物品的可能路径，不需要任何人工设计元路径或元图。

RippleNet将用户U和项目V作为输入，并输出用户U单击项目V的预测概率。对于用户U，将其历史兴趣V_{u}作为种子，在图中可以看到最初的起点是两个，之后不断向周围扩散。给定itemV和用户U的1跳ripple集合V_{u_{}^{1}}中的每个三元组\left( h_{i},r_{i},t_{i} \right)，通过比较V与三元组中的节点h_{i}和关系r_{i}分配相关概率。

在得到相关概率后，将V_{u_{}^{1}}中三元组的尾部乘以相应的相关概率进行加权求和，得到用户U的历史兴趣关于V的一阶响应，用户兴趣由V_{u}转移到o_{u}^{1}，可以计算得到o_{u}^{2}、o_{u}^{3}...o_{u}^{n}，进而计算得到U关于item V的特征可以被计算为融合他的所有阶数响应。

四、总结

综上，我们主要围绕推荐，介绍了图谱构建详细流程，对其中的困难和挑战做出了分析。同时也综述了很多重要的工作，以及给出了具体的解决方案，思路以及建议。最后介绍了包括知识图谱的应用，特别在推荐领域中冷起、可解释性、召回排序介绍了知识图谱的作用与使用。

引用：
[1] Kim S，Oh S G．Extracting and Applying Evaluation Criteria for Ontology Quality Assessment［J］．Library Hi Tech，2019.
[2] Protege: https://protegewiki.stanford.edu
[3] Ding S , Shang J , Wang S , et al. ERNIE-DOC: The Retrospective Long-Document Modeling Transformer[J]. 2020.
[4] DocBert，[1] Adhikari A , Ram A , Tang R , et al. DocBERT: BERT for Document Classification[J]. 2019.
[5] JanusGraph， https://docs.janusgraph.org/
[6] Sang L, Xu M, Qian S, et al. Knowledge graph enhanced neural collaborative filtering with residual recurrent network[J]. Neurocomputing, 2021, 454: 417-429.
[7] Du Y , Zhu X , Chen L , et al. MetaKG: Meta-learning on Knowledge Graph for Cold-start Recommendation[J]. arXiv e-prints, 2022.
[8] Chen Z , Wang X , Xie X , et al. Towards Explainable Conversational Recommendation[C]// Twenty-Ninth International Joint Conference on Artificial Intelligence and Seventeenth Pacific Rim International Conference on Artificial Intelligence {IJCAI-PRICAI-20. 2020.
[9] Wang X , He X , Cao Y , et al. KGAT: Knowledge Graph Attention Network for Recommendation[J]. ACM, 2019.
[10] Wang H , Zhang F , Wang J , et al. RippleNet: Propagating User Preferences on the Knowledge Graph for Recommender Systems[J]. ACM, 2018.

互联网上的人群为何越来越极端化？

Mon, 30 May 2022 08:15:52 CST

说理是正派社会的价值观，是文明的产物，学习说理既是教育又是自我启蒙的过程。" 理性 " 不仅指明晓事理、辨知是非，而且是在说服别人时，提供敞亮、清晰、恰当的理由，并倾听别人的合理之言。

主笔 | 张星云

在大学任教逾 30 年，社会学者徐贲负责教授各系科学生必修的说理写作课，教授的科目之一是公共说理的 " 论证与说服 "，后来他用这部分教学内容写了《明亮的对话：公共说理十八讲》，于 2014 年出版，是国内首部系统论述公共说理的著作。

徐贲现任美国加州圣玛利学院英文系教授，也是复旦大学社会科学高等研究院兼职教授，研究领域包括启蒙思想、公共生活、知识分子、权力与群众的关系等，出版有《在傻子和英雄之间：群众社会的两张面孔》《通往尊严的公共生活》《知识分子和公共政治》等著述。

左为徐贲教授（图 | 宁波读者）

在《明亮的对话：公共说理十八讲》一书中，他认为说理是一种思想能力，它要求人们尽可能全面、完整地把握讨论的问题，采取一种真实而客观的态度。理性话语的价值观是与他人平等、尊重、以说理相待的关系，并在这个基础上不羞辱他人、不欺骗他人、不歧视他人、不伤害他人、不使用任何暴力（包括语言暴力）对待他人。说理的目的不是要争辩出一个我是你非的结果，也不是一方一定要说服另一方放弃原来的主张或看法；说理是为了建立双方的信任，展示讨论的诚意，争取通过讨论对问题取得更全面的共同认识，达成某种妥协，在最大限度上争取双方可以认可或双赢的结果。

在他看来，说理是正派社会的价值观，是文明的产物，学习说理既是教育又是自我启蒙的过程。" 理性 " 不仅指明晓事理、辨知是非，而且是在说服别人时，提供敞亮、清晰、恰当的理由，并倾听别人的合理之言。这是一种公共理性，它离不开说理，也离不开适宜的社会和政治环境——社会必须拥有公民说理可以诉求、依据的普遍价值；政治必须尊重和保护他们自由、平等交流的公民权利。在这样的环境中，说理可以成为明亮的对话，一种因自由、理性而可持续的公共交谈。

如果身处长期缺乏公共说理教育的环境，徐贲认为，多数公众对峙就会停留在 " 吵架 " 的阶段。所谓 " 吵架 "，就是在最大限度上用语言暴力给对方造成伤害，以逻辑之外的手段去支持 " 吵架 "，如暴戾、武断、威胁、专横的用词，攻击对方人格、谩骂和侮辱，甚至压制对方发言。这种话语在思想上也势必会有排斥性、仇恨情绪和暴力倾向。吵架双方的彼此伤害越深，在 " 理 " 上取得共识、妥协的可能就越小。

《黑镜》剧照

今天，社交媒体几乎成为多数人唯一可以与人进行 " 讨论 " 的地方，但人们发现，互联网充斥着 " 键盘侠 "" 杠精 "" 喷子 " 们，表达情绪激烈，意见严重对立。 媒体事件往往引发网络上不同人群的热议、对抗和 " 互撕 "，网络暴力正在逐渐取代理性讨论和公共说理。

本刊记者此次专访徐贲教授，主要请他谈了这样几个问题：互联网环境下的公共说理、网络暴言、人群极化和网络公共空间的现状。

网络暴力首先是社会现象，而不只是网络现象

三联生活周刊：网络暴力并非一个崭新的话题，传统群众理论普遍认为网络暴力施暴者受教育水平低、反社会人格，但现实却是网暴事件影响的层面越来越大，越来越多的人参与其中。如何理解这一现象？参加网暴的群体构成是否有新的变化？

徐贲： 我认为，网络暴力首先是社会现象，而不只是网络现象。美国科技商人和谷歌前首席执行官埃里克 · 施密特（Eric E. Schmidt）曾说过：" 互联网是人类建造的第一件人类不理解的东西，是我们有史以来最大的无政府状态实验。" 事实上，尽管互联网在当今社会中发挥着巨大的信息驱动作用，是人们获取大量信息的门户，也是多种类型的社会交流的平台，其重要性无可替代，连害怕互联网的人也离不开互联网。但数字和通信技术的急剧进步也催化了虚假信息、极端主义和仇恨言论，并为其传播提供了方便，造成许多问题。鉴于社交媒体平台和搜索引擎算法的发展，这些问题变得更加错综复杂，它们根据用户的偏好策划和扩散内容，放大已有的信仰（回声效应），从而造成和激化群体分化。

互联网的首要问题—— " 假信息 " 和 " 假新闻 "，在俄乌冲突中我们又一次看到，这个问题变得多么严重。虚假信息在助长网上仇恨言论和宗派主义情绪方面起到极其恶劣的作用，在很大程度上增强了某些人的激进观点，并可能导致极端的语言和肢体暴力，有人在争辩时把对方耳朵咬伤的，更有人叫嚣要用核武器解决问题。因为仇恨，甚至不惜毁灭人类，这是多么可怕的邪恶！

《监视资本主义：智能陷阱》剧照

三联生活周刊：曾经人们将网络的匿名性视为言论自由和公共讨论的最大帮手，但如今人们却发现匿名性也成了网络暴力的最大帮凶。如何理解网络的匿名性？互联网是否需要它？社会舆论与网络暴力之间存在什么样的区别？

徐贲：在美国有许多这方面的研究，主要集中在网络匿名与网络霸凌的关系。其实，中国互联网的网络暴力和仇恨也是一种后妈眼皮子底下的儿童霸凌，幼稚、冲动、非理性，完全不像是思想成熟的成年人所为。

网络霸凌则是最为典型的网络暴力，也是最恶意、伤害意图最强烈的，并且有以多欺寡的特点，是一种暴众作恶。网络霸凌指通过电子手段进行的重复活动，目的是造成心理折磨，这是它与社会舆论完全不同的地方。网络霸凌可以有多种形式。它可以包括骚扰（侮辱或威胁）、散布谣言、举报、揭发和欺骗（获得一个人的信任，然后利用网络媒体传播他们的秘密）、排斥（把一个人排除在活动之外）、谩骂（妖魔化，非人化，扣上 " 汉奸 "" 走狗 " 的帽子）。这些活动可以通过电子邮件、即时通信、短信、社交或其他网站进行。

网络霸凌在几个关键方面与传统欺凌不同。最明显的是，它需要一定程度的技术专长，都是会玩电脑和手机的，有的甚至是高手。网络霸凌还为欺凌者提供了传统欺凌所不具备的匿名性。正因为如此，欺凌者无法看到受害者的反应，研究表明，他们作恶更大胆，悔意更少。网络霸凌是机会主义的，因为它在没有身体互动的情况下造成伤害，几乎没有计划，被发现的机会也很小。尽管如此，40% 到 50% 的网络霸凌受害者表示知道折磨他们的人是谁，在中国的比例更高。

网络霸凌可能比传统欺凌更普遍。传统的欺凌一般只限于学校，而网络霸凌可以随时随地发生，有更多潜在的受害者。由于缺乏法治规范，或者受到纵容唆使，这种情况更加严重。

《我们与恶的距离》剧照

极化，" 后真相 " 时代的特征

三联生活周刊：人们在谈网络暴力成因时说到了人群的极化问题，观点的极化、沟通的弱化，对待分歧时情绪表达取代公共讨论，导致对话困难，没有共存空间。这背后的原因是什么？

徐贲：" 极端化 " 或 " 沟通弱化 " 都是表象，其背后的实质是对真相价值的认知和判断。而不同的认知和价值观则又是由不同消息和信息形成的。 所以虚假信息成为一个至关重要的问题——准确地说，是那种让许多人乐意接受的虚假信息。他们最容易接受的是那种 " 我爱听 " 的虚假新闻的影响。这是今天 " 后真相 " 时代的一个特征，也是理解不同群体激烈对立的一个关键。

在后真相时代之前，诚信曾经被认为是一个全有或全无的命题。你要么是诚实的，要么是不诚实的。在后真相时代，这个概念已经变得模糊。人们较少考虑诚实和不诚实本身，而更多地考虑所谓的 " 用意 " 和 " 程度 "。道德是以滑动的尺度来判断的。有 " 良好 " 愿望的人觉得自己比别人更有理由谩骂、侮辱、人身攻击他人，在 " 有需要时 " 也更有理由掩盖或扭曲真相，甚至说谎。今天，我们的社会有越来越多的不诚实行为，这不只是与道德水平的下降有关，而且是与不再看重诚实和真实的社会环境有关。

从来就不缺少不择手段的人。只要有那些认为自己可以逃脱谎言的人，就会有骗子。问题是：什么情况下会助长说谎话而不负责任的侥幸心理？除了那些对真相和谎言不加区分的反社会者之外，我们大多数人在某些情况下更诚实，在其他情况下则不太诚实。纵容不诚实的环境在上升，而那些培养诚实的环境在下降。如果我们确实更多地撒谎——我们都相信我们的社会确实如此——那是因为当代生活的环境没有对不诚实进行足够的惩罚。

《社交网络》剧照

什么是人群的极化呢？我认为就是不同的人群在什么是真实、什么是基于真实的道德问题上严重对立，根本说不到一处去。这是一个 " 后真相 " 时代的现象，是无法清零的，我们只能与它共存。

2016 年，" 后真相 " 被《牛津词典》选为年度词汇，这个词是一个时代的象征，而不真的是指某个历史时期。也可以说，后真相是一个无边无际的虚拟信息时代，政治权力或意识形态威胁着事实和常识，打扮成 " 真相 " 或 " 真理 " 的代言人。正如《牛津词典》所解释的，后真相是一个经常与政治相关的形容词，" 它能够发挥营造客观事实和塑造公众舆论的作用，但这种作用不及诉诸个人情感和个人信仰 "。因此，后真相一方面把政治变成断言，另一方面又竭力试图诱惑人们的情感和直觉，而不是凭借理性的经验证据和真实信息，例如用煽情的民族主义取代理性的公民爱国主义，正如拉尔夫 · 凯斯（Ralph Keyes）在《后真相时代：当代生活里的不诚实和欺骗》（The Post-Truth Era：Dishonesty and Deception in Contemporary Life，2004，p.25）一书里所说，后真相时代创造了一个道德的昏暗地带，在那里，撒谎所附带的耻辱感消失了，谎言可以不受惩罚地被说出来，对一个人的声誉没有影响。这导致了谣言、假新闻和阴谋论的产生，它们可以在短时间内疯传，为虚假的现实提供动力，为宣传目的服务。

后真相让 " 撒谎 " 成为一种能耐，一种担任某些工作的能力和训练。这些骗子们擅长于制造令人愉悦和爱听的假信息和假新闻。例如有大学教授宣称，西方富人花钱坐飞机到迪拜，花 25 万美元打中国疫苗。这样的谎言之所以能够堂而皇之地登堂入室，是因为有的人爱听。

《虚构安娜》剧照

尽管自古以来一直都有骗子，但谎言通常是在犹豫不决，多少有一丝焦虑、一点内疚、一些羞耻的情况下说出来的，说的时候会不好意思，说不出口。现在，我们有些聪明人，已经想好了篡改真相的理由，这样他们就可以毫无愧疚地进行传播。" 后真相让我们可以在不认为自己不诚实的情况下传播谎言 "。" 极端化 " 或 " 无法沟通 " 并不是因为说话双方的遣词用字不同造成的，而是因为许多后真相的信息让有些人觉得舒服，而让另外一些人感到厌恶，要求他们通过沟通，在中间地带的某个地方握手、拥抱，事实上是没有这个可能的。

三联生活周刊：什么样的人会参与网络暴力？这种对陌生人的强烈的恶意从哪里来？参与网暴的人，可以从中得到什么心理或现实上的收益？

徐贲： 除了教育和环境文化的影响，人性中也有仇恨、残忍、恶毒的阴暗因素。不知道你有没有听说过这么一句话，" 仇恨是我们喝下的毒药，希望对方死去 "。把这句话里的 " 仇恨 " 换成 " 怨恨 " 或 " 愤怒 " 也是可以的。这句话可能是受到 5 世纪佛教僧侣觉音（Buddhaghosa）的著作的启发。在讨论愤怒时，他说：" 这样做，你就像一个想打别人的人，手里握着火炭或粪便，先烧伤或发臭的是你自己。"（Visuddhimagga，IX，23.）自然的人性中有仇恨，对非我族类有敌意，有暴力冲动，人类生来就是这副德性。进化心理学家解释说，人类进化出负面的情绪，是因为有利于我们祖先在恶劣环境中生存，物竞天择要求杀死我们的敌人，而不是爱我们的敌人。否则，我们死了，基因就无法传承下去。活下去，把基因传承下去，这也许就是仇恨最初的心理或现实收益吧。

不过，我们今天生活在一个与人类狩猎 - 采集者祖先完全不同的世界，人性中进化而来的负面情绪造成了我们今天看到的许多社会问题。卢梭和康德都曾强调，文明和道德就是限制人的某些自然天性。所以我们今天要倡导的不是野蛮的狼文化，而是文明的人文化。

《致命女人》剧照

三联生活周刊：你曾说网络暴言者会产生劣币逐良币的现象，说话声大的都是恶声恶气的，好好说话的人不再说话了，那我们应该如何对待网络暴言者？

徐贲：这看上去是网络时代的问题，其实是一个非常古老的问题，2000 多年前的所罗门智慧箴言里就已经谈到这个问题了，并有这样的教诲：" 鞭子是为打马，辔头是为勒驴；刑杖是为打愚昧人的背。不要照愚昧人的愚妄话回答他，恐怕你与他一样。要照愚昧人的愚妄话回答他，免得他自以为有智慧。"（箴言 26：3-5）这里有两个意思。 第一，对愚妄话不要与它一般见识，能躲就躲；第二，实在要回答，就不真不假地用高级黑的办法应对或敷衍一下，也许他能够意识到自己的愚蠢。箴言经常运用 " 反义平行 "（antithetical parallelism）的表达方式，这是一个很好的例子。

社交媒体上的冲突现在很普遍，但其实并不新鲜。在刚开始有网络论坛的时候，参与者之间的激烈交锋被称为 " 火焰战争 "（flame wars）。无论哪一方是 " 愚妄 " 的一方，双方对骂，绝无胜者。所以，中国人的智慧是道不同不相为谋，君子爱惜羽毛，远离小人，免得腥膻上身。双方争辩，评判对错是旁观者，但旁观者未必能 " 清 "，所以，美国幽默大师马克 · 吐温据说对此有一句智慧名言： " 永远不要和一个傻瓜争论，旁观者可能无法分辨。"这句话衍生出一些类似的说法，如 " 不要和一个傻瓜争论，否则听者会说你们是一对 "" 永远不要和一个傻瓜争论。但如果你必须这样做，最安全的方法是与自己进行辩论 "" 永远不要在公共场合与傻瓜争论，以免公众辨不清谁是傻瓜 "。

对网络暴力有无反制措施？

三联生活周刊：针对网络暴力，国际上近年有何新的研究成果和解释？

徐贲：国外有许多这方面的研究，前几天还看到一份马泰奥 · 希内利（Matteo Cinelli）等几位意大利社会学家刊发在 2021 年《科学报告》（Scientific Reports）上的一份研究报告《网上仇恨和错误信息的动态变化》（Dynamics of online hate and misinformation）。他们开宗明义就指出， 网上辩论的特点往往是用户之间的极端两极化和激烈讨论，究其原因是因为网上仇恨言论的存在。由于正变得越来越成问题，因此有必要制定适当的反制措施。研究者通过一个机器学习模型，对 YouTube 视频上超过 100 万条评论的语料库进行了仇恨言论检测。有意思的是，分析表明，没有证据表明存在 " 纯粹的仇恨者 "，也就是只发布仇恨性评论的活跃用户。此外，与回音室假说相一致，研究者们发现， 接受了扭曲信息的用户更容易对他们的对手使用不恰当的、暴力的或仇恨的语言。他们还发现，讨论的整体毒性随着讨论的长度而增加，从评论的数量和时间两方面来看，都是争论越长，语言暴力越升级。

他们的研究结果与著名的戈德温定律相一致，早在上世纪 90 年代，美国律师和作家迈克 · 戈德温（Mike Godwin）就提出了一个定理，今天被称为戈德温定律：" 随着网上讨论时间的延长，涉及纳粹或希特勒的比较的概率接近于 1。" 也就是说，如果在线讨论（无论主题或范围如何）进行了足够长的时间，则迟早会有人将某人或某物比作阿道夫 · 希特勒或他的行为。在西方，希特勒是 " 极恶 " 的象征，把谁说成是像希特勒是极度的上纲上线。不同的社会和不同的时期有不同的 " 极恶 " 象征，在今天的中国 " 极恶 " 的象征就是 " 汉奸 " 和 " 辱华 "。

《3 年 A 班：从现在起，大家都是人质》剧照

研究网络上的仇恨言论，当然会提出一些着眼于机构和网络平台问题的解决方案和对策。例如，为了防止和打击网上仇恨言论的传播，欧盟委员会与 Facebook、微软、Twitter、YouTube、Instagram、Snapchat、Dailymotion、Jeuxvideo.com 和 TikTok 达成了一项 " 打击网上非法仇恨言论的行为准则 "。仇恨除了助长网上辩论的毒性、仇恨言论，还可能产生严重的线下后果，如举报和告发。一些研究人员假设，在线仇恨和离线暴力之间存在因果关系。此外，有经验证据表明，在线仇恨可能诱发对线下反响的恐惧。然而，对仇恨言论的检测和对比是复杂的。仇恨言论的定义本身仍有模糊之处，学术界向相关的利益机构提供了他们的解释，包括社交媒体公司，如 Facebook、Twitter 和 YouTube。我希望微信也能参考一下国外的经验。

三联生活周刊：随着近年网络暴力事件影响越来越大，人们不禁开始怀念起 20 年前的中国互联网环境。曾经人们期待互联网能够成为一个新的公共空间，结果是攻击性的争论取代公共说理，为何会出现这种变化？

徐贲：也不能说完全没有新公共空间的作用，人们今天好歹还能得到一些真实消息，许多不都是来自互联网吗？但互联网确实不尽如人意，有许多恶劣的现象，问题在于我们如何看待这些恶劣的东西。如何看待恶在人世间的存在。这并不是今天互联网才有的问题，在希伯来神学里，这被称为 " 约伯问题 "：约伯百思不得其解，为什么上帝创造了这么一个美好的世界，而偏偏在这个世界里留下了这么多的恶。

同样，我们可以问，起于人类美好理念的互联网怎么会有这么多的肮脏和丑恶？要想清零这些肮脏和丑恶是不可能的，不愿意与它们共存，除非毁灭互联网。千百年来，对 " 约伯问题 " 有不同的解释，其中有一种最能被大多数人接受，那就是， 邪恶的存在为人类提供了在善和恶之间进行选择的可能，没有这样的选择人的灵魂便得不到塑造。当然，灵魂塑造的前提是人有自由意志。如今，互联网上良莠不齐，真假混杂，那不正好是我们学习善恶判断和是非分辨的一个机会吗？美国学校从初中到大学都开设针对互联网真假信息分辨的批判性思维课程，在这个基础上学习理性说理和互相尊重，这是在创造和维护良好公共空间的必要条件。

排版：踢踢 / 审核：小风

Fiddler 抓包 Android

Tue, 04 Jan 2022 19:34:26 CST

引言

准备

Fiddler
Android 模拟器
- 我这里是夜神模拟器，BlueStacks蓝叠模拟器没找到 WLAN 设置

Fiddler 基本配置

参考:

使用Fiddler+安卓模拟器对app抓包，包含https_f_yunsheng_t的专栏-CSDN博客_fiddler安卓模拟器抓包

Fiddler 配置代理, 允许远程的计算机连接

点击 OK，保存确定后， 需要重启 Fiddler 才能生效

Fiddler 配置 HTTPS

Fiddler启用https：Options中勾选"Decrypt HTTPS traffic"和"Ignore server certificate errors(unsafe)"，弹出的提示都选Yes

Android 模拟器配置

参考:

Fiddler 抓包逍遥安卓模拟器_架构师的成长之路的博客-CSDN博客_逍遥模拟器抓包

配置 Android 模拟器的网络代理

打开 设置, 选择 WLAN, 在显示已连接的WIFI上长按鼠标左键，选择 修改网络 ,

勾选 高级选项

选择 手动，填写本机 ip 以及端口 ( 8888 )

Fiddler 默认为 8888

查看本机端口, cmd 执行
1      
ipconfig      
图中 192.168.0.103 即为本机 ip,

我这里是 WiFi 连接，因此才是 Wireless LAN adapter WLAN, 如果是 网线连接 ，则是最上面的 以太网

PS: BlueStacks蓝叠模拟器居然没找到 WLAN 设置, 于是这里用夜神模拟器

应该说，到这里，就可以抓包 HTTP 了

针对 HTTPS 的请求，需要在Fiddler中启用 HTTPS，并把Fiddler的证书安装到模拟器中

配置 Fiddler 抓包模拟器的 HTTPS

模拟器安装来自 Fiddler 的 HTTPS 证书有两种方式:

Fiddler 导出证书，然后模拟器导入电脑文件, 然后安装证书

在模拟器中通过浏览器访问 Fiddler 的 http://ip:8888 ，下载安装证书

这里选择第二种方式，方便

如果打开后浏览器提示证书错误，点击 继续 即可

点击下载 Fiddler 证书，下载完成后，点击安装，这里给证书取名，随便取,

凭据用途有两个选项:

VPN和应用

WLAN

我这里只安装 VPN和应用 ，也可以两个都安装一遍

这里需要设置密码，设置好后即可

确定安装完毕；在 设置 - 个人 - 安全 - 信任的凭据 中， 用户 标签页可以看到安装的证书

点击证书，可以查看详情

接下来就可以打开Fiddler，在模拟器中打开浏览器测试下https的数据包是否可以正常抓到和解析了，以百度为例

打开模拟器默认带的浏览器，输入 m.baidu.com，百度现在默认使用https，随便搜索一下，查看刚才的包

成功

部分 APP 不走系统代理

参考:

部分APP无法代理抓包的原因及解决方法（flutter 抓包） - lulianqi15 - 博客园 - 重要参考: 原理, 详解
部分App无法使用系统代理抓包的原因及解决办法(Fiddler+Drony) - BYTEGOING - 博客园
如何让app不走系统代理？_阳光下的小树-CSDN博客_app不走代理 - 重要参考
app不走系统代理？如何抓包？_Zdelta-CSDN博客_app不走代理如何抓包 - 重要参考

现象

设置系统代理后，依然抓不到包 ( 没有相关请求的包 )，但是 app 却依旧正常返回数据，没有断网。

使用 Fiddler 或 Charles 这类代理抓包软件默认情况下无法抓取请求的，

但使用 Wireshark 这类网卡抓包软件可以看到这些 APP 的流量，

就表明这些 APP 使用的主要应用层协议仍然是 HTTP（HTTPS）

Fiddler 或 Charles 这类使用的代理的抓包软件与 Wireshark 是完全不同的（Wireshark 使用的网卡数据复制，只要是经过指定网卡都会被抓取），其只能对使用代理的应用层网络协议生效，比如常见的HTTP（https），Websocket 。

APP 不走系统代理原因/实现

网络请求代理设置 NO_PROXY

在网络请求的时候，通过OkHttp可以设置一个选项，代理的类型。我们在这里直接设置成Proxy.NO_PROXY。这样话即使android设置了代理，我们的app也不会走代理。

android系统设置的代理并不是强制对所有app生效的

app可以在网络请求类库中通过自定义代理设置，选择是否要走系统代理

public void run() {     
    Looper.prepare();     
    OkHttpClient okHttpClient = new OkHttpClient.Builder().     
        proxy(Proxy.NO_PROXY).//okhttp不设置代理     
        build();     
    Request request = new Request.Builder()     
        .url("http://www.baidu.com")     
        .build();     
    Response response = null;     
    try {     
        response = okHttpClient.newCall(request).execute();     
        Toast.makeText(this, Objects.requireNonNull(response.body()).string(), Toast.LENGTH_SHORT).show();     
    } catch (IOException e) {     
        e.printStackTrace();     
    }     
    Looper.loop();     
}

解决

TODO: 未完

Q&A

补充

Fiddler 默认端口

Fiddler 导出 HTTPS 证书

代理抓包原理

参考:

部分APP无法代理抓包的原因及解决方法（flutter 抓包） - lulianqi15 - 博客园

下面内容来自上面的参考内容，根据自己理解，修改简化

原理

为什么Fiddler 或 Charles对这些APP无效，我们有必要先了解代理抓包我原理

Fiddler 或 Charles 这类使用的代理的抓包软件与Wireshark是完全不同的（Wireshark 使用的网卡数据复制，只要是经过指定网卡都会被抓取），其只能对使用代理的应用层网络协议生效，比如常见的HTTP（https），Websocket 。

这里以HTTP为例简单说明下

客户端需要完成一次HTTP请求，通常需要先找到服务器，客户端会根据http请求中url的主机名（实际会使用host中的主角名）及其端口与目标主机建立tcp连接，建立连接后会将http报文发送给目标服务器（更多细节请参考https://tools.ietf.org/html/rfc7232）

接下来我来看下HTTP代理是如何运作的，我们启动Fiddler 或 Charles就是启动了一个HTTP代理服务器，这类工具会通知操作系统，“现在我在系统上创建了一个HTTP代理，IP为XXXXXX端口为XX。如果您使用的是linux您可以手动通知操作系统(export http_proxy=ip:port export https_proxy=$http_proxy),如果您使用的是手机等移动设备您可以在当前wifi设置处告诉系统你要使用http代理。现在我们已经告诉系统我们想要使用代理，这个时候运行在系统上的http客户端再去发送请求的时候，他就不会再去进行DNS解析，去连接目标服务器，而是直接连接系统告诉他代理所在的地址（代理的ip及端口，注意无论是http或https或其他支持代理的协议都会连接同一个端口）。然后代理服务器会与客户端建立连接，再然后代理服务器根据请求信息再去连接真正的服务器。

这里还有个细节正常在 没有代理 的情况下客户端向服务器发送的请求行里 只包含部分URI （实际上是没有方案，主机名及端口的）

有代理的情况下，应该是黄色标记的那样完整URL

如上图如果在没有代理的情况下，对 www.baidu.com/index.html 的请求的请求行实际上是 GET /index.html HTTP/1.1 其实并不是我们常见的完整uri。因为在原始的HTTP设计中没有考虑中间服务器（即代理）的情况，客户端在发送报文前已经知道服务器的地址并与之建立了连接，没有必要再发送方案，主机名及端口。不过代理出现后这种做法就会有问题了，客户端连接了代理服务器，而代理服务器却没有办法连接正确的服务器。因此客户端发送给代理的请求其实稍有不同，客户端会在请求行里使用完整的uri，这样代理服务器才能解析真实的服务器的地址。

现在我们的请求实际上都是通过代理服务器（Fiddler 或 Charles）发送出去的，所以代理抓包软件不仅知道http请求及响应的所有报文，甚至还可以随时修改请求及响应。

部分应用不能抓包的原因

代理抓包的关键就是需要HTTP客户端按照要求去连接代理服务器

一般情况下我们已经在系统层面上设置了代理，通常http客户端都是按要求去实现的，在进行http请求前会先检查系统代理，如果有设置代理，客户端会直接使用完整uri去连接代理服务器。不同的平台通常会实现自己的的http客户端的，虽然他们都按照协议要求实现了代理功能，但是并不一定在默认情况下会直接使用系统代理。

在现实中这种况下这种情况还不少，Flutter 就是这种情况，默认Flutter不会主动使用系统代理，需要单独设置。（当然个人认为这种策略也是有理由，虽然给测试及调试带来了不便不过也在一程度上提高了些许数据安全）

正是因为HTTP客户端没有使用我们设置的系统代理，他们自然也不会连接Fiddler 或 Charles创建的代理服务器，最终导致我们无法获取任何请求。

解决方案

不过既然我们已经知道了Fiddler 和 Charles不能抓包的具体原因，前面也提到了代理抓包的原理，那我们就总有办法解决。

前面说到了我们APP使用的HTTP客户端没有连接到代理服务器，导致我们的代理抓包软件无法正常抓包，那我们只要想办法让客户端重新连接到代理服务器就好了（当然这一切都是以不修改客户端软件APP为前提的）

方法1：控制DNS解析，通过修改dns的方式让客户端以为我们的代理服务器就是目标服务器。

优势：

操作方便，通过修改设备的hosts可以十分方便的首先

劣势：

需要为每个需要操作的域名提前添加host

在手机等手持设备上难以修改hosts（即对移动APP这类应用很难实现）

方法2：在网络设备上直接做流量转发，将指定终端设备上发往80及443端口的数据直接转发到代理服务器的目标端口上

优势：

可以针对连接到网络设备上的终端设备进行分别配置，而手机等终端设备不需要进行任何设备

劣势：

需要单独的硬件设备

方法3：使用VPN将终端设备的流量转发到代理服务器

优势：

使用VPN软件不用添加其他测试。

劣势：

终端上的VPN默认会直接对所有流量进行转发，要进行合理的配置可能需要额外的学习成本

TODO: 未复制完

参考

感谢帮助！

基于 Ubuntu 20.04 部署 1.23版K8S 集群

Sat, 15 Jan 2022 16:16:19 CST

从今天开始，我将开始连载《图解 K8S》入门系列文章

更多系列文章，可以微信搜索公众号：写点代码的明哥，回复 k8s 获取全系列教程

本篇是做为系列的第一篇文章，先来带大家一起搭建一个可用的 K8S 环境。

K8S 环境的搭建，是很多想学习 K8S 的人止于在入门之外的第一道门槛，不少人在这一道关上就被直接被劝退了。

为什么呢？主要有如下三点：

网络问题：K8S 是 Google 开发的，官方最新镜像都在墙外，安装时下载不了镜像
机器问题：K8S 运行的组件非常多，对于机器本身有要求，配置不能低，如果要搭建集群，还需要多台机器，是笔不小的开销。
运维问题：K8S 的部署安装和维护，涉及到不少 Linux 及网络相关的内容，需要有一定的运维能力

不过在如今，其实已经出现了非常多的 K8S 部署工具，有的是图形化界面安装，也有的甚至做到了一条命令安装。

这些工具，给新手提供了一个比较友好的部署解决方案，不过很遗憾的是，我大多没有用过，因为我认为这些工具隐藏了太多原生的 K8S 部署细节，比如安装了哪些组件，是怎么安装的？组件之间的依赖关系，网络是如何走的？

而这些细节，对于我们以后进行环境的维护、问题的排查会不小的帮助。

因此，我个人从一开始就不建议新手去使用那些太高级的部署工具。。

但也不能没有部署工具，所有的组件都手动安装，我想会逼疯很多新手。

因此，我这边选用官方推荐的 kubeadm 工具进行演示，带大家一起搭建个可用的 K8S 环境。

1. 环境说明

K8S 环境，可以分为单节点和多节点集群环境两种。

单节点的话，部署非常简单，对于一般的学习概念来说，也是够用了，除了一些需要多节点支持的功能，比如 DeamonSet ，比如调度策略验证等

而线上生产的环境，都应该是分布式的集群，只是这一套环境搭建下来需要多台的机器。

你可以在自己的电脑上创建几台虚拟机，本文我以我的 mac （16 G）为例，创建两台虚拟机，实际上带三台也没有问题，如此你是 windows ，请确保你的配置。

当然也可以选择去各大云厂商那里购买机器，个人感觉应该要不少钱，愿意投资的可以上。

由于后续肯定会用得上多节点，因此本篇只讲下多节点的集群搭建方法，如果你觉得自己当前想先试试水先学习一下一些基本的内容，可以在本文的评论区留言一下，我考虑剥离出一篇个单节点的 K8S 搭建方法，方法都大同小异。

2. 集群架构

K8S 中节点节点的角色，可以分为两种：

一种是控制节点，也即 Master 节点，主要运行控制平面的组件，如 kube-apiserver 等
一种是计算节点，也即 Worker 节点，主要运行业务上的组件，比如 web server 等

Master 节点是整个集群的大脑，一个集群只有一个 Master 节点肯定是不行的，通常来说，要至少三个，做下高可用。

但由于我们仅仅是学习之用，没有集群稳定安全性考虑，这里就不需要浪费资源去搞高可用。

因此，我的集群是一个 Master 节点，N 个 Worker 节点（下文中仅演示一个 worker 的部署，多个 worker 类似），管理网段是 172.20.20.0/24，ip 如图所示

3. 网络环境

集群的安装需要联网下载很多的镜像，因此在开始安装之前请保证你的所有节点都可以正常联网。

对于在云厂商购买的云主机来说，都有公网 ip，这个自不用担心。

可对于在本地电脑上创建的虚拟机做为 K8S 节点的朋友，可以跟着我一起操作。

我的个人电脑是最新款（2021）的 Macbook M1 Pro 内存仅有 16 G，现在我的电脑上已经安装好Mac 上的桌面虚拟化软件 Parallels Desktop，在 Parallels Desktop 的入口就可以下载 Ubuntu 20.04 ，请注意，这边下载的是桌面版的 Linux，本来我机器配置就不高，再使用桌面版的，实在太消耗资源了。

可以在这里下载服务器版的 Ubuntu：https://ubuntu.com/download/server/arm，会小很多，只有 1.1G。

下载完成后，可以自行安装，相信大多数人都知道如何操作，明哥这里就不会多费口舌，不懂的在留言区交流吧

等虚拟机安装完成后，别着急启动，可以先配置下网段。

如下图所示点 网络 -> 高级，再点打开 网络首选项

将桥接（Shared）的网络改为 172.20.20.0/24，也即 172.20.20.1-172.20.20.254

一旦你修改后，Paralles Desktop 就会感知，并修改本机上 bridge100 的 ip 地址为 172.20.20.0/24 里的 ip，这里分配的 ip 是 172.20.20.2，与虚拟机的网络在同一网段，如此一来，宿主机就能和虚拟机进行通信。

网络配置好后，正常启动虚拟机，可以看到虚拟机已经自动配置上 172.20.20.3 的 ip，这是怎么做到的呢？

原来在 netplan 的配置文件中 /etc/netplan/00-installer-config.yaml，配置了 enp0s5 启用 dhcp 获取 ip。

这种动态获取的 ip，会导致同一节点在不同时间、场景下获取到的 ip 可能是不一样的。

对于 K8S 集群环境来说，管理网络的 ip 应该固定的，否则会造成通信的混乱。

因此我们应该把规划好的 ip 地址写死到配置文件中，写好后，使用 netplan apply 使之生效

由于 ip 发生了变化，因此重启网络后，当前的 ssh 连接会断网,退出后，再次使用 172.20.20.200 就可以再次登陆，会发现 enp0s5 的 ip 已经按预期配置成 172.20.20.200 了。

尝试 ping 114.114.114.114 ，发现网络是不通的，这是为什么呢？

原来上面在 netplan 的配置文件中并没有指明网关地址，那网关地址是多少呢？

此时我们回想之间 bridge100 的 ip 是 172.20.20.2 ，为什么不是我们定义的 172.20.20.0/24 网段的第一个 ip 172.20.20.1 呢？

这是因为这个 ip 被 PD 拿去做网关了，因此我们只要往配置文件中加上网关再重新 netplan apply 即可

完整的配置文件如下

  # /etc/netplan/00-installer-config.yaml
network:
  ethernets:
    enp0s5:
      dhcp4: no
      addresses: [172.20.20.200/24]
      optional: true
      gateway4: 172.20.20.1
      nameservers:
        addresses: [114.114.114.114]
  version: 2

4. 基础环境

4.1 关闭 swapoff

在旧版的 k8s 中 kubelet 都要求关闭 swapoff ，但最新版的 kubelet 其实已经支持 swap ，因此这一步其实可以不做。

  iswbm@master:~sudo swapoff -a

# 修改/etc/fstab，注释掉swap那行，持久化生效
iswbm@master:~ sudo vim /etc/fstab

4.2 修改时区

修改一下时区，由原来的 UTC 变成了 CST，中间差了 8 个小时

  iswbm@master:~date
Sat 15 Jan 2022 02:22:44 AM UTC
iswbm@master:~ sudo timedatectl set-timezone Asia/Shanghai
iswbm@master:~$ date
Sat 15 Jan 2022 10:22:55 AM CST

修改后，如果想使得系统日志的时间戳也立即生效，由重启 rsyslog

  iswbm@master:~$ sudo systemctl restart rsyslog

4.3 设置内核参数

首先确认你的系统已经加载了 br_netfilter 模块，默认是没有该模块的，需要你先安装 bridge-utils

  sudo apt-get install -y bridge-utils

然后再使用 modprobe 加载一下， lsmod 就能看到 br_netfilter 模块，此时再确认一下内核参数 net.bridge.bridge-nf-call-iptables 是否为 1。

在Ubuntu 20.04 Server上，这个值就是1。如果你的系统上不一致，使用下面的命令来修改：

  cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sudo sysctl --system

5. 基础软件

本小节的步骤在 master 及 worker 执行

5.1 安装 Docker

目前的 Ubuntu 已经有提供 Docker 的安装包，直接安装即可

  # 安装 docker
iswbm@master:~sudo apt install docker.io

# 启动 docker 
iswbm@master:~ sudo systemctl start docker

# 开机自启
iswbm@master:~$ sudo systemctl enable docker

如果是旧版的 Ubuntu 还是建议按照官网(https://docs.docker.com/engine/install/ubuntu/)的操作去安装

但 ubuntu 20.04 源里提供的 Docker 版本还是比较新的，是 20.10.7，可以直接使用，我从 Docker 官网里看到的当前最新 Docker 版本是 20.10.12，只是差了几个小版本，区别不大。

  iswbm@master:~$ docker --version
Docker version 20.10.7, build 20.10.7-0ubuntu5~20.04.2

5.2 安装 kubeadm kubectl

以下操作在 master和 worker 节点上执行，由于谷歌的源和 repo 在国内的是无法访问的，因此这里需要切换为阿里源。

按顺序执行如下几条命令

  # 安装基础软件并设置源
iswbm@master:~sudo apt-get install -y ca-certificates curl software-properties-common apt-transport-https curl
iswbm@master:~ curl -s https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | sudo apt-key add -
iswbm@master:~sudo tee /etc/apt/sources.list.d/kubernetes.list <<EOF
deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main
EOF

# 刷新软件列表，然后直接安装
iswbm@master:~ sudo apt-get update
iswbm@master:~sudo apt-get install -y kubelet kubeadm kubectl

# 阻止自动更新(apt upgrade时忽略)。所以更新的时候先unhold，更新完再hold。
iswbm@master:~ sudo apt-mark hold kubelet kubeadm kubectl

6. 构建集群

6.1 部署 master

网上 90% 的文章，都是使用 kubeadm init 加各种参数实现的部署，只要一条命令即可实现，就像这样

  sudo kubeadm init --pod-network-cidr 172.16.0.0/16 \
    --image-repository registry.cn-hangzhou.aliyuncs.com/google_containers \
    --apiserver-advertise-address 172.20.20.200 \
    --apiserver-bind-port 6443

但这样的部署命令，在较新版本的 k8s （maybe 1.22 +）中是会部署失败的。

原因是 kubeadm 默认会将kubelet 的 cgroupDriver 字段设置为 systemd，

如果设置为 systemd ，kubelet 会启动不了。

经过我的摸索，kubeadm init 应该使用配置文件的方式进行部署

  iswbm@master:~$ sudo kubeadm init --config kubeadm-config.yaml

而如果你安装的是旧版的 k8s ，则不用使用上面的方式，直接

  sudo kubeadm init --pod-network-cidr 172.16.0.0/16 \
    --image-repository registry.cn-hangzhou.aliyuncs.com/google_containers \
    --apiserver-advertise-address 172.20.20.200 \
    --apiserver-bind-port 6443 \
    --token-ttl 0

关于 kubeadm 更多常用的参数及中文解释我整理如下

咱们的目的是学习，对版本没有要求，就直接上最新版，因此只能用这种方式安装

  iswbm@master:~$ sudo kubeadm init --config kubeadm-config.yaml

而这个 kubeadm-config.yaml 配置文件从哪里获取呢？我准备好一个，可以直接点这里进行下载 https://wwe.lanzout.com/iITg2yt0imd

kubeadm config print init-defaults 打印默认配置

执行完成后，会提醒你做三件事

第一件事：配置环境变量

以便你能正常使用 kubectl 进行集群的操作，对于常规用户用如下命令

  mkdir -p HOME/.kube
sudo cp -i /etc/kubernetes/admin.confHOME/.kube/config
sudo chown (id -u):(id -g) $HOME/.kube/config

对于 root 用户，执行如下命令

  export KUBECONFIG=/etc/kubernetes/admin.conf

第二件事：将节点加入集群

后面我们要将 worker 节点加入集群，就要执行这条命令

  sudo kubeadm join 172.20.20.200:6443 --token abcdef.0123456789abcdef \
    --discovery-token-ca-cert-hash sha256:4e4a7d0e848ae6c047d163fbe07f0e6975d71cc156d7705649241a59bbecaa04

这条命令是有有效期的，需要的时候，可以执行如下命令进行获取

  kubeadm token create --print-join-command

到此，你的集群已经安装好了，可以查看一下集群的基本情况

第三件事：部署网络插件

这个我在图中没有圈出来，但它也是非常重要的，我放到 6.3 部署 calico 这节里去做。

6.2 部署 worker

相比 master ，worker 的部署就简单许多了。

只要安装好了 docker、kubelet、kubeadm 软件，就可以执行前面的 join 命令直接加入集群

  sudo kubeadm join 172.20.20.200:6443 --token abcdef.0123456789abcdef \
    --discovery-token-ca-cert-hash sha256:4e4a7d0e848ae6c047d163fbe07f0e6975d71cc156d7705649241a59bbecaa04

完成之后，再到 master 上查看 node ，若可以看到 worker 说明成功将 worker 加入集群中

6.3 部署 Calico

上面其他我们已经部署好了 K8S 集群，但是由于还没有安装网络插件，因此整个集群实际上还是不能工作的，通过 kubectl get nodes 可以看到虽然已经有两个节点，但 Status 却都还是 NotReady 。

K8S 的网络插件有很多，常见的有 flannel、 calico、 cilium、 kube-ovn 等等。

更多支持的 CNI 可以在官方文档上找到列表：https://kubernetes.io/docs/concepts/cluster-administration/addons/

我大概数了一下，多达 16 个网络插件，太可怕了。

K8S 拥有如此多多的 CNI 网络插件，该如何做好CNI的技术选型，一个团队需要投入大量的精力进行调研。

Flannel 是由CoreOS开发的，K8S 最基础的网络插件，但是功能有限，一般仅供初学者学习使用，在生产中不推荐使用。

而其他的，Calico 是比较主流的选择（实际上我们公司使用的是 kube-ovn），因此我这里选择 Calico 进行安装

安装 Calico 只需要一条命令即可。

  kubectl apply -f https://docs.projectcalico.org/v3.21/manifests/calico.yaml

安装完成后，会创建出这几个 Pod

  iswbm@master:~$ kubectl get pod -A
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE
kube-system   calico-kube-controllers-85b5b5888d-dbptz   1/1     Running   0          3m33s
kube-system   calico-node-8jt69                          1/1     Running   0          3m33s
kube-system   calico-node-t69qb                          1/1     Running   0          3m33s

同时之前由于没有安装网络插件而失败的 coredns pod 也开始成功拉起了

网络 ok 后，再次确认下集群的环境

所有的 Pod 均已 Running
所有的 node 均已 Ready

7. 验收集群

关于 Pod 的概念，我将在后面慢慢介绍，现在你只要知道，Pod 是一个 K8S 最核心的资源对象，是最小的调度单位。

如果可以在 K8S 集群里，成功创建一个 Pod ，那就说明，你这个集群是健康的、可用的。

使用如下命令就可以创建一个最简单的 nginx pod

  kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml

simple.pod 的 yaml 简单内容如下

  apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

执行后，通过 kubectl get pod 可以观察到状态的变化

通过加 -o wide 可以查看 pod 的 ip，再使用 curl，就可以访问这个 nginx 服务

至此，我们创建了第一个 pod 的，集群搭建完成。

恭喜你，已经完成了你学习 K8S 最艰难的一步 — 环境搭建

8. 写在最后

本文虽然是在 mac 操作系统下进行演示，但机器对于搭建 K8S 集群本身并没有什么区别，最多也就虚拟机网络配置那里有所区别，但我相信这些对于正经的程序员来说，绝对不是什么难题。

本文完整复现了 K8S 集群的搭建过程，经历了 自己搭建 – > 问题排查解决 – > 素材收集整理 -> 撰写文章 ，全文经过多次修缮，前前后后一共花费了 6 个多小时的时间，才形成此文，可以达到让一个没有运维能力的纯新手也能无痛学习。

一篇文章的产出，需要经过如此长的时间，更新频率自然小很多，其实我也在考虑，之后要以一种怎样的风格来完成这个系列，是类似这样的万字长文呢？还是日更级别的，每天 5 分钟学习 K8S 呢？

对于我来说，我更倾向于前者，这样才能有条件把一个知识给讲透，而且能让你感受到我写这个系列的诚意。

但从读者的角度来看，应该是后者，更新频率太低，读者的脑子会断层，一个星期前的新知识，现在可能忘得差不多了。

你是怎么想的呢？欢迎你在评论区给我建议。

更多系列文章，可以微信搜索公众号：写点代码的明哥，回复 k8s 获取全系列教程

网络数字身份认证术

Sun, 02 Jan 2022 16:38:13 CST

这篇文章是《 HTTP API 认证授权术》的姊妹篇，在那篇文章中，主要介绍了 HTTP API 认证和授权技术中用到的 HTTP Basic, Digest Access, HMAC, OAuth, JWT 等各种方式，主要是 API 上用到的一些技术，这篇文章主要想说的是另一个话题——身份认证。也就是说，怎么确认这个数据就是这个人发出来的？

用户密码

要解决这个问题，我们先来看一个最简单的解——使用密码，通常来说，在网络上要证明一个人的身份的话，都需要这个人的一些私密而唯一的东西。比如，像密码这样的东西，很多地方，只要你提供了你的用户名+密码，就可以确定这个人是你（注明：关于密码管理，强密码设定，密码泄漏，密码破解以及密码哄骗不在这篇文章的话题中），也就是说，这个密码是非常私密的事，我们可以假设，这个事全世界只能有当事人一个人知道，所以，当当事人得供正确的密码，我们就可以认证这个人了。

为了加强密码的安全程度，一般会使用 2FA（Two-factor authentication）或 MFA（Multi-factor authentication），双因认证或多因认证，这需要用户提供一个唯一的可信设备，比如用户的手机，然后通过验证手机短信，或是像 Google Authenticator 这样的动态口令来完成。这样的安全级别已经算是比较高了。如果能够再加上经常性的变更密码，那么密全级别就更好了。

另外，一些公司还使用了生物密码来进行用户的身份验证，比如人脸识别。但是，我个人觉得人脸识别或是生物识别是比较糟糕的方式，因为：

目前能被验证的生物信息（如人脸和指纹）太容易被别人获得和伪造了。
这样东西不能被变更和吊销，密码可以被吊销和重置，人脸则不能。

密钥对和证书

密码可以解决身证认证的问题有很多问题，最重要的一个问题就是，你要把你的密码提供给对方，对方才能验证你的身份。你不可能把你的密码提供给全世界的人吧，这样的话，全世界的人都有你的密码了，那么任何人都能变成你了。所以，用户密码这个事只能存在于权威机构和普通用户之间，不能存在于普遍应用中。所以，这里需要使用更好的解决方案。

使用 ECC（ Elliptic-Curve Cryptography）椭圆曲线密码术，可以通过一个“密钥对”进行非对称加密。这种技术，在对信息进行加密和解密时，使用两个不同的密钥，其中一个用来做加密，另一个做解密。这样一来，我们就可以把其中一个密钥公布出去，称之为公钥，另一个密钥私密地保管好，称之为私钥。

比如，我用我的私钥加密信息，然后，我把这个私钥所配对的公钥发布给所有人，大家都用公钥解密信息，不用我的公钥你解密不了这个信息。这样一来，就可以保证这个信息是我发出来的，不但保证了信息安全，还完成了身份认证。

这样的现实案例一般用于网站，也就是用户得要知道我访问的这个网站是真实的，不是别人做的。因为 DNS 很容易被 hack，你连上一个不可信的网络，这个网络里的 DNS 把这个网站的 IP 地址解析成什么就是什么了。但是有了这个加密的机制后，网站把自己的信息加密后连同公钥给到访问者，访问解密后就知道是不是这个网站了。

但是，这里还是会有一个很严重的问题，那就是中间人攻击。如下图所示：

中间人 Chad 把伪装成 Bob 向 Alice 要信息，然后，再伪装成 Alice 对 Bob 说，这就是 Alice 的公钥，于是 Bob 也无法验证是不是 Alice 的公钥，因为公钥里就是一堆乱七八糟的数据，我们完全不能分辨哪个公钥属于 Alice 的。试想，如果我们收到声称属于银行的密钥。我们怎么知道它确实属于你的银行？

这里的答案就是 使用数字证书。证书跟我们的身份证非常类似，其需要一个可信机构来颁发和验证的。这个证书机构 CA（Certificate Authority）是一个是大家都相信的权威机构，他用他的人品保证（当然一般会被严格管理和审计），CA 机构同样使用这样的非对称加密的技术来完成颁发和验证的事。下图展示了这一过程。

说明一下上面这个图：

为了解决公钥认证的问题的，我们需要一个权威的CA 机构。
Alice 把自己的信息（姓名、组织，地址，电邮，网址等）和自己的公钥打包成一个 CSR 的文件，发给 CA 机构，
CA 机构会来找 Alice 做物理世界的认证，如果通过后，就会用自己的机构私钥，把CSR 变成一个签名证书。
Bob 同学拿到 Alice 的证书，用 CA 机构的公钥解密后，得到 Alice 的公钥
后面就可以签证信息是否来自 Alice 了。

是的，这个过程就是在“套娃”，这种证书机构还可以给下级的证书机构发证，于是就会一层套一层地，形成一个证书链，顶层的叫根证书，你得绝对信任之。对于验证证书真实性的客户端，它需要能够验证链中所有 CA 的签名，这意味着客户端需要访问链中所有 CA 的证书。

证书生成过程演示

并不是所有的场景都需要向这些大型的 CA 机构申请公钥证书，在任何一个企业，组织或是团体内都可以自己形这样的“小王国”，也就是说，你可以自行生成这样的证书，只需要你自己保证自己的生成证书的私钥的安全，以及不需要扩散到整个互联网。下面，我们用 openssl命令来演示这个过程。

1）生成 CA 的证书（公钥） ca.crt 和私钥 ca.key

openssl req -newkey rsa:2048 \
    -new -nodes -x509 \
    -days 365 \
    -out ca.crt \
    -keyout ca.key \
    -subj "/C=SO/ST=Earth/L=Mountain/O=CoolShell/OU=HQ/CN=localhost"

2) 生成 alice 的私钥

openssl genrsa -out alice.key 2048

3）生成 Alice 的 CSR – Certificate Signing Request

openssl req -new -key alice.key 365 -out alice.csr \
    -subj "/C=CN/ST=Beijing/L=Haidian/O=CoolShell/OU=Test/CN=localhost.alice"

4）使用 CA 给 Alice 签名证书

openssl x509  -req -in alice.csr \
    -extfile <(printf "subjectAltName=DNS:localhost.alice") \ 
    -CA ca.crt -CAkey ca.key  \
    -days 365 -sha256 -CAcreateserial \
    -out alice.crt

双向认证 mTLS

上面，我们说的基本上都是单向认证，大量的场景都是确保用户方访问的是真正的服务方，如：银行，电商网站，等。这样可以保证用户不会被钓鱼网站或是中间人攻击。但是，很多时候，我们也是需要双向认证的。下面是一个典型的场景——微信支付和商户间交互

用户到商家那边买东西，商家要求用户进行支付。
用户选择了微信支付，于是，界面从商户侧切到了微信侧
微信那边支付完成后，商户这边收到微信那边支付完成的通知，于是开始发货。

这个过程中有件事非常重要——就是微信通知商户支付完成的时候。

微信得确保通知到的就是用户所支付商户，而不是别个。
商户也得要能确认，来通知我的就是微信，不是别人。

一般来说，微信会给商户一个 AppID和一个 AppSerct，用这个来确保是我认证过的商户来调用我，然后，需要商户在自己的系统里填一个回调的 URL，并通过平台设置的 key来做 MD5/HMAC的签名来确保是官方的回调。这都是在《 HTTP API 认证授权术》中提到过的技术，是相对传统的技术。

如今， mTLS是确保云原生应用程序中服务之间的通信安全的首选协议。也就是双向认证。

传统的 TLS 认证过程是：

客户端连接到服务器
服务器提供其 TLS 证书
客户端验证服务器的证书
客户端和服务器通过加密的 TLS 连接交换信息

在 mTLS 中，客户端和服务器都有一个证书，双方都使用他们的公钥/私钥对进行身份验证。与常规 TLS 相比，mTLS 中有额外的步骤来验证双方（以 粗体显示的额外步骤）：

客户端连接到服务器
服务器提供其 TLS 证书
客户端验证服务器的证书
客户端出示其 TLS 证书
服务器验证客户端的证书
服务器授予访问权限
客户端和服务器通过加密的 TLS 连接交换信息

mTLS 需要“根”TLS 证书；这我们自己来完成证书颁发机构的职责。授权客户端和服务器使用的证书必须与此根证书相对应。根证书是自签名的，这意味着我们需要自己创建它。（注：此方法不适用于公共 Internet 上的单向 TLS，因为外部证书颁发机构必须颁发这些证书）

那么，为什么整个互联网上都用了 TLS 了，为什么不升级一下使用 mTLS？这里有两方面的原因：

公共互联网上要解决的问题是：A) 确保用户访问到的是正确的网站，而不是钓鱼网站。B）网站传输的内容是安全和私密且不会被篡改的。
将 TLS 证书分发到所有最终用户设备将非常困难。生成、管理和验证为此所需的数十亿个证书几乎是不可能的任务。

在较小的范围内，mTLS 对于单个组织非常有用且非常实用，尤其是当这些组织采用零信任方法来确保网络安全时。由于默认情况下零信任方法不信任任何用户、设备或请求，因此组织必须能够在每次尝试访问网络中的任何点时对每个用户、设备和请求进行身份验证。mTLS 通过对用户进行身份验证和设备验证来帮助实现这一目标。

关于 mTLS，这里有一个我用 Golang 写的示例 – https://github.com/haoel/mTLS，大家可以参考一下。

P.S. 本文图版中的卡司来自安全圈的标准 Cast，参看 Alice and Bob。

（全文完）

关注CoolShell微信公众账号和微信小程序

（转载本站文章请注明作者和出处酷壳 – CoolShell ，请勿用于任何商业用途）

——=== 访问酷壳404页面寻找遗失儿童。 ===——

The post 网络数字身份认证术 first appeared on 酷壳 - CoolShell.

Knower – 能自动识别、提炼、检索、聚合的网络书签、文档收藏工具

Sun, 07 Mar 2021 16:06:59 CST

Knower 是一款在线网页、文档、笔记收藏工具，拥有 Chrome、Edge、Firefox 扩展，不同于传统收藏工具，用 Knower，无需手动输入分类、标签，它会自动帮你解决这个问题。@ Appinn

来自发现频道，介绍非常简单： 你的知识助手，收藏、管理你的知识。以至于青小蛙在第一次看到的时候错过了。其实 Knower 在发现频道的介绍并不简单，可以说非常详细，但对青小蛙来说最重要的“ 一句简介”太简单了。

Knower

Knower 是一个在线服务，拥有 Chrome、Edge、Firefox 扩展，主要用来收藏网页、文档（Office、PDF 文档等）、笔记，最重要的功能是可以自动识别、分类、检索、聚合，让你 只需要做收藏一件事，其它都交给 Knower。

一个按钮、一个功能

Knower 的浏览器扩展只有一个按钮、一个功能，点击一下就能将当前标签页保存到 Knower 中，整个保存过程就结束了。

Knower 会自动提炼网页关键词，并自动设置一个标签，虽然目前看来标签的命名还有很大的提升，但关键词提炼已经相当不错了：

全文检索

被收藏进 Knower 的内容，支持全文检索，就算有大量的收藏，只要记得一两个关键词，都会非常容易搜索到。

而每一个收藏，都有一个实体功能。

实体功能

实体这个名字比较不好理解，点击后就会出现四个框框，里面是从内容冲提炼出来的高频词、人物、地名、机构。

青小蛙测试了几个，还算准确，尤其一些人物，可以非常完整的提炼出内容中出现的人名。

标记、批注

对于懒人青小蛙来说，这就可以了，但对于勤人青老蛙来说，添加收藏之后才是开始。

Knower 可以自定义每一个收藏的标签，也可以对内容进行标记、批注、搜索、翻译：

以上这些功能，对于文档同样适用，你可以自己将 PDF、Docs 上传至 Knower 中，然后就能获得自动的标签、高频词、人物等信息，同样也能批注、标记。

你以为这就完了？

Knower 还有个很酷的视图树功能，一键生成一个挺酷的思维导图：

基本上这样就完了，另外还拥有多种配色、导出数据等功能，虽然页面设计算不上优美，不过功能点真是不错。这大概是青小蛙理想中网络书签的样子。

感兴趣的同学可以前往官网使用，或前往发现频道和开发者聊聊。Knower 目前免费。

科研人员发现隐私泄露无孔不入，扫地机器人已成新型“窃听器”？

Sat, 28 Nov 2020 19:20:00 CST

图片来源@视觉中国

文丨学术头条

在当今的信息互联网时代，个人隐私信息已不再属于个人。互联网在为我们提供便利的同时，也给我们的生活和工作带来了一定的风险。

事实证明，越来越多的不法分子利用计算机技术和各类漏洞窃取个人、机构团体甚至政府部门的重要信息，无良商家也会通过倒卖用户信息来牟取暴利。更令人恐慌的是，不仅仅是我们在虚拟网络上的个人信息被泄露，我们的实际生活也遭到了“恶意”入侵，比如难以发现的针孔摄像头和常用的家居物品，他们无一不在“监视”着我们的生活。

而现在，“窃听”方式似乎变得更加难以防备，而且比你想象得更加容易。 可能一个扫地机器人和一个垃圾桶，就可以使你的个人隐私暴露无遗。

近日，由新加坡国立大学（NUS）、美国马里兰大学学院市分校（UMD）研究人员组成的科研团队，成功远程入侵了一台家用扫地机器人，使其充当窃听器来“窃听”屋内的私人信息。这项研究表明，即使没有安装传统的“窃听器”，不法分子也可以操纵家居设备来窃取他人信息。

相关论文也以“Spying with Your Robot Vacuum Cleaner: Eavesdropping via Lidar Sensors”为题在线发表。

吸尘器？窃听器！

在过去几年中，利用智能传感器实现自主运行的扫地机器人已经越来越广泛地被用于个人家庭中。

工作时，配备有激光雷达导航系统的扫地机器人，会使用脉冲激光来测量与附近物体间的距离，它会向房间四周发出激光束，并感应反射光束，然后利用反射信号绘制出整个房间的地图，从而避免在房屋内发生不必要的碰撞。

此前已有隐私专家建议，扫地机器人制作的地图（通常存储在云平台中）会构成潜在的隐私漏洞，使广告商可以借此判断房屋大小（这可能暗示收入水平）以及其他与生活方式相关的信息。

而在这项研究中，论文作者之一、马里兰大学计算机科学系助理教授 Nirupam Roy 及其合作者则提出了另一种猜想：

扫地机器人中的激光雷达系统，是否有可能成为不法分子在个人家中或企业中的窃听设备，并带来潜在的安全风险呢？

于是，他们创造了一种名为“LidarPhone”的监听系统，并通过攻击一款小米 Roborock 扫地机器人进行了测试。此次攻击的核心思想是：“黑”进扫地机器人后远程访问云平台，获取激光雷达数据并分析收集到的原始信号。研究人员表示，这将使攻击者可以窃听私人对话，从而泄露信用卡信息或可能用于威胁勒索的信息。

图 | 通过扫地机器人捕捉家中物品（比如垃圾桶）反射的声音信号进行窃听（来源：Sriram Sami）

那么，问题来了，吸尘器中并没有声音传感器，LidarPhone 是如何“听”到声音的？

我们知道，声波会导致物体振动，而这些振动又会导致从物体反射回来的激光束发生变化。 因此，攻击者就有可能由吸尘器接收到的激光信号及其变化，分析出导致这种变化的声波信号，进行成功窃听。

图 | 深度学习算法可以解释由扫地机器人捕捉到的分散声波，进而识别数字和音乐序列（来源：Sriram Sami）

自 20 世纪 40 年代以来就一直用于间谍活动的激光麦克风就是一个典型的例子。但是，激光麦克风依赖于在非常光滑的表面（例如玻璃窗）上反射的目标激光束，也就是说，一旦激光束接触到的物体表面不够光滑，最终就难以转换成声波。

在此次实验中，研究人员在小米 Roborock 扫地机器人上使用 LidarPhone 系统进行了概念验证（PoC）。首先，他们对扫地机器人的基于 ARM Cortex-M 的固件进行了反向工程；然后，利用 Dustcloud 软件堆栈（该设备是吸尘器的代理服务器或终结点服务器）中的问题，获得了对系统的 root 访问权限。

研究人员表示：“这类扫地机器人通常与小米云平台连接，以实现其标准操作和数据交换。我们使用设备上的 Valetudo 软件堆栈覆盖此接口，并通过本地网络控制机器人。”

然后，研究人员收集了两个语音序列——计算机扬声器和电视音箱播放的音乐，在记录的 19 个小时内总计发出了 30000 多个语音序列。 实验结果显示，LidarPhone 的数字和声音分类的平均准确度分别达到了约 91％和 90%。

图 | LidarPhone 对数字声源、性别、说话人的辨别准确度

利用 LidarPhone，研究人员可以监测到家庭中出现的不同声音——从地毯到垃圾桶，再到电视上流行的新闻频道（如 FOX、CNN 和 PBS）的各种介绍性音乐背景，甚至可以预测说话者的性别。

仍需多加提防

尽管如此，LidarPhone 也并非完美，其在攻击过程中也遇到了各种各样的问题。

比如，与扫地机器人之间的距离和各种噪音的音量，都会影响整体效果，背景噪声水平和光照条件也会影响整体攻击效果。

研究人员表示，可以通过降低激光雷达信号的信噪比（SNR）来“阻止”攻击或降低攻击风险：以低于特定旋转速率的速度传输，没有选择在软件中覆盖此功能。

此外，手机也可能会成为攻击者的作案工具。“虽然我们以吸尘器为例研究激光雷达系统，但我们的发现可能会扩展到许多其他有源光传感器，包括智能手机的飞行时间（ToF）传感器。” ToF 相机使用红外线感应物体并将反射光线返至相机，光线离开并返回设备所需的时间（即飞行时间）使相机能够感应到深度，从而创建出整个空间的 3D 地图。

另一个好消息是，这种攻击操作起来相对复杂，要求攻击者必须已经破坏了设备本身。 此外，攻击者必须连接到被攻击者的本地网络上才能发起攻击。

但无论如何，这类攻击是一个重要的提醒：家中越来越普及的智能感应设备，很可能为私人对话与个人信息窃听提供了许多机会。

参考资料：

https://www.cs.umd.edu/~nirupam/images/2_publication/papers/LidarPhone_SenSys20_nirupam.pdf

https://techxplore.com/news/2020-11-hacked-robotic-vacuum-cleaner-speech.html

更多精彩内容，关注钛媒体微信号（ID：taimeiti），或者下载钛媒体App

浅谈Forrester零信任架构评估的7个技术维度

Mon, 08 Jun 2020 14:10:04 CST

零信任是由Forrester Research的分析师John Kindervag在2009开发，并在2010年正式提出的。在过去的10年间，随着云计算、移动互联等技术发展以及全球范围内部威胁的不断涌现，零信任越来越为产业界所接受。

Google从2011年开始探索和实践零信任，并在2014年发表了BeyondCorp系列研究论文，成为零信任大规模实施的典范。

Gartner在2017年发布的其自适应安全3.0的版本CARTA框架，持续自适应的风险与信任评估的思想与零信任内涵和逻辑高度一致，进一步推进了产业界对零信任投入和研究。

NIST在2019和2020也连续发表了SP800-207零信任架构草案第一和第二版本，探讨零信任体系结构（ZTA）网络策略的核心逻辑组件。从2018开始，Forrester 开始发布零信任扩展生态系统ZTX研究报告，探索零信任架构在企业中的应用，系统性对零信任厂商的能力进行评估。

Forrester对厂商的评估包括多个维度的一系列的指标，例如收入，厂商的零信任的战略和对零信任的宣传，以及API集成能力等。本文主要关注的是Forrester在零信任评估中所涉及的7个主要技术维度，即

网络安全

设备安全

人员/身份安全

工作负载/应用安全

数据安全

可见性和分析

自动化和编排

本文基于2019年第四季度Forrester Wave™报告中的评估数据做一个简单分析。在报告中，7个技术维度，每个都分别打分，有不同的权重，每项得分有了1、3、5三个不同的值，其中1分最低，5分是最高分，本文将从这7个技术维度逐一展开说明。

一、网络安全

网络安全能力是零信任最初关注的核心能力，在ZTX模型中，主要关注的是如何实现网络隔离和分段，以及最终安全性的原理是什么。在这个维度中，得到最高分5分的厂商最多，达到了7家，这也与零信任最初的切入点吻合。这7家分别是Check Point、Cisco、Palo Alto Networks、Symantec、Forcepoint、Okta、Cyxtera Technologies。简单来说，零信任的网络安全能力可以理解为是支持微分段和微边界的NGFW产品定义的能力，产品形态可以是硬件形态也可以是虚拟化设备或其它可以提供同等能力的软件形态。

零信任网络安全的关键架构组件包括网络分段网关，微内核和微边界。网络分段网关作为网络的核心，集成了各个独立安全设备的功能和特点，从防火墙、IPS、WAF、NAC、VPN等。它支持高速多个10GB接口，可以高性能的检查所有流量。通过微内核和微边界，连接到“网络分段网关”的每个接口都有自己的交换区。每个交换区都有一个微内核和microperiodier（MCAP），具有相同的安全信任级别。这实际上将网络划分为并行、安全的网段，这些网段可以都单独扩展，以满足特定的法律合规性要求或管理需求。下面以几个典型产品为例简单说明。

Check Point的零信任网关可以在整个IT基础架构以及私有/公共云和公司网络环境中对网络进行微分段，它可以全面控制所有东西向流量，可以准确地检查和阻止网段之间的未授权流量，同时仅允许绝对最小的合法流量。

Palo Alto的零信任网关主要是其下一代防火墙，它是单通道软件架构来实现这一目标，具有独立的控制和数据平面，加上特定功能的并行处理硬件引擎来处理流量。

二、设备安全

零信任安全架构中的设备安全的能力需要持续监控网络上的所有设备。除了“看到”传统服务器、PC、笔记本电脑和智能手机之外，还包括在连接到网络的物联网和IOT设备、外设、网络基础设施组件和恶意的设备，虚拟机、工作负载等软设备形态。根据预先收集的有关设备类型设备允许、拒绝或限制对内部网络资源的访问，从而强制让设备的行为符合执行预期。同时还可以根据已建立的策略发出通知并启动设备修复。连接后，平台持续监视设备，以确保设备行为不会偏离策略。关键点在于对设备的持续发现和安全性检查的能力，这一点有别于传统的NAC设备一次检查永久信任的模式。

设备安全相对比较容易理解，Forrester Wave™评分中得到5分有4家企业，分别是Forescout、Cisco、Proofpoint、MobileIron。下面以Forescout为例简单说明。

Forescout是传统NAC的标志性厂商，它通过对SecurityMatters的收购，将设备安全的能力扩展到了IOT环境中。它的零信任设备安全实践很有代表意义。它可以全面了解企业内所有的IP连接设备，包括数据中心、云和IOT设备，并对设备安全性和配置状态的深入检查，以确定设备的风险态势。Forescout策略引擎根据设备的风险态势，将企业的安全策略和分段策略转换为单个实施产品应用的规则。

三、人员/身份安全

人员/身份安全是关注于使用网络和业务基础架构的人员的安全，减少这些合法用户身份所带来和造成的威胁。攻击者获取敏感数据的最简单方法之一就是凭证盗用。一旦进入目标网络，攻击者一般都会扩大攻击范围，并在网络中横向移动，寻找特权帐户和凭据，帮助他们访问组织最关键的基础设施和敏感数据。人员安全主要是身份和访问管理（IAM），大多数应用程序和服务交互都与角色和权限（用户、组和服务帐户）有某种关联，因此零信任策略对象的重要主体是身份和账号。

这应该是零信任中最容易被理解的一个维度了，在Forrester Wave™评分中得到5分有6家，分别是Akamai、Cisco、Google、Proofpoint、Okta、MobileIron。下面以Okta为例简单说明

Okta的身份认证逻辑分为三个阶段，1、实现统一身份访问管理。对访问管理系统下进行整合，通过单点登录（SSO）完成的第一阶段整合。2、实现上下文访问管理。通过收集关于用户上下文信息（即他们是谁？他们是一个有风险的用户群吗？），应用程序上下文（即用户试图访问的应用程序）、设备上下文、位置和网络等信息进行综合判断，对于可能存在风险用户配合多因子身份认证进行二次验证。3、自适应的身份鉴别。这是与传统上身份验证区别最大的地方，不再是一次验证通过就获得这次会话的完全信任，而是通过自适应的、基于风险的评估来识别潜在威胁，在用户体验的整个过程中持续进行。这是第2阶段的上下文响应中添加了一个智能的、基于风险的引擎，并允许基于这些上下文信号的风险评分来确定特定身份验证事件的风险，并基于这种判断提示进行附加的身份验证。这里的关键是要避免因为误报而导致对用户正常操作的干扰。

四、工作负载/应用安全

过去10多年伴随着云计算的蓬勃发展，工作负载安全的重要性日趋凸显，无论是私有云还是公共云中的工作负载，例如应用程序、虚拟机、容器、Serverless等都容易受到攻击。要实现基于零信任的工作负载安全，首先要弄清楚组织内部的工作负载资产情况，构建工作负载、安全组、实例和防火墙的实时拓扑，通过自适应访问策略，根据工作负载的任何变化自动调整，这些策略是强制执行，可以自动发现并纠正错误的工作负载系统配置，同时，可以通过调用IPS、恶意软件检测等安全引擎实现威胁防护。

在产品和能力提供上，零信任的工作负载安全通过提供基于身份的代理网关，降低了应用和工作负载的暴露面，无论应用和工作负载在什么地方，未经授权的人员和设备都是看不见这些资源的。同时可以配合其它的传统安全手段，强化应用和工作负载的安全性。

应用和工作负载的零信任，在Forrester Wave™评分中得到5分有3家，分别是Akamai、Google、Cyxtera 。他们都是SDP的实践者，下面以Akamai为例简单说明。

Akamai是CDN的发明者和服务提供商，它原有的24万台服务器的代理平台也是它转型到以SDP提供零信任服务的重要因素。Akamai的IAP模型与Google的Beyond Corp模式相似。它通过企业应用程序访问（EAA）云产品提供工作负载保护的服务。

EAA允许企业通过Internet（无论是托管在云中还是在数据中心中）提供对私有应用程序的访问，并执行最小特权和零信任的原则。只有经过身份验证的用户和设备才能访问他们有权访问的内部应用程序，并且不需要打开或维护入站防火墙端口。EAA将数据路径保护，单点登录，身份访问，应用程序安全以及管理可见性和控制功能集成到由Akamai智能平台支持的基于云的单个服务中。它最终可以保护私有企业应用程序，从而最大程度地减少了攻击面并使企业基础结构和数据对公众不可见。它是基于云的服务，并从一个单一窗口访问基于Web的应用程序，框架内也可以与传统的安全服务集成，例如高级威胁防护，Web应用程序防火墙等。

五、数据安全

零信任架构的核心是回归本源，聚焦于保护数据的安全，构建以数据为中心的安全。从数据安全着手建立零信任体系相对容易落地，也更容易以最好的ROI产生效果。无论数据处于在终端、应用服务器、数据库、SaaS应用程序之中，无论在组织网络内部或外部，无论数据是处于流动状态还是使用状态，都需要通过一定的技术手段，防止数据的泄露。Forrester Wave™在评估时主要关注如何实现数据的分类，隔离，加密和控制等安全措施。

虽然零信任架构的实践目前以网络微隔离、增强IAM（IDAAS等）、SDP这些形式为主，但本质上这些零信任的实践还是围绕是以实现数据安全为核心。在Forrester Wave™7个技术维度的权重中，数据安全权重17%也是最高的（网络安全权重12%，身份安全权重15%）。但是在数据安全这个维度中拿到最高分5分的企业却只有一家，远小于网络安全等其它维度，这是一个很有意思的现象。

零信任数据安全的保护应用于数据本身，与数据的位置无关。为了有效，敏感信息应在进入组织的IT生态系统后立即被自动标识出来，并应通过在整个数据生命周期中持续的保护。

典型实现包括安装在每个终端上的部署代理，在云和网络上部署探针设备，这些代理和探针由一个集中管理控制台控制，管理员在该控制台中为每个终端代理、每个用户、每个探针定义数据类型和采用适当的保护形式。作为以数据为中心的网络设计，该设计本质是在特定数据或资产周围放置了微边界，以便可以执行更细粒度的规则。这个一般分为4个步骤：

1、识别敏感数据：这看似简单，但要落地，远比想象的更具挑战性。保护看不见的数据是不可能的。识别数据后，有必要使数据分类有用，而简化是关键。

2、映射敏感数据的数据流：了解数据如何在网络内、跨网络以及在用户和资源之间流动。这里的数据既包括结构化半结构化数据，也包括非结构化的文档数据，数据流的形成是一个必要而艰难的过程。

3、创建自动化规则库：确定访问控制的规则，形成数据安全策略。要定义这些规则，必须了解哪些用户、应用和数据之间的关系。

4、持续监控持续调整：通过持续监控，并根据用户的行为和风险，自适应的调整用户的安全策略，采用不同的响应手段。

常见数据安全防护的技术包括文档加密、数据库加密、磁盘加密、数据脱敏、DLP(数据防泄漏)、数据库审计、虚拟沙箱、UEBA、CASB等。与SDP、IDAAS、微隔离等相比，这些看似不是新的名词和定义，理论上应该有更好的表现，但Forrester Wave™选的14家厂商中只有ForcePoint拿到了最高分5分，数据安全整体得分是7个技术维度中最低的，甚至长期在GartnerDLP魔力象限领导者的Symantec也只被评估为3分，为什么会出现这种情况？这是一个很有意思的话题，Forrester评价Symantec产品组合中唯一真正的缺陷是其传统的DLP方法。客户“并未真正按预期使用DLP”。但是，实际上，对于当今行业中的大多数DLP工具来说，这很常见。传统DLP的问题本文就不展开讨论了。不过，笔者一直认为，数据安全相对而言是零信任理念和架构最容易落地的一个维度，一个好的数据安全方案和产品可以基本不改变用户原有的网络架构，不改造用户原有的应用系统，不影响用户原有的使用习惯，以轻量级代理的模式介入到用户环境中，达到一个性价比相对价高的零信任安全结果。因为Forrester Wave™在数据安全维度下只有ForcePoint得到最高的5分，下面以ForcePoint为例简单说明。

Forcepoint的解决方案是围绕DLP和CASB构建数据安全平台，同时关注用户在终端上的行为监控和实体行为分析。Forcepoint将数据分为两大类，一类是个人信息类数据，另一类是知识产权类数据。对个人信息类数据，它集成各种合规检查和报告，可以帮助用户实现数据隐私法规的合规，例如GDPR、CCPA、PCI DSS等。对于知识产权类数据通过机器学习、指纹等方式定义和识别数据，制定数据访问规则，并持续监控、分析和调整。Forcepoint将看似无关的数据安全事件进行关联分析，通过事件风险排序（IRR）将不同的指标融合到机器学习模型中，以评估数据风险发生的可能性。它通过一个仪表板为管理员提供了整个企业（包括端点，网络和云应用程序）受保护数据的统一视图。

六、可见性和分析

这一个维度相对来说入围的各个厂商都做了不少工作，因为没有对安全的可见性和分析，产品的价值是无法体现出来的。看不见或看不懂的东西是无法被保护的，Forrester在这个维度主要关注技术或解决方案是否提供有用的分析和数据支撑，并尽量消除系统和基础架构中存在的死角。这在不同的关注维度下有不同的支撑场景和实现，需要在对需求，客户、业务和技术多维度的综合认知指引下，定义出产品自身的分析和可视化逻辑，本文就不展开分析了。

在Forrester Wave™评分中得到5分有7家企业，分别是Check Point、Cisco、Palo Alto Networks、Forcepoint、Forescout、Unisys、Illumio。下面以Illumio为例简单说明。

Illumio的自适应安全平台提供实时的应用程序依赖关系映射和安全分段，以阻止数据中心和云环境内部的横向移动。这对对跨异构计算环境的工作负载之间的连通性的可见性有较高的要求，它提供了异构环境中工作负载的实时显示，自动的发现和分类和全面的可视化审核。Illumio的核心能力是在整个基础架构中提供定义明确且清晰可见的资产图。

七、自动化和编排

零信任安全体系结构要发挥最大的价值，需要与更广泛的IT环境集成，可以改进的事件响应的速度，提高策略的准确性和并自动分配任务等。Forrester在这个维度主要关注技术或解决方案如何实现基于零信任原则的自动化和编排，并使企业能够对不同的系统进行更强大的控制。它认为如果工具具有辅助自动化和编排的技术能力，并且还可以进行细分，还不足以成为平台。但是，如果工具或技术支持微隔离和加密，集成了自动化和编排功能，并且具有完善的API，开发人员可以通过该API内置其他零信任功能，则可以将其视为平台。

通过自动化和编排，可以将重复和繁琐的安全任务转换为自动执行、计划执行或事件驱动的自定义工作流。可以动态地将安全策略中的对象与外部资料关联（如AD等IAM身份管理系统），以释放大量的工作人员时间，并减少由于人为错误而出错的机会。可以通过使用算法和经验值来自动识别安全事件，并更改访问策略规则进行响应，响应的方式也可以通过编排自动对接第三方工具和产品。同时也可以与第三方SIEM产品深度集成，提供更完整准确的分析。

在Forrester Wave™评分中得到5分有4家企业，分别是Okta、Palo Alto Networks、Proofpoint、Illumio。下面以Palo Alto Networks为例简单说明。

Palo Alto Networks这一块的功能主要是通过对Demisto的收购实现的。通过为SOC分析人员提供单一平台来管理事件，自动化和标准化事件响应流程以及在事件调查方面进行协作，来优化安全操作的效率。它利用机器学习（ML）来支持诸如事件分类等功能，或为SOC分析人员提供下一步建议。同时为分析人员提供了一个作战室，以便他们协作调查事件，并自动记录事件发生后的报告。Palo Alto Networks提供强大的事件/案例管理和剧本自动化功能，以及300多种现成的产品集成。

这7个维度是John Kindervag的继任者，现在Forrester 首席分析师Chase Cunningham在其零信任扩展框架中提炼出的7个支撑维度。在用户视角看，目前实现全面的零信任的改造存在复杂性和风险。但从不同用户具体的IT基础设施的实际出发，从最关切的风险出发，可以逐步落实零信任的原则和理念。

本质上，包括零信任在内的一切新的概念和总结，出发点都是为了解决网络安全和信息安全的本源问题，即应用和系统的可用性问题，数据的机密性问题。围绕可用性、机密性和完整性的原则，不断迭代新的理念和技术，为用户的业务提供更好的支撑和保障，这些零信任产品的发展也是各个厂商在某相对擅长的领域，为了更好的解决客户问题的自然演进。

所以零信任的7个维度划分也不是铁律，我们可以分解来看，一定程度上就是更细的网络边界，应用切分，数据定义，用户身份的多次验证，更细的强制访问控制，在永不信任，持续验证的理念下，如何在不影响用户体验的情况下，提供更好的安全保障和服务。

*本文作者：王文宇@ 网安网事，转载请注明来源

完美世界何艺：零信任架构的开发和落地

Tue, 07 Apr 2020 09:30:56 CST

“在这个过程中会遇到很多你想不到的问题，或者你以为的小问题，对公司上万台终端来说，哪怕1%的概率也要花很大的成本来解决这个问题。”

何艺，十六年甲方安全经验，现任完美世界高级安全总监，负责集团的安全工作，专注企业安全建设，安全平台设计，安全分析与检测，自15年开始研究零信任架构，并以自研方式在集团内落地和闭环。在各大安全会议上有过多次议题分享经历，有个人公众号“小议安全”，也欢迎大家搜索关注。

近几年，“传统安全边界逐渐失效”的论调不绝于耳，随着攻击手段的复杂化、多样化，边界防护日渐衰微。此次邀请完美集团高级安全总监何艺来分享在传统安全架构逐渐失效的背景下，利用零信任架构建设企业安全的实践经验。

传统的安全架构，主要思想在于边界安全防护，将资源投入到边界上去。而如今的边界正在“模糊化”，不像传统边界那样清晰，比如BYOD自带设备、业务上云、远程办公等等。

过去，传统边界模型对于以往一些传统的安全事件来说是很有效的，比如蠕虫，阻断端口即可将其防御在外。但是，随着现在攻击方式的进步，比如APT攻击、网络钓鱼、社会工程学等方式，往往就可以进入企业内部，而内部的检测和防护能力较弱，这就导致了传统边界安全的失效。因此，再在边界上下功夫，那么企业的安全防护自然也难以应对新的安全问题。

2014年，谷歌的一篇论文彻底打破了内外网之别，其“不再区分内外网”的做法震惊世界，那时推出的Beyondcorp项目将“零信任架构”推入人们的视线中。

我们当时15年的时候，其实之前很多精力是放在检测这个方面，但是当时已经觉得检测越来越不能够应对当前的一些问题，正在设计主动防护方案，这个时候看到谷歌这条新闻被国内报道，当时很多朋友圈其实都在转发，那个时候很多人觉得挺不可思议，太超前了。

在企业安全实践之路上，零信任架构又或者说零信任理念，这是大胆的一步。

回看国内零信任架构建设，完美集团的零信任架构搭建和落地具有一定的参考和借鉴意义。而何艺对零信任架构具有多年的研究经验，深耕安全行业多年，带领安全团队从一开始只是启发到后面的落地闭环，一步一步结合业务分阶段地构建企业的网络安全架构。

在何艺看来，企业搭建网络安全架构往往要根据企业的业务现状来决定，比如传统企业，业务大部分都处在线下，未来也没有往线上发展的打算，那么网络威胁和挑战对这类企业则没有太大的影响。然而，现实情况是在第四次工业革命的大背景环境下，传统企业逐渐转型、逐渐上云，将自身业务转向线上，比如制造业或者是基于网络化的智能型产业。

在这种情况下，网络安全架构则十分重要。一个好的架构不仅是企业安全保障的基础，而且可以起到事半功倍的作用，以较小的投资得到较大的收益。此外，好的安全架构是能够适应未来发展的，比如遇到新的问题、新的威胁，能不能在这个架构之上快速增加一些新的模块，或者是做一些变化和调整来应对威胁，这个问题对于好的安全架构来说，至关重要。

从各自为政到安全一体化

企业安全建设离不开安全理念的支撑。何艺在采访中提及，在安全行业这些年中，不断学习和成长，逐渐形成了“安全一体化”的思想。

在2004年，当时何艺还在CERT任职，担任网络安全组组长，当时应用的还是传统的安全解决方法，很多是依赖于乙方及其提供的安全解决方案和安全产品，基本上也都偏向合规类。

这种传统的安全解决方案，包括一些安全场景，可能主要还是以合规为主，而不是真正去关心是否能够解决企业的安全问题。

2011年，在进入完美世界之后，何艺企业建设安全理念的种子开始发芽。在过去的传统安全中，安全产品之间往往都是各自为政，系统中的某一个地方遭受攻击之后，其他地方或者其他系统并不能感知到此次攻击。然而，对于黑客来说，他们背后的这些力量、资源或者是产业，都是互通的。黑客之间进行一些利益交换，共享是很容易的，他们是集中优势力量来发动进攻。

这种情况下，对于企业而言，传统的安全方案就会特别被动，所以说那时候就萌生了要做这种一体化安全平台的想法。

出于早期资源有限以及方便切入，何艺及其安全团队一开始用开源系统去搭建集中化的安全分析平台，用开源的方式去做分析的平台，收到了好的效果但还远远不够。因为这种分析平台是基于事中和事后，缺乏主动防御，依然是无法解决安全问题的，比如在APT对抗中，仅仅只是这样一种分析类的一体化平台，永远是滞后的、无法有效地进行自我保护。

我们后来开始做零信任架构，从15年开始研究，以分层分模块方式，一边开放一边落地，同时进行修正和迭代，一直到现在零信任架构闭环落地，然后推广到各个业务中。

一体化安全平台理念是搭建零信任架构的一部分，在未来，这种理念还将和业务更加紧密地结合，比如像服务器之间的最小化权限，业务之间API的一些调用等，将这些延伸到业务中去，才能切实验证和发挥理念优势。

零信任架构搭建及难点

零信任架构是一种典型的主动防护性质的架构，可以和以前的企业架构结合在一起，既有防护又有检测。结合一体平台化思想搭建零信任架构，当平台一方遭受攻击之后，其他系统也可以感应得到，平台所有数据相通，可以互相联动。

安全解决方案往往是就是一个新的方案去解决一个安全风险的时候，可能会带来另外一些新的风险，这里面其实也是一个取舍问题。

在集中化的这个过程中会产生一些结构化风险，比如当核心节点被攻击时，影响的面积会比之前大。所以其实又回到了安全投入产出比的问题上，因为集中化，可以以较少的资源投入到这些集中的地方进行防护，因此也会更加有效。安全方案在解决一些风险时往往也会带来一些新的风险，而方案优良与否、适合与否，有个大的考量在于能否接受这个新的风险，或者是，权衡之下，能否防控住这种新的风险。

从一开始从谷歌得到启发，经过多个阶段的摸索和尝试，到最后架构的闭环、落地，完美世界集团的零信任架构在安全防护和应用上已经颇见成效。

我觉得零信任架构内部其实并没有黑科技，这不是一个完全全新的东西，相反，这更像是一个多种技术集成的事物。

基于此，何艺将零信任架构的构建拆分为三个阶段。

第一阶段

基于统一认证的实现，比如开发OTP这样的一个动态口令认证系统，所有业务可以应用这种系统进行认证，这是一个基础的技术系统。其次，web网关的实现，即将web应用一一放到网关去进行保护、认证和授权。通过认证之后的用户才能够看到页面和具体的业务。同时，系统还带有一些可共同监督的功能。这是零信任架构比较核心的系统模块。

第二阶段

构建零信任需要的终端、网络、分析环境，比如SADB系统、SOC统计分析中心的构建和完善。在做终端agent之前，先做了移动端的app，利用零信任架构支撑公司的移动化办公，比如移动端的审批、应用等都可以进行快速集成。所以构建了这样的技术平台之后，也帮助了公司移动化办公。而终端PC agent的构建，由于时间较长、成本较高、难度较大，则放在了第三个阶段去部署和完成。

完美世界零信任整体架构图

第三阶段

基于前两个阶段的准备，开始开发终端agent、网络安全管理系统。最后，将三套系统整合起来，其中包括主机安全管理系统（涵盖终端agent）、网络安全管理系统、应用安全管理系统，并且开始做三者之间的联动，并打通数据共享。谷歌核心的理念，从终端到人，再到权（应用权限）三者之间的信任关系便建立起来了。同时，在这个过程中，不断地优化以及将数据转到SOC中并进行集中和联动，之后再进行全局的安全分析工作响应，最后才能够将零信任架构落实到业务上去。

虽说零信任架构不是完全陌生的事物，但是这个探索的过程依然是极其不容易的。架构构建、开发、和业务相结合的实施过程中就会产生各种各样的问题，需要整个安全团队一步一步地去解决。

谈及这整个过程中印象深刻的“难关”，何艺认为其实有很多，比如终端的准入开发遇到设备兼容性问题，应用安全网关拦截不跳转的问题，后台的业务配合认证，配合这种认证规范和集成化，用户端那边，较老的商业应用可能就需要比较低的IE版本，导致一些不兼容的问题等等。

其实在开发、实施阶段，你之前很难预料到所有的问题，可能就是等到要开始去做的时候，甚至说有时候你真正开始应用的时候，才发现以前的方案可能会走不通。

这些看似微小的问题，却会影响到整个架构的落地，但好在整个团队非常齐心，遇到问题大家一起来解决来克服。

企业安全团队管理

很多东西对我们而言未知的，我们之前也比较缺乏这样的一些经验，但是好的一点，就是说我们的小伙伴，团队其实还不错。

对于整个企业的安全建设，技术或许起到决定性作用。然而，何艺却认为，安全技术最终还是依赖于人来实现，而不同的人有不同的分工，不同阶段有各自的压力和挑战。比如在项目开发阶段，开发人员就十分重要，新的业务一旦遇到bug，就要快速地响应和修复。而在项目实施的阶段，安全运维的人要大规模推动上线，充当热线解决用户问题、之后的运营过程中，安全测试、分析人员要不断主动去找问题，发现问题，那么他们的重要性和挑战也就突显出来了。

其实就对于安全管理来说的话，你可能就要考虑到说去怎么样让大家在不同的阶段中，然后都能够体现出自己的价值来。

换句话说，安全管理需要让不同的人在不同的阶段和岗位中充分发挥自己的价值。对于人员本身而言，也有所收获和成长，平衡人员个体和公司的双向动态发展。安全管理不应该是过于管制或者过于强制的，应该是一种带领性的作用，给安全团队一个明确的方向，在这个过程中，不断调整、不断进步。

提到完美世界集团的安全部门管理，何艺分享了他的一个理念，将人的经验积累起来转换成系统或者是平台的能力，这可能是一些功能模块也有可能是一些系统规则。经验的不断累积和转换，这是有利于安全技术人员从重复的劳动中解放出来，去做其他更有价值的事，以此往复，系统平台的能力就会不断沉淀、不断加强，对于新兴的风险和威胁防御能力也会不断增长，而团队人员可以把精力放在发现新的问题，解决新的问题上，会有更多成长。完美世界在这个成长过程中也在不断调整，比如从过去的攻防体系到如今的攻击、防御、检测的分层体系。总而言之，结合这种一体平台化的理念，完美世界的零信任架构安全建设一直在路上。

所有的产出都是依赖团队的力量，每一个人都是幕后功臣。最后，何艺表示，现在的安全团队也还需要注入新鲜血液，希望能有更多的小伙伴加入进来，将这套体系完善下去，共同成长。

结语

零信任架构作为网络安全行业的“新宠”，尽管早期面临许多质疑，比如是否是“新瓶装旧酒”、能否发挥其安全防护效用等问题，但是面对这些质疑，完美世界架构的落地闭环提交了一份还不错的答卷。从一开始尝试、质疑、再尝试，到闭环、落地，零信任架构搭建过程是不易的，以业务为导向，结合独特的企业安全理念，面对未来复杂多变的网络威胁，企业安全防护才能真正有效。

*本文作者：Sandra1432，转载请注明来自FreeBuf.COM

HTTP的前世今生

Tue, 01 Oct 2019 19:21:10 CST

HTTP (Hypertext transfer protocol) 翻译成中文是超文本传输协议，是互联网上重要的一个协议，由欧洲核子研究委员会CERN的英国工程师 Tim Berners-Lee v发明的，同时，他也是WWW的发明人，最初的主要是用于传递通过HTML封装过的数据。在1991年发布了HTTP 0.9版，在1996年发布1.0版，1997年是1.1版，1.1版也是到今天为止传输最广泛的版本（初始 RFC 2068 在1997年发布，然后在1999年被 RFC 2616 取代，再在2014年被 RFC 7230 / 7231/ 7232/ 7233/ 7234/ 7235取代），2015年发布了2.0版，其极大的优化了HTTP/1.1的性能和安全性，而2018年发布的3.0版，继续优化HTTP/2，激进地使用UDP取代TCP协议，目前，HTTP/3 在2019年9月26日被 Chrome，Firefox，和Cloudflare支持，所以我想写下这篇文章，简单地说一下HTTP的前世今生，让大家学到一些知识，并希望可以在推动一下HTTP标准协议的发展。

HTTP 0.9 / 1.0

0.9和1.0这两个版本，就是最传统的 request – response的模式了，HTTP 0.9版本的协议简单到极点，请求时，不支持请求头，只支持 GET 方法，没了。HTTP 1.0 扩展了0.9版，其中主要增加了几个变化：

在请求中加入了HTTP版本号，如： GET /coolshell/index.html HTTP/1.0
HTTP 开始有 header了，不管是request还是response 都有header了。
增加了HTTP Status Code 标识相关的状态码。
还有 Content-Type 可以传输其它的文件了。

我们可以看到，HTTP 1.0 开始让这个协议变得很文明了，一种工程文明。因为：

一个协议有没有版本管理，是一个工程化的象征。
header是协议可以说是把元数据和业务数据解耦，也可以说是控制逻辑和业务逻辑的分离。
Status Code 的出现可以上请求双方以及第三方的监控或管理程序有了统一的认识。最关键是还是控制错误和业务错误的分离。

（注：国内很多公司HTTP无论对错只返回200，这种把HTTP Status Code 全部抹掉完全是一种工程界的倒退）

但是，HTTP1.0性能上有一个很大的问题，那就是每请求一个资源都要新建一个TCP链接，而且是串行请求，所以，就算网络变快了，打开网页的速度也还是很慢。所以，HTTP 1.0 应该是一个必需要淘汰的协议了。

HTTP/1.1

HTTP/1.1 主要解决了HTTP 1.0的网络性能的问题，以及增加了一些新的东西：

可以设置 keepalive 来让HTTP重用TCP链接，重用TCP链接可以省了每次请求都要在广域网上进行的TCP的三次握手的巨大开销。这是所谓的“ HTTP 长链接” 或是 “ 请求响应式的HTTP 持久链接”。英文叫 HTTP Persistent connection.
然后支持pipeline网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。（注：非幂等的POST 方法或是有依赖的请求是不能被pipeline化的）
支持 Chunked Responses ，也就是说，在Response的时候，不必说明 Content-Length 这样，客户端就不能断连接，直到收到服务端的EOF标识。这种技术又叫 “ 服务端Push模型”，或是 “ 服务端Push式的HTTP 持久链接”
还增加了 cache control 机制。
协议头注增加了 Language, Encoding, Type 等等头，让客户端可以跟服务器端进行更多的协商。
还正式加入了一个很重要的头—— HOST这样的话，服务器就知道你要请求哪个网站了。因为可以有多个域名解析到同一个IP上，要区分用户是请求的哪个域名，就需要在HTTP的协议中加入域名的信息，而不是被DNS转换过的IP信息。
正式加入了 OPTIONS 方法，其主要用于 CORS – Cross Origin Resource Sharing 应用。

HTTP/1.1应该分成两个时代，一个是2014年前，一个是2014年后，因为2014年HTTP/1.1有了一组RFC（ 7230 / 7231/ 7232/ 7233/ 7234/ 7235），这组RFC又叫“HTTP/2 预览版”。其中影响HTTP发展的是两个大的需求：

一个需要是加大了HTTP的安全性，这样就可以让HTTP应用得广泛，比如，使用TLS协议。
另一个是让HTTP可以支持更多的应用，在HTTP/1.1 下，HTTP已经支持四种网络协议：
- 传统的短链接。
- 可重用TCP的的长链接模型。
- 服务端push的模型。
- WebSocket模型。

自从2005年以来，整个世界的应用API越来多，这些都造就了整个世界在推动HTTP的前进，我们可以看到，自2014的HTTP/1.1 以来，这个世界基本的应用协议的标准基本上都是向HTTP看齐了，也许2014年前，还有一些专用的RPC协议，但是2014年以后，HTTP协议的增强，让我们实在找不出什么理由不向标准靠拢，还要重新发明轮子了。

HTTP/2

虽然 HTTP/1.1 已经开始变成应用层通讯协议的一等公民了，但是还是有性能问题，虽然HTTP/1.1 可以重用TCP链接，但是请求还是一个一个串行发的，需要保证其顺序。然而，大量的网页请求中都是些资源类的东西，这些东西占了整个HTTP请求中最多的传输数据量。所以，理论上来说，如果能够并行这些请求，那就会增加更大的网络吞吐和性能。

另外，HTTP/1.1传输数据时，是以文本的方式，借助耗CPU的zip压缩的方式减少网络带宽，但是耗了前端和后端的CPU。这也是为什么很多RPC协议诟病HTTP的一个原因，就是数据传输的成本比较大。

其实，在2010年时，Google 就在搞一个实验型的协议，这个协议叫 SPDY，这个协议成为了HTTP/2的基础（也可以说成HTTP/2就是SPDY的复刻）。HTTP/2基本上解决了之前的这些性能问题，其和HTTP/1.1最主要的不同是：

HTTP/2是一个二进制协议，增加了数据传输的效率。
HTTP/2是可以在一个TCP链接中并发请求多个HTTP请求，移除了HTTP/1.1中的串行请求。
HTTP/2会压缩头，如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。这就是所谓的HPACK算法（参看 RFC 7541 附录A）
HTTP/2允许服务端在客户端放cache，又叫服务端push，也就是说，你没有请求的东西，我服务端可以先送给你放在你的本地缓存中。比如，你请求X，我服务端知道X依赖于Y，虽然你没有的请求Y，但我把把Y跟着X的请求一起返回客户端。

对于这些性能上的改善，在Medium上有篇文章你可看一下相关的细节说明和测试“ HTTP/2: the difference between HTTP/1.1, benefits and how to use it”

当然，还需要注意到的是HTTP/2的协议复杂度比之前所有的HTTP协议的复杂度都上升了许多许多，其内部还有很多看不见的东西，比如其需要维护一个“优先级树”来用于来做一些资源和请求的调度和控制。如此复杂的协议，自然会产生一些不同的声音，或是降低协议的可维护和可扩展性。所以也有一些争议。尽管如此，HTTP/2还是很快地被世界所采用。

HTTP/2 是2015年推出的，其发布后，Google 宣布移除对SPDY的支持，拥抱标准的 HTTP/2。过了一年后，就有8.7%的网站开启了HTTP/2，根据这份报告，截止至本文发布时（2019年10月1日），在全世界范围内已经有41%的网站开启了HTTP/2。

HTTP/2的官方组织在 Github 上维护了一份各种语言对HTTP/2的实现列表，大家可以去看看。

我们可以看到，HTTP/2 在性能上对HTTP有质的提高，所以，HTTP/2 被采用的也很快，所以，如果你在你的公司内负责架构的话，HTTP/2是你一个非常重要的需要推动的一个事，除了因为性能上的问题，推荐标准也是架构师的主要职责，因为，你企业内部的架构越标准，你可以使用到开源软件，或是开发方式就会越有效率，跟随着工业界的标准的发展，你的企业会非常自然的享受到标准所带来的红利。

HTTP/3

然而，这个世界没有完美的解决方案，HTTP/2也不例外，其主要的问题是：若干个HTTP的请求在复用一个TCP的连接，底层的TCP协议是不知道上层有多少个HTTP的请求的，所以，一旦发生丢包，造成的问题就是所有的HTTP请求都必需等待这个丢了的包被重传回来，哪怕丢的那个包不是我这个HTTP请求的。因为TCP底层是没有这个知识了。

这个问题又叫 Head-of-Line Blocking问题，这也是一个比较经典的流量调度的问题。这个问题最早主要的发生的交换机上。下图来自Wikipedia。

图中，左边的是输入队列，其中的1，2，3，4表示四个队列，四个队列中的1，2，3，4要去的右边的output的端口号。此时，第一个队列和第三个队列都要写右边的第四个端口，然后，一个时刻只能处理一个包，所以，一个队列只能在那等另一个队列写完后。然后，其此时的3号或1号端口是空闲的，而队列中的要去1和3号端号的数据，被第四号端口给block住了。这就是所谓的HOL blocking问题。

HTTP/1.1中的pipeline中如果有一个请求block了，那么队列后请求也统统被block住了；HTTP/2 多请求复用一个TCP连接，一理发生丢包，就会block住所有的HTTP请求。这样的问题很讨厌。好像基本无解了。

是的TCP是无解了，但是UDP是有解的！ 于是HTTP/3破天荒地把HTTP地底层的TCP协议改成了UDP！

然后又是Google 家的协议进入了标准 – QUIC （Quick UDP Internet Connections）。接下来是QUIC协议的几个重要的特性，为了讲清楚这些特性，我需要带着问题来讲（注：下面的网络知识，如果你看不懂的话，你需要学习一下《 TCP/IP详解》一书（在我写blog的这15年里，这本书推荐了无数次了），或是看一下本站的《 TCP的那些事》。）：

首先是上面的Head-of-Line blocking问题，在UDP的世界中，这个就没了。这个应该比较好理解，因为UDP不管顺序，不管丢包（当然，QUIC的一个任务是要像TCP的一个稳定，所以QUIC有自己的丢包重传的机制）
TCP是一个无私的协议，也就是说，如果网络上出现拥塞，大家都会丢包，于是大家都会进入拥塞控制的算法中，这个算法会让所有人都“冷静”下来，然后进入一个“慢启动”的过程，包括在TCP连接建立时，这个慢启动也在，所以导致TCP有一些时候性能也不行。QUIC才不管这个，是个相对比较激进的协议。QUIC有一套自己的丢包重传和拥塞控制的协，一开始QUIC是重新实现一TCP 的 CUBIC算法，但是随着BBR算法的成熟（BBR也在借鉴CUBIC算法的数学模型），QUIC也可以使用BBR算法。这里，多扯几名， 从模型来说，以前的TCP的拥塞控制算法玩的是数学模型，而新型的TCP拥塞控制算法是以BBR为代表的测量模型，理论上来说，后者会更好，但QUIC的团队在一开始觉得BBR不如CUBIC的算法好，所以没有用。现在的BBR 2.x借鉴了CUBIC数学模型让拥塞控制更公平。这里有文章大家可以一读“ TCP BBR : Magic dust for network performance.”
接下来，现在要建立一个HTTP的连接，先是TCP的三次握手，然后是TLS的三次握手，要整出六次网络交互，一个链接才建好，虽说HTTP/1.1和HTTP/2的连接复用解决这个问题，但是基于UDP后，UDP也得要实现这个事。于是QUIC直接把TCP的和TLS的合并成了三次握手。

所以，QUIC是一个在UDP之上的伪TCP +TLS +HTTP/2的多路复用的协议。

但是对于UDP还是有一些挑战的，这个挑战主要来自互联网上的各种网络设备，这些设备根本不知道是什么QUIC，他们看QUIC就只能看到的就是UDP，所以，在一些情况下，UDP就是有问题的，

比如在NAT的环境下，如果是TCP的话，NAT路由或是代理服务器，可以通过记录TCP的四元组（源地址、源端口，目标地址，目标端口）来做连接映射的，然而，在UDP的情况下不行了。于是，QUIC引入了个叫connection id的不透明的ID来标识一个链接，用这种业务ID很爽的一个事是，如果你从你的3G/4G的网络切到WiFi网络（或是反过来），你的链接不会断，因为我们用的是connection id，而不是四元组。

然而就算引用了connection id，也还是会有问题，比如一些不够“聪明”的等价路由交换机，这些交换机会通过四元组来做hash把你的请求的IP转到后端的实际的服务器上，然而，他们不懂connection id，只懂四元组，这么导致属于同一个connection id但是四元组不同的网络包就转到了不同的服务器上，这就是导致数据不能传到同一台服务器上，数据不完整，链接只能断了。所以，你需要更聪明的算法（可以参看 Facebook 的 Katran 开源项目）

好了，就算搞定上面的东西，还有一些业务层的事没解，这个事就是 HTTP/2的头压缩算法 HPACK，HPACK需要维护一个动态的字典表来分析请求的头中哪些是重复的，HPACK的这个数据结构需要在encoder和decoder端同步这个东西。在TCP上，这种同步是透明的，然而在UDP上这个事不好干了。所以，这个事也必需要重新设计了，基于QUIC的QPACK就出来了，利用两个附加的QUIC steam，一个用来发送这个字典表的更新给对方，另一个用来ack对方发过来的update。

目前看下来，HTTP/3目前看上去没有太多的协议业务逻辑上的东西，更多是HTTP/2 + QUIC协议。但，HTTP/3 因为动到了底层协议，所以，在普及方面上可能会比 HTTP/2要慢的多的多。但是，可以看到QUIC协议的强大，细思及恐，QUIC这个协议真对TCP是个威胁，如果QUIC成熟了，TCP是不是会有可能成为历史呢？

未来十年，让我们看看UDP是否能够逆袭TCP……

(全文完)

关注CoolShell微信公众账号和微信小程序

（转载本站文章请注明作者和出处酷壳 – CoolShell ，请勿用于任何商业用途）

——=== 访问酷壳404页面寻找遗失儿童。 ===——

HTTPS劫持研究

Sat, 10 Aug 2019 13:00:48 CST

这篇文章描述了我们对哈萨克斯坦政府实施的电信级HTTPS劫持的分析。

哈萨克斯坦政府最近开始使用一个假的根证书颁发机构，对包括Facebook，Twitter和Google等网站在内的HTTPS连接进行中间人（MitM）攻击，在此文中，我们给出了还在进行中的研究的初步结果，以及哈萨克劫持系统中新的技术细节。

情况提要

哈萨克斯坦最近开始使用一个假的根证书颁发机构对HTTPS连接进行劫持。这一行为显著弱化了哈萨克网络用户的互联网安全体验。

默认情况下，这一证书颁发机构是不被浏览器信任的，因此必须通过用户手动安装。如果用户不安装这一假证书颁发机构的根证书进而允许劫持，那么用户则完全无法访问受影响的网站。

第一次检测到的劫持行为是在7月17日，我们从7月20号就开始了持续追踪。期间劫持行为出现了几次停止又再次启动的现象。只有某些网站被劫持，劫持是由基于SNI 主机名字段触发的。至少37个域名受到影响，包括社交媒体和即时通讯网站（完整列表见文章后）。

截至目前，该攻击似乎会影响该国最大的ISP ——Kazakhtelecom（9198 KazTelecom）中传输的连接中的一小部分。这意味着只是部分而不是全部哈萨克网络用户会受到影响。劫持行为可以在国外触发，因此使得国际研究者们可以进行远程研究。

什么是HTTPS劫持？

HTTPS通过加密传输数据来保护浏览器和网站之间的安全交互，从而防止ISP和政府对传输进行读取和篡改。服务器通过提供由证书颁发机构（CA）进行数字签名的证书来验证自己身份，而证书颁发机构就是被浏览器信任、能担保网站身份的一个实体。例如，facebook.com会提供一个由DigiCert签名的证书给浏览器，而DigiCert则是一个被信任并且内置在几乎所有浏览器中的证书颁发机构。通过验证提供的证书并且确认证书是由浏览器所信任的证书颁发机构（DigiCert）所签发，浏览器就可以确信是在和真正的facebook.com进行交互。facebook.com提供的证书同时也包含一个用来保护接下来浏览器和Facebook之间通信的公钥。

在HTTPS劫持攻击（“中间人攻击”的一种类型）中，网络中的攻击者会伪装成一个网站（例如facebook.com），并且提供带有攻击者公钥的假证书。通常，攻击者无法让任何合法的CA来对一个不受攻击者控制的域名的证书进行签名，因此浏览器会检测并阻止这种攻击行为。但是，如果攻击者可以说服用户安装一个新CA的根证书到浏览器当中，浏览器就会信任攻击者提供的由这个合法CA签发的假证书。通过这些假证书，攻击者可以模仿任何网站，进而可以篡改网站内容、记录用户在网站上的操作或发表的内容等。因此，用户不应该安装根CA证书，因为这样就会将原本安全的通信暴露无遗，导致通信被劫持或篡改而不被用户所感知。

Censored Planet的发现

Censored Planet是一个在密歇根大学运作的全球审查行为观察站，该机构利用一些远程检测的方法，连续不断地在超过170个国家监测多种类型的网络接口。我们的扫描器第一次报告在哈萨克斯坦出现可能的中间人攻击是在2019年7月20日。利用一个叫做HyperQuack的技术，我们第一次检测到了这一攻击行为。这一技术通过连接到TLS服务器，发送握手包，而该握手包的服务器名称指示（SNI）扩展中包含可能被审查的域名。如果响应结果显示出不同于正常的握手包的扰乱迹象，那么这一域名就会被标记为可能被审查。

图一 CensoredPlanet是如何使用HTTPS服务器来监测TLS中间人攻击的例子

我们的调查揭示了在这些案例中返回的证书是一个由哈萨克斯坦的根CA（Qaznet Trust Network）（图2）签发的假证书。我们的实验同时显示这一审查行为是通过透明代理实现。这意味着审查者在转发流量到目的机器之前，先对流量进行了解密并用其自己的密钥进行了加密。

图2 KazTelecom AS（AS 9198）中的HTTPS服务器拥有可信证书和中间人注入证书的示例

我们的调查显示，只有网络路径经过劫持系统的连接才会被劫持；但是不论连接的方向如何，只要经过劫持系统，连接就会被拦截。这意味着我们可以通过发起到哈萨克斯坦国内的TLS服务器的连接，从而在国外触发劫持，使得我们能方便地进行更加精细的检测。

深入分析

被Censored Planet的HyperQuack扫描自动生成的结果所提醒之后，我们进行了几次实验来更好的理解哈萨克斯坦的HTTPS劫持的基础设施。

我们在哈萨克斯坦的条件是有限的：我们拥有这个国家里2台VPS客户机和52个RIPE Atlas探针的访问权限。由于已知劫持可以被双向触发，甚至可以被在国外的客户端连接触发，所以我们在国外对该国的TLS主机也进行了更加全面的扫描。

我们在该国内的机器上，仅观察了2个HTTPS劫持的实例，两个都是从RIPE Atlas探针发起。我们的两个VPS客户机都可以访问受影响的站点（例如facebook.com）且不被HTTPS劫持，表明HTTPS劫持在该国并不是普遍行为：即使在连接到已知受影响的域名的时候，很多客户端浏览器都未收到中间人注入的证书。

我们发现证书注入必须要有一定的前提条件：

1、客户端到服务器的路径必须经过AS 9198（KazTelecom）的特定部分，即我们观察到发生了证书注入的那个唯一的AS。

2、客户端必须发送一个包含受影响域名的TLS SNI扩展

3、服务器必须提供一个有效的、浏览器信任的TLS证书，但不必是SNI中所包含域名的证书。

我们注意到这些条件是必要不充分条件：例如我们已经发起了经过AS 9198的连接，但仍没有发现证书注入的现象，即使其他的条件也已成立。我们仍在研究触发劫持所必须满足的其他条件。

哈萨克斯坦有超过200,000个能访问的TLS主机，但是来自Censys的数据表明，只有其中6736个TLS主机提供了一个有效的且被浏览器所信任的证书。7月21日，我们进行了一个TLS握手实验——从位于美国的客户端逐一发起到这6736个HTTPS服务器的连接，将其中的SNI设置为facebook.com和google.com，而这两个域名都已确认会触发HTTPS劫持。我们发现只有459个服务器（7.0%）发生了证书注入，表明哈萨克斯坦的HTTPS劫持目前只发生在该国的一部分地区。

而在该国内，通过我们的其中一个VPS对这6736个可信HTTPS服务器进行了同样的扫描，却发现有1598个（24%）服务器发生了证书注入。而这些服务器都部署在不同的位置，但都会经过AS 9198，而这就恰恰说明了它就是HTTPS劫持所发生的位置。在7月22日的早些时候，我们注意到劫持行为不再继续发生，但是9小时后又再次出现。当我们重新运行我们的检测时，我们发现存在证书注入的HTTPS主机的数量有所减少：从美国位置发起的扫描显示只有300个（4.4%），从哈萨克斯坦的VPS发起的扫描显示有400个（5.9%）。这表明该劫持系统仍处于测试调整阶段，或许是更大规模部署的征兆。

网络跳数级分析

为了定位劫持发生的位置，我们采用了一个基于TTL的技术，这一技术常用来做网络检测。对于每个我们能够触发劫持的HTTPS主机，我们都发出了多次连接，在这些包含SNI主机名的连接中，其 IP报文的TTL字段都带有不同的数值，我们记录了收到注入证书的响应包所对应的最小TTL值。IP报文的TTL字段控制报文能到达的最大网络跳数，所以如果我们把一个报文的TTL值设为3跳，而未收到任何证书注入的响应，我们就能知道注入设备很可能与我们源机器的距离超过3跳。这一技术使得我们能够精准定位注入设备的网络位置。

我们从在哈萨克斯坦部署的VPS上，针对之前检测到存在证书注入的1598个HTTPS服务器，进行了这一类型的扫描。对每一个主机，我们都发起了两次连接，一次包含facebook.com的TLS SNI头，另一次则包含一个未受影响的域名，检测收到响应时的第一跳。在这次扫描的过程中，HTTPS劫持短暂地停止了一段时间，但是如果我们仅观察在发生变化之前扫描的前1212个HTTPS主机，99.5%的结果都显示证书注入行为发生在到达服务器之前的网络路径中的某一跳。在大部分情况下，注入证书返回的网络位置与真正目标主机的网络位置只有3或4跳的网络距离，意味着注入是在距离用户相当近的位置发生的。我们利用相同的技术在美国进行的测试也证实了相似的结果。

通过观察注入发生那一跳所在的IP地址，我们发现95%的时间里，注入发生的前一跳都是92.47.151.210或92.47.150.198，注入发生的后一跳都是95.56.243.92或95.59.170.59。所有这些IP地址都位于AS 9198（KazTelecom），表明AS 9198是目前唯一的造成注入HTTPS证书的网络地址。一个traceroute的示例如下，该实例中证书注入发生在第5跳。

证书注入发生在第四和第五跳之间。

注入的证书

我们也观察了HTTPS劫持所返回的证书的模式规律。当客户端的SNI信息触发了证书注入的时候，返回的假证书似乎是基于服务器的合法证书而不是客户端的SNI信息。这意味着在一次TLS请求中发送包含facebook.com的SNI到一个不相关的站点iqala.kz，会收到一个CN=iqala.kz的注入证书。该注入证书有以下的属性：

和原本主机的证书相同的主题和主题别名（SAN）公钥被替换为一个指定的加密指数为3的RSA-2048密钥有效期（Not Before/Not After）与原本证书相同，但具体时间上有提前6小时整的偏移序列号除最后4字节被修改了之外，其余与原本相同所有其他x509扩展都被移除，该证书是由一个中级证书（C=KZ, CN=Security Certificate）签发，而中级证书又是由根证书（C=KZ, CN=Qaznet Trust Network）签发。中级证书使用2048位的RSA密钥（使用典型的加密指数65537），有效期3年，而根证书则使用4096位的RSA密钥，拥有30年的有效期。

审查痕迹

AS 9198中负责进行劫持的中间组件需要连接到原本的TLS服务器，从而可以获取到其合法的证书，用于验证和替换。我们使用RIPE Atlas检测来发送一个TLS连接到我们控制的服务器，在这台主机上我们可以捕获到来自RIPE Atlas探针的IP数据包。当我们把Atlas 探针客户端的SNI设置为不会触发证书注入的一些域名时，可以在我们的服务器中看到由RIPE Atlas探针发送的正常的客户端hello包，并且拥有一个特定的TLS指纹。但是，当我们把SNI设置为facebook.com时，我们的服务器会收到一个来自HTTPS劫持设备的不同的TLS指纹。与RIPEAtlas的指纹不同，该中间组件的TLS指纹在正常的网络流量中是几乎看不到的。受影响的域名可以使用这一指纹来鉴别连接是否被劫持，对用户进行提示，撤销已经暴露的登录凭据，或者不向用户发送敏感数据。为了进一步分析，我们在这里提供了捕获的数据包。（PCAP包或未发生劫持）

域名目标

HTTPS劫持是由客户端发送的SNI扩展所触发。Censored Planet发现在约10000个测试域名中，有37个域名会触发假证书的注入。这些域名大部分都是社交媒体和即时通讯网站，列表如下：

ISP让用户安装哈萨克斯坦根证书，声称这样可以帮助阻挡诈骗、黑客攻击和非法内容。然而，上面列出的域名表明其真实意图却是监视用户在社交网络和即时通讯网站上的行为。

结语

哈萨克斯坦的HTTPS劫持降低了该国互联网用户的安全性和隐私性。虽然目前劫持还没在全国范围内出现，但似乎政府既希望同时又有潜能，在不久的将来进行大范围的HTTPS劫持。国际社会需要密切监视这一令人忧心的举动，而这一危险信号，已经飞舞在计算机安全界数十年间致力于对所有网站进行高强度、端到端加密的努力和进步的面前。

*本文作者：Kriston，转载请注明来自FreeBuf.COM

K8S的SDN容器网络解决方案及其价值

Fri, 02 Aug 2019 14:26:47 CST

编者按：关于容器网络的解决方案业界已经有较多的讨论，笔者无意继续赘述。K8S及其网络模型体现了鲜明的解耦设计思想，采用SDN技术实现K8S容器网络，并与相应的生态组件形成SDN监管控一体化解决方案，可以更好地提高整个系统的运营水平，更有效地提升企业的核心竞争力。本文拟抛砖引玉，从K8S的网络实现入手，重点阐述SDN在容器网络中的应用价值。欢迎业界联系云杉同仁交流讨论。

综述：K8S的基本机制是以“对象-控制器”架构模式为基础设计与实现的。组件API server与etcd的主要功能是实现对各种资源对象REST风格的增删改查CRUD、盯Watch操作。组件controller-manager包括了各种内置控制器，其功能是确保整个系统处于预期的状态。这种数据存储与应用逻辑分离的模式是各功能组件实现无状态服务架构的关键。K8S集群针对基本操作单元Pod对象的处理主要是通过scheduler和kubelet实现的。实际上我们可以把scheduler看作是集群层面的Pod对象控制器，把kubelet理解为是节点层面Pod对象的创建与维护的控制器。

K8S场景下实现Pod互联等的容器网络特别是其数据转发面遵循并适用网络技术的一般性原则与实现。当前主流的容器网络基本解决方案主要包括以Calico为代表的基于经典的三层路由/Netfilter模型的实现，和以OpenShift的SDN实现为代表的二层SDN/OVS模型的实现。而容器网络的特殊性则主要体现在管理控制面实现、以及基于K8S扩展机制的SDN控制器云原生部署等方面。K8S及其网络模型体现了鲜明的解耦设计思想，不论是在K8S与网络组件之间，还是在容器网络与Pod接入容器网络之间等各方面。

狭义地讲SDN的核心技术主要包括数据转发面特别是流表流水线的设计和相应的基于SDN控制器平台的应用的设计与实现等。SDN控制器与各节点上的SDN代理相配合完成系统容器网络的项目租户、网络子网路由、安全策略与服务、SLA/QoS的管控，以及监控可视化等各项操作。而CNI-Plugin的主要功能则是在kubelet创建Pod时将之挂接到容器网络上。在K8S场景下，SDN的价值同样体现在与各种生态组件的集成，实现一体化监管控解决方案，可以更好地提升整个系统的运营水平。

K8S基本机制

K8S集群提供了以Pod为基本操作单元的容器化应用的部署、维护、扩展等功能。主要由主节点上的API server、etcd、controller-manager、scheduler等，以及工作节点上的kubelet、容器运行时等功能组件构成。命令行kubectl可以在主节点上也可以部署在远程运行，并通过API server调用与K8S交互。etcd集群可以采用与主节点分离的方式进行部署。另外，即使是主节点不参与业务Pod的分配与创建，也需要运行有一个kubelet实例。

对象处理组件与功能

kube-apiserver：API server通过Web Service端点处理函数的注册与相应的访问请求相关联，实现REST机制对资源对象的增删改查CRUD盯Watch等的操作功能，是系统对外访问的统一入口。而K8S集群内部各功能组件之间的互动也主要是通过API server 的Watch机制实现的。API server本身实现了无状态服务架构模式。Web Service端点以API Group来管理分组和版本适配，分组包括核心组、扩展组、其他的auto scaling组、metrics组等。而Proxy类API server接口的作用是代理REST请求，并转发给相应节点的kubelet进行实际的操作处理。此外API server还提供有各种web hook扩展机制。

etcd集群：etcd是Go语言编写的基于raft分布式协议的高可用key-value存储系统，作为API server的后台用于K8S存储各种资源对象包括外部扩展定制资源对象（CRD – Custom Resource Definition）等配置与状态信息，支持典型的消息发布与订阅机制，即Watch机制。etcd是K8S组件API server等实现无状态服务架构的基础。K8S集群内任何对资源对象的增删改查CRUD盯Watch操作等都通过API server的storage接口统一与etcd交互，各组件不会直接操作etcd。

控制器架构模式及组件功能

控制器模式是K8S各组件功能实现的基本框架，其基础主要是基于etcd特性在API server内部实现的List-Watch机制和相应的client-go客户端平台库函数。

List-Watch机制：该机制是基于etcd本身的Watch特性的，属于API server对资源对象CRUD操作的体系化扩展。API server内部向etcd发起的Watch只能订阅某个对象的创建、删除事件，无法设置过滤条件的，不能针对对象的属性进行过滤；而API server实现对外部各种K8S功能组件发起的Watch请求的处理，并能够针对对象属性进行过滤。在集群运行过程中组件向API server发送REST请求进行Watch订阅，告诉API server对什么资源对象及发生什么样的变化事件感兴趣。而每一个Watch操作的生命周期对应相应的HTTP REST请求的生命周期。

库函数client-go包括了访问API server的客户端，以及支持控制器实现所需的相关平台机制List-Watch的客户端informer和事件队列workqueue等。这样控制器的设计与实现只需专注应用逻辑，只需提供对象的事件回调函数和相应的队列处理功能即可。

控制器架构模式：一个典型的控制器实现通过API server的List-Watch机制的客户端informer与API server保持交互，跟踪特定的资源对象的状态与变化。对象变化的事件由informer调用相应的callback完成一些基本的处理，然后把相关的变更及对象信息放到workqueue里面。控制器的应用逻辑实现在worker协程里面。控制器可启动多个worker协程来处理workqueue里的对象事件。根据对象的期望状态和当前系统的实际情况进行相应的处理，并通过clients向API server发送行动请求。实际上也是通过对其他相关下游资源对象的设置，以实现整个集群向期望的状态演进。此外，为缓解各组件模块对API server的访问压力、提高处理性能，控制器的内部实现也都采用了缓存机制的支持。

kube-controller-manager：K8S内置了一系列的控制器，基本上都是嵌入在controller-manager进程里的。其中，Replication Controller的功能是确保集群中有且仅有指定个数的Pod实例在运行，可以通过调整RC中的副本数量来实现系统扩容或缩容，通过改变RC中的Pod模板来实现系统的滚动升级；Endpoints Controller中的Endpoints表示某个Service对应的所有Pod副本的访问地址。此控制器的功能是通过监听Service和对应的Pod副本的变化，负责生成和维护所有Endpoints对象。而工作节点上的kube-proxy就是通过监听Service和Endpoints来配置相应的数据面实现相应的转发和负载均衡功能。我们可以理解Endpoints Controller是K8S除Pod以外最重要的资源对象服务Service的集群层面的控制器，而kube-proxy则是相应节点层面的控制器；Namespace Controller的功能是在后台实现优雅地删除某Namespace下的Service Account、RC、Pod等资源对象及此Namespace本身；Service Accounts Controller的功能是为每个Namespace维护一个默认的Service Account，并与Token Controller配合实现K8S集群内部Pod访问API server的认证功能。

K8S除本身内置的这些控制器外，也支持各种用户自定义扩展。控制器可以运行在K8S主节点上，也可以运行在工作节点上；可以运行在K8S集群内，甚至运行在集群外。

Pod处理组件与功能

基本上K8S的资源对象与控制器都是相互对应、配合起来完成相应的功能的。但如果注意到的话，在controller-manager中并没有针对Pod对象操作的控制器。实际上K8S决定把Pod放到哪个节点上是由组件scheduler按照相应的策略决策的，而Pod的实际创建与维护是由kubelet完成的。所以我们可以理解为scheduler是Pod集群层面的控制器，kubelet则是Pod节点层面的控制器。

具体的来说，就是scheduler通过API server提供的Watch等接口，监听并获取到未调度的Pod和节点等的相关信息，通过过滤和优先级算分对节点筛选，选择出最合适的节点，将Pod与此节点绑定，并把结果通过API server存储到etcd中。在相应工作节点上的kubelet会去实际创建Pod的SandBox，调用CNI-Plugin进行相应的网络配置挂接SandBox网络名字空间到容器网络上，创建和运行Pod所属的init容器，最终创建和运行Pod的常规业务容器。

SDN容器网络

业界所谓的“There is no such thing called container networking”的说法更多的是从连接容器或Pod的网络的一般性而言的。或者说从二层交换、三层路由转发面的角度认为连接容器的网络与连接VM或BM等的网络没有本质的区别，即容器网络特别是其数据转发面仍遵循和适用网络技术的一般性原则与实现。在这个层面上“容器网络”有点类似“业务网络”的概念之与物理网络、虚拟网络。但另一方面，特别是从服务发现与负载均衡、管理模式与部署实施等的角度看，K8S的“容器网络”是有其特殊性的。这主要体现在Pod生命周期到服务Service映射的动态性、SDN控制器云原生模式部署、Pod挂接网络的Plugin机制、以及安全策略的实现等方面。

数据转发面与管理控制面

针对当前主流的典型的容器网络解决方案的分析，特别从数据转发面特征的角度，可以认为主要包括以Calico为代表的基于经典的三层路由、Netfilter模型的实现，和以OpenShift的SDN及Neutron等为典型代表的二层SDN/OVS模型的实现等。

三层路由/Netfilter模型：这类实现的优点是网络拓扑直观易懂，扁平化结构，可扩展性强；容器间三层网络隔离，不需要解决arp风暴问题；基于经典的、成熟的Netfilter/IPtables与Linux路由技术，包转发与细粒度策略控制效率高等。

二层SDN/OVS模型：这类模式的转发面是指Overlay二层和流表流水线设计与实现采用OVS，支持与各种Underlay模式的对接，可扩展实现DVR、广播抑制特性等。这是当前比较典型和成熟的转发面SDN模式方案；三层采用网络名字空间的Linux路由器；安全策略以及NAT功能采用Netfilter/IPtables实现。

基于这种参考架构实现的方案的优点是兼容了传统网络二层交换、三层路由、策略控制，可以通过VLAN实现多租户隔离；可以采用典型的SDN套路对容器网络的访问做到细粒度控制；Overlay与Underlay的解耦设计，具备良好的混合云、公有云的互联能力；逻辑结构清晰，可适应不同场景和规模的网络方案；有成熟的开发部署运维实践经验，稳定性经过生产环境验证。这种类型的典型有OpenShitf的SDN转发面方案，从某种角度来看它与Neutron模型的转发面实现有很多类似的地方。

SDN容器网络转发面设计与实现的关键因素，特别是对于虚拟网络方案而言，是选择以Linux路由、Netfilter为基础，叠加基于OVS的多租户支持等的SDN扩展。一般而言以OVS为主体的SDN容器网络解决方案，也是需要有三层互联的功能配合的。而对于简单扁平的三层容器网络方案是可以没有二层OVS特性支持的。

相应的管理控制面的设计与实现主要也分为基于BGP的分布式管理控制面和基于SDN控制器的集中式管理控制面等。

平台扩展与云原生部署

K8S实现了典型的平台与应用解耦的架构设计，提供了种针不同场景的扩展手段。除了kubelet的CNI-Plugin网络挂接扩展外，与SDN容器网络相关的扩展机制还有Operator模式和Aggregated Server模式。

Operator扩展模式：这种模式基于CRD机制和定制控制器实现。CRD是通过apiextensions-apiserver实现的。K8S集群可以动态定义并注册用户资源对象的schema，可以像操作其他内置资源对象一样通过kubectl创建和访问这些自定义对象。定制化控制器是用户可以在集群内部署的定制开发的控制器，与定制化资源CRD等结合起来解决特定的应用问题。这种模式比较适合作为SDN控制器云原生部署的实施方案。

Aggregated-server扩展模式：这种方式的设计思路是通过增加API的扩展性，使K8S的用户可以扩展自己的API服务器，而不需要更改核心代码。这种方式的优点还在于可以将开发工作分阶段进行，新的API先在单独的API服务器中开发，在稳定之后再把它集成在一起。这种模式比较适合K8S监控系统的实现与部署。apiextensions-apiserver和替代早期版本K8S监控Heapster的metrics-server都是采用这种模式实现的。

SDN控制器部署：K8S的SDN控制器的部署首先是创建SDN控制器和节点代理及CNI-Plugin部署和运行所需的服务账号、角色和角色绑定。定义角色的访问对象涉及哪些资源以及相应许可的操作。定义访问的主体，即服务账号，在特定名字空间中对相应角色、对象的访问授权；然后以Deployment的方式在主节点上部署SDN控制器，可采用ConfigMap实现SDN控制器的相关配置管理；在每个集群工作节点上以DaemonSet的方式部署SDN代理，其中的CNI-Plugin安装脚本容器负责在部署时安装CNI-Plugin插件和相应的网络配置等；以及通过CRD机制扩展相关的资源对象管理，实现相应的定制控制器进行K8S与SDN间的封装、对接、适配。

挂接Pod到容器网络

kubelet：kubelet运行在集群的每个节点上，负责节点层面的Pod管理，周期执行Pod状态的探测和上报功能，并提供相应的http服务代理的各种Pod或容器操作等功能。

在系统运行过程中，kubelet的配置协程通过监听Watch apiserver获取分配给该节点的Pod。Pod工作协程池通过事件队列接收从配置协程发来的Pod创建请求，调用相应的Pod管理、容器管理、设备管理等Manager模块，最终通过容器运行时（以及dockershim）与Docker和CNI-Plugin互动完成Pod的创建。PLEG（Pod Lifecycle Event Generator）协程会持续地通过容器运行时监视本节点Pod的状态，与相应的期望值进行比较，当发现状态变化时生成相应事件给Pod工作协程实现相应的同步处理以保证Pod正常工作。

除监听apiserver外，kubelet还支持监听本地静态配置文件创建Pod的功能。K8S集群主节点上的apiserver、controller-manager、scheduler以及etcd就是以这种静态Pod的方式由kubelet启动运行的。

CNI-Plugin：Docker在创建容器的过程中支持四种网络模式。bridge模式会为每个容器分配网络名字空间、IP地址等，并连接到本地的bridge上；host模式会共用主机的网络名字空间；none模式会分配给容器独立的网络名字空间，但不会对容器进行相关的网络配置；container模式是将新创建的容器和已经存在的某个容器共享网络名字空间。

kubelet在创建Pod过程中，首先通过容器运行时调用Docker以none模式创建Pod的SandBox，即pause容器，也就是在这个时间点kubelet调用CNI-plugin来进行相应的接口、IP、路由等网络相关配置任务的，即挂接Pod到容器网络上；然后调用Docker以container模式创建并运行init容器，共享SandBox的网络名字空间；最终调用Docker也是以container模式创建常规业务容器，同样共享SandBox的网络名字空间。

所以CNI-Plugin是在kubelet创建Pod时被直接或通过dockershim调用来为Pod的SandBox做网络配置的。原则上CNI-Plugin不包含“容器网络”主体项目租户、网络子网等的创建和管理等功能。从这个意义上我们可以理解CNI-Plugin的作用主要是kubelet在创建Pod时将之挂接到“容器网络”上。

SDN解决方案的价值

广义地讲SDN的基本功能是把可形式化的、繁琐的各种网络的监管控操作自动化以支持运维人员直观便捷地获取各种信息、执行各种操作、解决各种问题。狭义地讲SDN的核心技术主要包括OpenFlow模式等交换机的转发面流表流水线设计和相应的基于SDN控制器平台的应用开发等方面。

流表流水线设计

SDN转发面OpenFlow流表实际上可以理解为是对二层交换mac表、三层路由表、防火墙ACL策略表等的一种抽象。所以从原理上讲OpenFlow/OVS交换机可以特定化承载传统的二层交换、三层路由、以及各种ACL等功能。SDN这种转发面从特例到一般再到特例的演进过程中，其价值更体现在可以支持更多种千变万化的应用上，这就是SDN转发面流表流水线设计的核心。通常SDN网络解决方案的套路就是针对特定问题设计相应的流水线，并基于SDN控制器平台开发相应的应用配合起来形成整体的解决方案。OpenShift的SDN容器网络以及Neutron架构中的DVR、SFC就是比较典型的案例。而现阶段多数SDN解决方案的转发面通常是在经典的二层交换、三层路由基础之上扩展细粒度流表设计实现相应的Overlay/Underlay转发、策略、服务链功能等的。

控制器平台与应用

SDN控制器主要包括平台和应用两个层面。平台通常采用基于分布式内存存储的某开源方案，控制器集群遵循CAP理论约束，支持基于任务和功能的负载分割，实现相应的二层交换、三层路由、拓扑管理、规则下发、状态统计等功能。而各种应用的开发是与相应的转发面、流表流水线设计相配合实现相应的网络互联、安全隔离、服务链、网络SLA/QoS、以及监控分析可视化与闭环控制等功能。

SDN控制器的南向接口对接各种网元设备，可以是物理的、也可以是虚拟的；北向接口提供各种网络主体的管理操作，可以通过各种封装适应不同的应用场景与不同的云管平台对接；西向接口可以是与K8S各种相关资源对象的动态互动适配；而东向接口可以作为CNI-Server提供给kubelet的CNI-Plugin完成将Pod挂接到容器网络的相关操作。

SDN这种架构适用于物理Fabric网络的管控和/或服务器Overlay虚拟网络的管控；适用于OpenStack、vSphere、K8S的网络管控；适用于DCN、WAN，也适用于混合云；适用于网络主干的管控、资源池的管控，也适用于边缘互联的管控。

系统部署示例

一个典型的生产环境K8S和SDN容器网络部署除划分有各个网络平面外，服务器节点也可以拆分为不同的功能组。其中主节点组承担K8S集群的Master角色，主要运行apiserver、controller-manager、scheduler组件等；基础节点组属于K8S集群的工作节点，通过设置节点标签，只用于部署系统基础服务，包括注册仓库、三层路由、监控可视化、SDN控制器等；业务节点组也属于工作节点，用于运行业务系统的各种应用容器Pod。如果以OpenStack为参照的话，主节点组对应OpenStack的控制器节点；基础节点组部分功能对应OpenStack的网络节点；业务节点组则对应OpenStack的计算节点。

SDN解决方案包括在K8S场景下的应用可以支持业务应用弹性扩展、更新迭代；自动化可提高系统运行稳定、有效的运维排障；细粒度控制可以提高访问和数据的安全性。采用SDN技术实现K8S容器网络，SDN控制器基于K8S平台扩展机制的云原生部署，并与相应的生态组件形成SDN监管控一体化解决方案，可以更好地提高整个系统的运营水平，更有效地提升企业的核心竞争力。

人才短缺，压力过大，网络安全行业一点都不轻松

Tue, 02 Jul 2019 15:48:26 CST

近日，赛门铁克发布一项调查称，法国、英国和德国三个国家中近一半（48%）的网络安全行业领导者们认为他们的安全团队在与黑客、网络罪犯们的竞争中处于严重落后状态，马上就凉的那种。

网络安全形势的日益严峻，给本就已经疲惫不堪的安全从业人员带来了更大的压力。根据统计，在接受调查的网络安全从业者中已经有约64%的人在考虑辞职或已经辞职。

赛门铁克EMEA首席技术官Darren Thomson对此表示：“令人感到不安的是，这就像是你明知道危险就在眼前，却还是不去待见那些在你身前为你挡刀的人。当面对一个成长速度、能力水平比自己还强的对手时，如果你只关注自己的财物、数据在此刻有没有受到威胁，那么是远远不够的，你需要将眼光放长远，正视技术的差距并进行相应的战略投资。”

本次调查人数包括德、法、英三国在内共计3045人，通过调查也反映出了一个比较严重的问题：因为工作负荷太大和生活压力过重从而阻碍了安全人和行业的正常发展以及相关决策的制定，从而形成了一个恶性循环。

不到一半（占英国总数44%，英国共占据38%）的网络安全从业者们表示，他们所在的团队缺乏必要的技术能力来应对其所面对的安全威胁。而超过三分之一的人则表示他们的团队根本在现在庞大的工作量下正常应对大规模安全事件。

ENISA运营主管Steve Purser博士认为，当前的安全行业有很大的倦怠风险，很多人都处在极限运营状态。“当你看到他们的日常工作时间就什么都明白了。”

进攻和防护的差距仍在加大

随着技术变革速度的不断加快，网络犯罪分子所掌握的技术也越来越丰富并且日益精进，很多企业或网络安全团队都在努力跟上技术的发展以及对手的发展，然而安全行业人才缺口已是长久以来存在的问题，这个缺口越来越大也会导致这二者之间的差距越来越大。

研究表明，46%的人表示他们太忙没时间学技术，45%的人表示技术变化太快他们学不过来。另外，也还有近一半的人认为，现在的网络攻击者拥有的资源丰富程度是前所未有的，越来越多的网络犯罪成为有组织有预谋，甚至是国家政府支持的行动。伦敦大学金史密斯学院Chris Brauer博士表示，网络安全从业者在网络安全这一行业中是第一线人员，需要不断的与犯罪分子进行“军备竞赛”，这其中最重要的武器就是技术和人才。绝大多数人认为这是一项精彩绝伦充满着斗智斗勇的挑战，然而，这项工作却伴随着很高的安全风险，一不留神可能就是心理和生理的双重打击。长时间超负荷工作的人选择激流勇退的可能性会更高，在已经是缺人的状态下，这种情况所带来的风险比看起来更大。

对本就有限的网络安全人才的压力正逐渐成为企业和整个行业的压力，安全性和威胁在不断加大。

在调查中，约有四分之三的人表示自己低估了处理网络安全事件所需要花费的精力和条件；也有相同比例的人表示多数情况下自己根本没时间去正确的评估某一件事的威胁；还有超过三分之二的人认为很多已经发生了的网络安全事件都是本可以不发生的。

自从CISO这一职业出现以来，网络安全就成为了一个需要严肃对待的问题，互联网的格局已经发生了巨大的变化，来自网络的威胁已经常态化，成为按秒计算的状态，IT产业的复杂性呈指数级增长，想要同步防护和进攻的水平是一个不小的挑战。防御战略需要改变，设备的升级、人员的扩充、技术的增长是关键问题。

*参考来源： helpnetsecurity，Karunesh91编译，转载请注明来自FreeBuf.COM

使用DNSPOD的API实现动态域名

Thu, 27 Jun 2019 13:55:01 CST

标签： api DNSPOD 域名

0. 你得有一个 dnspod 帐号，并且把你的域名（例如 test.com ）解析迁移过去（略）

1. 添加一个子域名的 A 记录，例如 ddns.test.com 指向 127.0.0.1

$ export domain=test.com
$ export subdomain=ddns

2. 生成一个token：参考官方说明 https://support.dnspod.cn/Kb/showarticle/tsid/227/

【务必注意】需要用生成的 ID 和 Token 这两个字段来组合成一个完整的 Token，组合方式为："ID,Token"（用英文半角逗号分割），比如官方示例中，完整的 Token 为：13490,6b5976c68aba5b14a0558b77c17c3932 。

$ export token=13490,6b5976c68aba5b14a0558b77c17c3932

3. 获取必要信息: 域名和子域名的ID

$ curl -X POST https://dnsapi.cn/Record.List -d "login_token=${token}&format=json&domain=${domain}&sub_domain=${subdomain}"

返回结果为：{"status":{...}, "domain":{"id":640001, "name":"test.com", ...}, "info":{...}, "records":[{"id":"355300007", "name":"ddns", ...}]}

记录下对应域名的id 和子域名的id

$ export domain_id=640001
$ export subdomain_id=355300007

4. 获取外网ip

$ wanip=`nc ns1.dnspod.net 6666`

5. 更新记录

$ curl https://dnsapi.cn/Record.Ddns -d "login_token=${token}&format=json&domain_id=$domain_id&record_id=$record_id&sub_domain=$sub_domain&record_line=默认&value=$wanip"

= 完 =

（其实没完）其中 1、2、3 做完以后

6. 把 4、5 可以写到一个脚本里

$ vi dnspod.sh

#!/bin/bash

domain_id=640001
record_id=355300007
sub_domain=ddns

wanip=`nc ns1.dnspod.net 6666`
curl https://dnsapi.cn/Record.Ddns -d "login_token=${token}&format=json&domain_id=$domain_id&record_id=$record_id&sub_domain=$sub_domain&record_line=默认&value=$wanip"

7. 设置 crontab

$ crontab -e

引用

*/15 * * * * sh /path/to/dnspod.sh

您可能还对下面的文章感兴趣：

最萌域名.cat背后的故事：加泰与西班牙政府的暗战 [2017-10-15 09:27:45]
域名DNS相关术语 [2014-03-19 22:40:30]
域名相关的一些基本概念总结 [2012-11-11 23:47:37]
Apache用mod_rewrite配置子域名 [2011-09-04 22:47:02]
如何拿下简短的域名 [2011-03-07 22:45:33]
网址决定内容 [2010-10-13 08:26:34]
A记录,MX记录,CNAME记录,url转发,ns记录,动态记录 [2010-03-03 09:17:10]
全站换域名时利用nginx和javascript做简单友好的换域名跳转通知 [2009-11-04 11:31:18]
使用apache下的301设置来做域名的更换转移 [2009-10-28 20:44:20]
Apache、resin、rewrite泛域名、多域名设置 [2009-10-14 13:40:57]

HTTP API 认证授权术

Thu, 09 May 2019 21:37:29 CST

我们知道，HTTP是无状态的，所以，当我们需要获得用户是否在登录的状态时，我们需要检查用户的登录状态，一般来说，用户的登录成功后，服务器会发一个登录凭证（又被叫作Token），就像你去访问某个公司，在前台被认证过合法后，这个公司的前台会给你的一个访客卡一样，之后，你在这个公司内去到哪都用这个访客卡来开门，而不再校验你是哪一个人。在计算机的世界里，这个登录凭证的相关数据会放在两种地方，一个地方在用户端，以Cookie的方式（一般不会放在浏览器的Local Storage，因为这很容易出现登录凭证被XSS攻击），另一个地方是放在服务器端，又叫Session的方式（SessonID存于Cookie）。

但是，这个世界还是比较复杂的，除了用户访问，还有用户委托的第三方的应用，还有企业和企业间的调用，这里，我想把业内常用的一些 API认证技术相对系统地总结归纳一下，这样可以让大家更为全面的了解这些技术。 注意，这是一篇长文！

本篇文章会覆盖如下技术：

HTTP Basic
Digest Access
App Secret Key + HMAC
JWT – JSON Web Tokens
OAuth 1.0 – 3 legged & 2 legged
OAuth 2.0 – Authentication Code & Client Credential

HTTP Basic

HTTP Basic 是一个非常传统的API认证技术，也是一个比较简单的技术。这个技术也就是使用 username和 password 来进行登录。整个过程被定义在了 RFC 2617 中，也被描述在了 Wikipedia: Basic Access Authentication 词条中，同时也可以参看 MDN HTTP Authentication

其技术原理如下：

把 username和 password 做成 username:password 的样子（用冒号分隔）
进行Base64编码。 Base64("username:password") 得到一个字符串（如：把 haoel:coolshell 进行base64 后可以得到 aGFvZW86Y29vbHNoZWxsCg ）
把 aGFvZW86Y29vbHNoZWxsCg放到HTTP头中 Authorization 字段中，形成 Authorization: Basic aGFvZW86Y29vbHNoZWxsCg，然后发送到服务端。
服务端如果没有在头里看到认证字段，则返回401错，以及一个个 WWW-Authenticate: Basic Realm='HelloWorld' 之类的头要求客户端进行认证。之后如果没有认证通过，则返回一个401错。如果服务端认证通过，那么会返回200。

我们可以看到，使用Base64的目的无非就是为了把一些特殊的字符给搞掉，这样就可以放在HTTP协议里传输了。而这种方式的问题最大的问题就是把用户名和口令放在网络上传，所以，一般要配合TLS/SSL的安全加密方式来使用。我们可以看到 JIRA Cloud 的API认证支持HTTP Basic 这样的方式。

但我们还是要知道，这种把用户名和密码同时放在公网上传输的方式有点不太好，因为Base64不是加密协议，保是编码协议，所以就算是有HTTPS作为安全保护，给人的感觉还是不放心。

Digest Access

中文称“HTTP 摘要认证”，最初被定义在了 RFC 2069 文档中（后来被 RFC 2617 引入了一系列安全增强的选项；“保护质量”(qop)、随机数计数器由客户端增加、以及客户生成的随机数）。

其基本思路是，请求方把用户名口令和域做一个MD5 – MD5(username:realm:password) 然后传给服务器，这样就不会在网上传用户名和口令了，但是，因为用户名和口令基本不会变，所以，这个MD5的字符串也是比较固定的，因此，这个认证过程在其中加入了两个事，一个是 nonce 另一个是 qop

首先，调用方发起一个普通的HTTP请求。比如： GET /coolshell/admin/ HTTP/1.1
服务端自然不能认证能过，服务端返回401错误，并且在HTTP头里的 WWW-Authenticate 包含如下信息：

 WWW-Authenticate: Digest realm="testrealm@host.com",
                        qop="auth,auth-int",
                        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                        opaque="5ccc069c403ebaf9f0171e9517f40e41"

其中的 nonce 为服务器端生成的随机数，然后，客户端做 HASH1=MD5(MD5(username:realm:password):nonce:cnonce) ，其中的 cnonce 为客户端生成的随机数，这样就可以使得整个MD5的结果是不一样的。
如果 qop 中包含了 auth ，那么还得做 HASH2=MD5(method:digestURI) 其中的 method 就是HTTP的请求方法（GET/POST…）， digestURI 是请求的URL。
如果 qop 中包含了 auth-init ，那么，得做 HASH2=MD5(method:digestURI:MD5(entityBody)) 其中的 entityBody 就是HTTP请求的整个数据体。
然后，得到 response = MD5(HASH1:nonce:nonceCount:cnonce:qop:HASH2) 如果没有 qop则 response = MD5(HA1:nonce:HA2)
最后，我们的客户端对服务端发起如下请求—— 注意HTTP头的 Authorization: Digest ...

GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
                     realm="testrealm@host.com",
                     nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                     uri="%2Fcoolshell%2Fadmin",
                     qop=auth,
                     nc=00000001,
                     cnonce="0a4f113b",
                     response="6629fae49393a05397450978507c4ef1",
                     opaque="5ccc069c403ebaf9f0171e9517f40e41"

维基百科上的 Wikipedia: Digest access authentication 词条非常详细地描述了这个细节。

摘要认证这个方式会比之前的方式要好一些，因为没有在网上传递用户的密码，而只是把密码的MD5传送过去，相对会比较安全，而且，其并不需要是否TLS/SSL的安全链接。但是，别看这个算法这么复杂，最后你可以发现，整个过程其实关键是用户的password，这个password如果不够得杂，其实是可以被暴力破解的，而且，整个过程是非常容易受到中间人攻击——比如一个中间人告诉客户端需要一个。

App Secret Key + HMAC

先说HMAC技术，这个东西来自于MAC – Message Authentication Code，是一种用于给消息签名的技术，也就是说，我们怕消息在传递的过程中被人修改，所以，我们需要用对消息进行一个MAC算法，得到一个摘要字串，然后，接收方得到消息后，进行同样的计算，然后比较这个MAC字符串，如果一致，则表明没有被修改过（整个过程参看下图）。而HMAC – Hash-based Authenticsation Code，指的是利用Hash技术完成这一工作，比如：SHA-256算法。

（图片来自 Wikipedia – MAC 词条）

我们再来说App ID，这个东西跟验证没有关系，只是用来区分，是谁来调用API的，就像我们每个人的身份证一样，只是用来标注不同的人，不是用来做身份认证的。与前面的不同之处是，这里，我们需要用App ID 来映射一个用于加密的密钥，这样一来，我们就可以在服务器端进行相关的管理，我们可以生成若干个密钥对（AppID, AppSecret），并可以有更细粒度的操作权限管理。

把AppID和HMAC用于API认证，目前来说，玩得最好最专业的应该是AWS了，我们可以通过 S3的API请求签名文档看到AWS是怎么玩的。整个过程还是非常复杂的，可以通过下面的图片流程看个大概。基本上来说，分成如下几个步骤：

把HTTP的请求（方法、URI、查询字串、头、签名头，body）打个包叫 CanonicalRequest，作个SHA-256的签名，然后再做一个base16的编码
把上面的这个签名和签名算法 AWS4-HMAC-SHA256、时间戳、Scop，再打一个包，叫 StringToSign。
准备签名，用 AWSSecretAccessKey来对日期签一个 DataKey，再用 DataKey 对要操作的Region签一个 DataRegionKey ，再对相关的服务签一个 DataRegionServiceKey ，最后得到 SigningKey.
用第三步的 SigningKey来对第二步的 StringToSign 签名。

最后，发出HTTP Request时，在HTTP头的 Authorization字段中放入如下的信息：

Authorization: AWS4-HMAC-SHA256 
               Credential=AKIDEXAMPLE/20150830/us-east-1/iam/aws4_request, 
               SignedHeaders=content-type;host;x-amz-date, 
               Signature=5d672d79c15b13162d9279b0855cfba6789a8edb4c82c400e06b5924a6f2b5d7

其中的 AKIDEXAMPLE 是 AWS Access Key ID，也就是所谓的 AppID，服务器端会根据这个AppID来查相关的 Secret Access Key，然后再验证签名。如果，你对这个过程有点没看懂的话，你可以读一读这篇文章——《 Amazon S3 Rest API with curl》这篇文章里有好些代码，代码应该是最有细节也是最准确的了。

这种认证的方式好处在于，AppID和AppSecretKey，是由服务器的系统开出的，所以，是可以被管理的，AWS的IAM就是相关的管理，其管理了用户、权限和其对应的AppID和AppSecretKey。但是不好的地方在于，这个东西没有标准，所以，各家的实现很不一致。比如： Acquia 的 HMAC，微信的签名算法（这里，我们需要说明一下，微信的API没有遵循HTTP协议的标准，把认证信息放在HTTP 头的 Authorization 里，而是放在body里）

JWT – JSON Web Tokens

JWT是一个比较标准的认证解决方案，这个技术在Java圈里应该用的是非常普遍的。JWT签名也是一种MAC（ Message Authentication Code）的方法。JWT的签名流程一般是下面这个样子：

用户使用用户名和口令到认证服务器上请求认证。
认证服务器验证用户名和口令后，以服务器端生成JWT Token，这个token的生成过程如下：
- 认证服务器还会生成一个 Secret Key（密钥）
- 对JWT Header和 JWT Payload分别求Base64。在Payload可能包括了用户的抽象ID和的过期时间。
- 用密钥对JWT签名 HMAC-SHA256(SecertKey, Base64UrlEncode(JWT-Header)+'.'+Base64UrlEncode(JWT-Payload));
然后把 base64(header).base64(payload).signature 作为 JWT token返回客户端。
客户端使用JWT Token向应用服务器发送相关的请求。这个JWT Token就像一个临时用户权证一样。

当应用服务器收到请求后：

应用服务会检查 JWT Token，确认签名是正确的。
然而，因为只有认证服务器有这个用户的Secret Key（密钥），所以，应用服务器得把JWT Token传给认证服务器。
认证服务器通过JWT Payload 解出用户的抽象ID，然后通过抽象ID查到登录时生成的Secret Key，然后再来检查一下签名。
认证服务器检查通过后，应用服务就可以认为这是合法请求了。

我们可以看以，上面的这个过程，是在认证服务器上为用户动态生成 Secret Key的，应用服务在验签的时候，需要到认证服务器上去签，这个过程增加了一些网络调用，所以，JWT除了支持HMAC-SHA256的算法外，还支持RSA的非对称加密的算法。

使用RSA非对称算法，在认证服务器这边放一个私钥，在应用服务器那边放一个公钥，认证服务器使用私钥加密，应用服务器使用公钥解密，这样一来，就不需要应用服务器向认证服务器请求了，但是，RSA是一个很慢的算法，所以，虽然你省了网络调用，但是却费了CPU，尤其是Header和Payload比较长的时候。所以，一种比较好的玩法是，如果我们把header 和 payload简单地做SHA256，这会很快，然后，我们用RSA加密这个SHA256出来的字符串，这样一来，RSA算法就比较快了，而我们也做到了使用RSA签名的目的。

最后，我们只需要使用一个机制在认证服务器和应用服务器之间定期地换一下公钥私钥对就好了。

这里强烈建议全文阅读 Anglar 大学的《 JSW：The Complete Guide to JSON Web Tokens》

OAuth 1.0

OAuth也是一个API认证的协议，这个协议最初在2006年由Twitter的工程师在开发OpenID实现的时候和社交书签网站Ma.gnolia时发现，没有一种好的委托授权协议，后来在2007年成立了一个OAuth小组，知道这个消息后，Google员工也加入进来，并完善有善了这个协议，在2007年底发布草案，过一年后，在2008年将OAuth放进了IETF作进一步的标准化工作，最后在2010年4月，正式发布OAuth 1.0，即： RFC 5849 （这个RFC比起TCP的那些来说读起来还是很轻松的），不过，如果你想了解其前身的草案，可以读一下 OAuth Core 1.0 Revision A ，我在下面做个大概的描述。

根据RFC 5849，可以看到 OAuth 的出现，目的是为了，用户为了想使用一个第三方的网络打印服务来打印他在某网站上的照片，但是，用户不想把自己的用户名和口令交给那个第三方的网络打印服务，但又想让那个第三方的网络打印服务来访问自己的照片，为了解决这个授权的问题，OAuth这个协议就出来了。

这个协议有三个角色：
- User（照片所有者-用户）
- Consumer（第三方照片打印服务）
- Service Provider（照片存储服务）
这个协义有三个阶段：
- Consumer获取Request Token
- Service Provider 认证用户并授权Consumer
- Consumer获取Access Token调用API访问用户的照片

整个授权过程是这样的：

Consumer（第三方照片打印服务）需要先上Service Provider获得开发的 Consumer Key 和 Consumer Secret
当 User 访问 Consumer 时，Consumer 向 Service Provide 发起请求请求Request Token （需要对HTTP请求签名）
Service Provide 验明 Consumer 是注册过的第三方服务商后，返回 Request Token（ oauth_token）和 Request Token Secret （ oauth_token_secret）
Consumer 收到 Request Token 后，使用HTTP GET 请求把 User 切到 Service Provide 的认证页上（其中带上Request Token），让用户输入他的用户和口令。
Service Provider 认证 User 成功后，跳回 Consumer，并返回 Request Token （ oauth_token）和 Verification Code（ oauth_verifier）
接下来就是签名请求，用Request Token 和 Verification Code 换取 Access Token （ oauth_token）和 Access Token Secret ( oauth_token_secret)
最后使用Access Token 访问用户授权访问的资源。

下图附上一个Yahoo!的流程图可以看到整个过程的相关细节。

因为上面这个流程有三方：User，Consumer 和 Service Provide，所以，又叫 3-legged flow，三脚流程。OAuth 1.0 也有不需要用户参与的，只有Consumer 和 Service Provider 的，也就是 2-legged flow 两脚流程，其中省掉了用户认证的事。整个过程如下所示：

Consumer（第三方照片打印服务）需要先上Service Provider获得开发的 Consumer Key 和 Consumer Secret
Consumer 向 Service Provide 发起请求请求Request Token （需要对HTTP请求签名）
Service Provide 验明 Consumer 是注册过的第三方服务商后，返回 Request Token（ oauth_token）和 Request Token Secret （ oauth_token_secret）
Consumer 收到 Request Token 后，直接换取 Access Token （ oauth_token）和 Access Token Secret ( oauth_token_secret)
最后使用Access Token 访问用户授权访问的资源。

最后，再来说一说OAuth中的签名。

我们可以看到，有两个密钥，一个是Consumer注册Service Provider时由Provider颁发的 Consumer Secret，另一个是 Token Secret。
签名密钥就是由这两具密钥拼接而成的，其中用 &作连接符。假设 Consumer Secret 为 j49sk3j29djd 而 Token Secret 为 dh893hdasih9那个，签名密钥为： j49sk3j29djd&dh893hdasih9
在请求Request/Access Token的时候需要对整个HTTP请求进行签名（使用HMAC-SHA1和HMAC-RSA1签名算法），请求头中需要包括一些OAuth需要的字段，如：
- Consumer Key ：也就是所谓的AppID
- Token： Request Token 或 Access Token
- Signature Method ：签名算法比如：HMAC-SHA1
- Timestamp：过期时间
- Nonce：随机字符串
- Call Back：回调URL

下图是整个签名的示意图：

图片还是比较直观的，我就不多解释了。

OAuth 2.0

在前面，我们可以看到，从Digest Access，到AppID+HMAC，再到JWT，再到OAuth 1.0，这些个API认证都是要向Client发一个密钥（或是用密码）然后用HASH或是RSA来签HTTP的请求， 这其中有个主要的原因是，以前的HTTP是明文传输，所以，在传输过程中很容易被篡改，于是才搞出来一套的安全签名机制，所以，这些个认证的玩法是可以在HTTP明文协议下玩的。

这种使用签名方式大家可以看到是比较复杂的，所以，对于开发者来说，也是很不友好的，在组织签名的那些HTTP报文的时候，各种，URLEncode和Base64，还要对Query的参数进行排序，然后有的方法还要层层签名，非常容易出错，另外，这种认证的安全粒度比较粗，授权也比较单一，对于有终端用户参与的移动端来说也有点不够。所以，在2012年的时候，OAuth 2.0 的 RFC 6749 正式放出。

OAuth 2.0依赖于TLS/SSL的链路加密技术（HTTPS），完全放弃了签名的方式，认证服务器再也不返回什么 token secret 的密钥了，所以，OAuth 2.0是完全不同于1.0 的，也是不兼容的。目前，Facebook 的 Graph API 只支持OAuth 2.0协议，Google 和 Microsoft Azure 也支持Auth 2.0，国内的微信和支付宝也支持使用OAuth 2.0。

下面，我们来重点看一下OAuth 2.0的两个主要的Flow：

一个是Authorization Code Flow，这个是 3 legged 的
一个是Client Credential Flow，这个是 2 legged 的。

Authorization Code Flow

Authorization Code 是最常使用的OAuth 2.0的授权许可类型，它适用于用户给第三方应用授权访问自己信息的场景。这个Flow也是OAuth 2.0四个Flow中我个人觉得最完整的一个Flow，其流程图如下所示。

下面是对这个流程的一个细节上的解释：

1）当用户（Resource Owner）访问第三方应用（Client）的时候，第三方应用会把用户带到认证服务器（Authorization Server）上去，主要请求的是 /authorize API，其中的请求方式如下所示。

https://login.authorization-server.com/authorize?
        client_id=6731de76-14a6-49ae-97bc-6eba6914391e
        &response_type=code
        &redirect_uri=http%3A%2F%2Fexample-client.com%2Fcallback%2F
        &scope=read
        &state=xcoiv98CoolShell3kch

其中：

- client_id为第三方应用的App ID
- response_type=code为告诉认证服务器，我要走Authorization Code Flow。
- redirect_uri意思是我跳转回第三方应用的URL
- scope意是相关的权限
- state 是一个随机的字符串，主要用于防CSRF攻击。

2）当Authorization Server收到这个URL请求后，其会通过 client_id来检查 redirect_uri和 scope是否合法，如果合法，则弹出一个页面，让用户授权（如果用户没有登录，则先让用户登录，登录完成后，出现授权访问页面）。

3）当用户授权同意访问以后，Authorization Server 会跳转回 Client ，并以其中加入一个 Authorization Code。如下所示：

https://example-client.com/callback?
        code=Yzk5ZDczMzRlNDEwYlrEqdFSBzjqfTG
        &state=xcoiv98CoolShell3kch

我们可以看到，

- 请流动的链接是第 1）步中的 redirect_uri
- 其中的 state 的值也和第 1）步的 state一样。

4）接下来，Client 就可以使用 Authorization Code 获得 Access Token。其需要向 Authorization Server 发出如下请求。

POST /oauth/token HTTP/1.1
Host: authorization-server.com
 
code=Yzk5ZDczMzRlNDEwYlrEqdFSBzjqfTG
&grant_type=code
&redirect_uri=https%3A%2F%2Fexample-client.com%2Fcallback%2F
&client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&client_secret=JqQX2PNo9bpM0uEihUPzyrh

5）如果没什么问题，Authorization 会返回如下信息。

{
  "access_token": "iJKV1QiLCJhbGciOiJSUzI1NiI",
  "refresh_token": "1KaPlrEqdFSBzjqfTGAMxZGU",
  "token_type": "bearer",
  "expires": 3600,
  "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciO.eyJhdWQiOiIyZDRkM..."
}

其中，

- access_token就是访问请求令牌了
- refresh_token用于刷新 access_token
- id_token 是JWT的token，其中一般会包含用户的OpenID

6）接下来就是用 Access Token 请求用户的资源了。

GET /v1/user/pictures
Host: https://example.resource.com

Authorization: Bearer iJKV1QiLCJhbGciOiJSUzI1NiI

Client Credential Flow

Client Credential 是一个简化版的API认证，主要是用于认证服务器到服务器的调用，也就是没有用户参与的的认证流程。下面是相关的流程图。

这个过程非常简单，本质上就是Client用自己的 client_id和 client_secret向Authorization Server 要一个 Access Token，然后使用Access Token访问相关的资源。

请求示例

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=czZCaGRSa3F0Mzpn
&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

返回示例

{
  "access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
  "scope":"create"
}

这里，容我多扯一句，微信公从平台的开发文档中，使用了OAuth 2.0 的 Client Credentials的方式（参看文档“ 微信公众号获取access token”），我截了个图如下所谓。我们可以看到，微信公众号使用的是GET方式的请求，把AppID和AppSecret放在了URL中，虽然这也符合OAuth 2.0，但是并不好，因为大多数网关代理会把整个URI请求记到日志中。我们只要脑补一下腾讯的网关的Access Log，里面的日志一定会有很多的各个用户的AppID和AppSecret……

小结

讲了这么多，我们来小结一下（下面的小结可能会有点散）

两个概念和三个术语

区分两个概念：Authentication（认证）和 Authorization （授权），前者是证明请求者是身份，就像身份证一样，后者是为了获得权限。身份是区别于别人的证明，而权限是证明自己的特权。Authentication为了证明操作的这个人就是他本人，需要提供密码、短信验证码，甚至人脸识别。Authorization 则是不需要在所有的请求都需要验人，是在经过Authorization后得到一个Token，这就是Authorization。就像护照和签证一样。
区分三个概念：编码Base64Encode、签名HMAC、加密RSA。编码是为了更的传输，等同于明文，签名是为了信息不能被篡改，加密是为了不让别人看到是什么信息。

明白一些初衷

使用复杂地HMAC哈希签名方式主要是应对当年没有TLS/SSL加密链路的情况。
JWT把 uid 放在 Token中目的是为了去掉状态，但不能让用户修改，所以需要签名。
OAuth 1.0区分了两个事，一个是第三方的Client，一个是真正的用户，其先拿Request Token，再换Access Token的方法主要是为了把第三方应用和用户区分开来。
用户的Password是用户自己设置的，复杂度不可控，服务端颁发的Serect会很复杂，但主要目的是为了容易管理，可以随时注销掉。
OAuth 协议有比所有认证协议有更为灵活完善的配置，如果使用AppID/AppSecret签名的方式，又需要做到可以有不同的权限和可以随时注销，那么你得开发一个像AWS的IAM这样的账号和密钥对管理的系统。

等保2.0将至，解读新标准的变化

Mon, 29 Apr 2019 09:30:35 CST

*本文原创作者：宇宸@默安科技合规研究小组，本文属于FreeBuf原创奖励计划，未经许可禁止转载

引言

中央网络安全和信息化领导小组提出：“没有网络安全就没有国家安全，没有信息化就没有现代化，中国要由网络大国走向网络强国。”首先，我们来看一下近几年来国家层面网络安全工作的开展情况：

2014年2月27日，中共中央网络安全和信息化领导小组成立

2014年，开始每年举办网络安全宣传周

2015年6月-2016年10月，审议网络安全法草案

2017年6月1日，网络安全法实施，强制要求等级保护工作，强调关键基础设施三同步

2018年3月23日，公安部发布《网络安全等级保护测评机构管理办法》

2018年6月27日，公安部公布《网络安全等级保护条例（征求意见稿）》

2018年11月30日，公安部网络安全保卫局公布《互联网个人信息安全保护指引》（征求意见稿）

2019年，预计实施等保2.0

本文尝试从《网络安全法》的角度介绍关键信息基础设施和等级保护安全工作的核心，同时对等保 2.0通用安全部分的变化进行分析和解读，旨在让大家了解等级保护制度的重要性和新标准的变化。

等级保护工作的核心

《网络安全法》明确等级保护工作的核心主要包括：

关键信息基础设施的定义；

关键信息基础设施的安全保护义务（第三十四条运营者设置专门机构和负责人、网络安全教育培训、容灾备份、应急预案和演练等）；

敏感信息保护（第三十七条境内收集产生的个人信息和重要数据应当在境内存储。确需向境外提供的，应进行安全评估）；

风险评估（第三十八条运营者每年至少组织一次安全风险检测评估，并评估情况和改进措施报相关部门）。

关键信息基础设施分为三类：

《网络安全法》规定，等级保护是我国信息安全保障的基本制度。《网络安全法》第二十一条规定，国家实行网络安全等级保护制度。网络运营者应当按照网络安全等级保护制度的要求，履行下列全保护义务：保障网络免受干扰、破坏或者未经授权的访问，防止网络数据泄露或者被窃取、篡改。

等级保护范围内重要信息系统所涵盖的行业包括：能源、金融、交通、水利、医疗卫生、环境保护、工业制造、市政、电信与互联网、广播电视及政府部门。

等保 VS ISO27001

国家对网络安全越来越重视，企业自身也开始关注安全问题。在这样的环境下，我觉得大家要转换下思维，不要再把等保当做一种应付上级检查的被动性工作、不要因为开展业务不做不行才去搞、不要觉得反正又没出事，不用担心。现在的现状是这样，一提等保就觉得Low，就是应付检查的……一提ISO27001就觉得高大上，感觉很先进，而且是完整的体系。

但实际上真的如此吗？下面，我来给大家对比一下。

这么一看是不是其实也没差多少呢？再举个细节的例子：

左边是27001附录A的控制措施，右边是等保2.0中三级系统物理与环境安全位置和访问控制的要求项。其实差不多，只是表述不同。27001讲的是PDCA，是一个不断循环的工作。等保讲的是“定级-备案-测评-整改-监督”，同样是一个循环的过程。

我的态度一直如此。为了做好安全工作，体系和标准只是指导文件和指南，落地要结合实际，做到什么程度需要根据企业环境而定，不一定要所有都做，也不是为了应付做做样子。安全工作技术上有难度，管理上难度更大，是一个不断循环和改进的过程，因此等保是嵌入到安全建设中的一项工作，而不是为了过等保去搞安全。

等保2.0的变化

去年比较火的大概是《GDPR》，今年比较火的好像是《等保 2.0》，小道消息可能4月有望发布，不过现在已是4月底了，可能要推迟。广东的兄弟说那边已经确定了，7月正式实施，估计应该年内会正式出台。

等级保护制度系统分为五个级别，五级系统属国家级、国防类的系统（核电站、军用通信系统），所以我们很难接触的到，标准中也没有五级系统的检查要求。四级系统量级较大，比如支付宝、银行总行系统、国家电网系统，也是我们很少会接触到的（这里是指去做等级测评），因此我们通常说等保一般是指三级和二级系统（因为一级系统要求简单，不作为重点监管对象）。本文重点放在等保2.0中三级系统要求的变化。

测评分数变化

以前的等保测评分数及格线是60分，近几年个别省份将分数线提高到70分，据传闻互金类系统要90分。同样是听说，等保2.0新的及格线是75以上。

结构的变化，先看新标准安全通用要求和旧版的变化：

控制大项从原来的10项，改为8项，其实就是合并了数据和应用、机构和人员。

要求项的变化

这其中要求项的细节变化可以对比新旧标准自己看一下，就不详细展开来说了。

PS：这里有一点要提下，就是等保中新增了 个人信息保护的要求，也是因为近来越来越多的安全事件以及欧盟保护条例的出台，国内也开始重视个人隐私问题了。

不过这只是通用要求，新标准分成了5个部分（也就是5个标准）分别是：

《网络安全等级保护基本要求第1部分安全通用要求》

《网络安全等级保护基本要求第2部分云计算安全扩展要求》

《网络安全等级保护基本要求第3部分移动互联安全扩展要求》

《网络安全等级保护基本要求第4部分物联网安全扩展要求》

《网络安全等级保护基本要求第5部分工业控制系统安全扩展要求》

在我看来感觉挺好，多了几个以前没接触过的方向。因为我之前一直做传统安全，通用部分比较了解，现在的公司做云计算安全，所以云这部分也相对了解一些。之前检查过几家工控单位，对工控系统安全算是知道些皮毛吧。其他两块就比较陌生了。同样的，对于某些甲方的兄弟来说，这也是要命的，新标准实施后，所有定过级的系统估计全都要重新定级备案一次，所以这块未来几年的市场应该还可以，不管甲方还是乙方或是测评中心，都有事要搞了。

等保2.0技术要求的变化

再来看看细节的变化，由于没有实际项目案例，外加标准没正式发布，这里只是以最终稿版本来对比，另外篇幅问题，只对通用要求部分进行简要分析。

物理与环境安全部分

32项调整为22项。这部分没太大变化，只有几个细节点，这里说一下。

1.明确提出机房 视频监控系统的要求，旧标准里没有，这部分就是要求对机房横向和纵向都要有视频监控，整个机房不能存在监控死角。

2.防静电要求明确举例说明采用 静电消除器、 防静电手环；对于静电防护要求更为细节化，这回操作服务器时都要预先消除人体所带静电，合作和佩戴防静电手环来操作。

3.供电部分不再要求备用供电系统，但保留 冗余电力电缆的要求，这里说的冗余电力不是说你在市政那边拉过来两条电缆就可以了，而是两条不用电井的电缆，这样才算冗余，因为出现停电同一电井或线路的电缆你拉多少条都是单链路的。

4.在云计算扩展要求中新增，物理机房必须要在境内。

网络和通信安全部分

33项不变。新标准减少了结构安全、边界完整性检查、网络设备防护三个控制点，增加了网络架构、通信传输、边界防护、集中管控四个控制点。

1.删除了重要系统不能直接外连外部网络的要求，删除了按业务优先级分配带宽的SLA服务；新标准只要求通信线路、关键网络设备冗余性。

2.在边界完整性间检查中，提出了 无线网络的安全要求，无线网络接入必须要通过 受控边界，也就是说无线网络接入到系统要通过安全设备进行访问控制和授权后才可以访问互联网。

3.访问控制中新增 内容过滤管理，要求在关键网络节点处对进出网络的信息内容进行过滤，实现对内容的访问控制。这里的内容猜测指的是黄赌毒反动这类的不良信息。曾经接触过一些媒体公司，他们也有比较完善的内容过滤机制，不过最终还是要人来做这件事情，所以目前主流的各大媒体，都有自己的内容审核团队7×24倒班，1审是机器过滤，2审是人工初审，3审是人工复审，然后发布到网上。所以这部分内容想要完全靠技术手段实现，可能暂时不太现实。

4.入侵防范的新要求，能够检测 由内对外和由外对内的攻击，这里就是我们常说的南北向双向检测，这就要求我们配置策略的时候要双向应用，在接口的in和out方向都启用策略。

5.恶意代码防范的新要求，第一次明确要求对 垃圾邮件进行防护(之前也提过但没指定垃圾邮件)，估计不少企业要额外采购这块的设备或软件了。

6.日志审计方面要求变化由以前的留存6个月改为 符合法律法规要求，这个就不好说具体怎么操作了，不过刚开始还是按照6个月留存，看后续怎么执行。此外还要求，能对远程访问的用户行为、访问互联网的用户行为等单独进行行为审计和数据分析，这块感觉要求有点逆天了，乍看好像是说的机器学习分析用户行为，如果真是像阿里那种通过自动学习生成用户的行为习惯准则，用来判断用户的违规行为检测，那么对于甲方来说就难搞了。而且这里要求的是能够访问互联网的用户(也包括内部员工)，还有远程访问系统的用户，这些日志都要能够查询并进行行为分析。

集中管控是全新部分，这里贴一下原文要求，解读暂时不好说，还有一些不确定因素：

a) 应划分出特定的管理区域，对分布在网络中的安全设备或安全组件进行管控（安全域划分）；

b) 应能够建立一条安全的信息传输路径，对网络中的安全设备或安全组件进行管理（堡垒机）；

c) 应对网络链路、安全设备、网络设备和服务器等的运行状况进行集中监测（监控平台）；

d) 应对分散在各个设备上的审计数据进行收集汇总和集中分析（日志审计系统）；

e) 应对安全策略、恶意代码、补丁升级等安全相关事项进行集中管理（资产统一管理平台）；

f) 应能对网络中发生的各类安全事件进行识别、报警和分析（态势感知）。

网络设备防护整个部分删除，移动到设备和计算安全中。

设备和计算安全

32项调整为26项，删除剩余信息保护要求：

1.身份鉴别中两种鉴别方式有明显变化，采用两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用 动态口令、密码技术或生物技术来实现。传统的用户名密码方式将渐渐被淘汰，取而代之的是无密码登录,也就是生物识别技术，像指纹、声音、人脸、视网膜等登录。

2.恶意代码防范要求也有明显变化，应采用免受恶意代码攻击的技术措施或可信验证机制对系统程序、应用程序和 重要配置文件/参数进行 可信执行验证，并在 检测到其完整性受到破坏时采取恢复措施。

这项要求也是比较繁琐的，提出对配置文件及参数的可信执行进行验证，同时发现完整性出现问题要有应对的恢复措施。属于可信计算的范畴，查阅了一些材料，大概解释下。

可信计算的定义：如果一个实体的行为总是按照预期的方式和目标进行，那它就是可信的。

这个定义从安全角度来看，其实并不安全，比如一台中毒的主机，他也是按照预期的方式和目标去工作的，那么按照可信计算的定义，这台主机也是可信的。

所以，从容错计算发展来的可信并不等于安全，但可以认为可信是安全的前提。可信计算将可预期性与正确性作为最终的目标，自此，可信计算有了安全特色。

国内目前叫做可信3.0，可信计算有两种可信环境。在可信信任链的传递过程中，根据度量的方式不同，分为动态信任链与静态信任链两个链条。静态信任链度量平台的配置，动态信任链度量系统软件、软件配置与软件策略。

静态信任链

静态信任链在开机后即可度量，如Intel TXT技术，将度量代码写入处理器中，获得了更早的度量时间。在CPU未参与的环境中，一般是将度量代码写入BIOS对系统进行度量，确保链条的完整性。

静态信任链的主旨是：度量从硬件开始，度量值由TPM来防护免受篡改，代码执行前要度量。

静态信任链既无法对系统运行进行度量，受运行空间的限制，也很难支撑庞大的系统软件，更重要的是这些静态度量在每次开机后仅仅运行一次，对于一个服务器系统，在整个生命周期的运行中，其开机次数少之又少，仅仅依靠静态信任链建立可信环境显然是不够的。

动态信任链

静态测量从加电开始，按照顺序加载可信模块形成可信环境，但静态信任链不支持大型系统软件的检测，这就需要通过CPU参与建立另外一种信任环境—动态信任链。动态信任链不依赖系统加电启动过程，允许系统可以从任意一个不被信任的状态为测量起点来建立信任链。值得注意的是，在动态信任链的建立过程中，基于X86的环境，需要一个RING0级别的基础系统作为可信基的运行环境，以期获得更高的安全期望。动态信任链可以根据用户需要在不重启系统的情况下基于策略随时重新构建信任链。

动态信任链的建立与应用，使得略显“僵化”的可信计算体系有了更灵活的防护方式，也使得各类基于动态信任链原理的“白名单”软件系统在工业界得到广泛应用。

对可信计算有兴趣的可以看下这篇文章： https://mp.weixin.qq.com/s/HoF9DqBgudUJeP29L5vkzQ

本条的要求猜测，是要通过可信计算技术来实现对系统中应用和配置文件、参数进行验证，保障系统在可信环境下运行。这块接触的不多，算比较新的技术。

应用和数据安全

39项调整为33项。以前是两个部分，现在整合到一起，还是比较靠谱的。减少了通信完整性、通信保密性和抗抵赖三个控制点，增加了个人信息保护控制点。

1.新增要求点， 应强制用户首次登录时修改初始口令。以前是没有明确要求的，都是大家引申出来的，所以不是强制的，限制是必须要做了。

2.新增要求点， 用户身份鉴别信息丢失或失效时，应采用技术措施确保鉴别信息重置过程的安全。个人理解，这部分在SDL的威胁建模里见过，举个例子：用户忘记密码，要重置密码，这个过程必须要回答密保问题或是验证码发送到手机，确认身份后才能重置。但有的系统，没有这个验证，直接可以重置密码，这就属于设计上的缺陷。不过具体的情况，还是那句话，等实施再看。

3.新增要求点， 在故障发生时，应自动保存易失性数据和所有状态，保证系统能够进行恢复。这里指的应该是两部分，系统自身的数据保护以及用户的数据保护。系统自身的就不用过多解释了。用户的数据，举个简单例子，论坛编辑帖子时的自动保存功能，出现问题时，过几天再来打开编辑页面，能再草稿里找到之前的文本，不会消失。

新增模块，个人信息保护：

应仅采集和保存业务必需的用户个人信息；

应禁止未授权访问和非法使用用户个人信息。

理解起来不难，技术实现起来有点麻烦，管理上更难流程化标准化，所以这块其实还是很重要的部分。最近公安那边也发布了《互联网个人信息安全保护指南》，大家可以参考指南内容来配合等保个人信息这块的要求，虽然就两句话，但是你懂得，不可能这么简单的，肯定会被引申出来一堆要求。

以上是等保2.0通用要求技术要求部分的变化分析，下面再看看管理部分，有什么新的变化。

安全策略与管理制度

11项调整为7项。把1.0中管理制度的第一点单独作为一个控制点，体现对企业总体方针及策略的重视程度增加。

1.对于制定和发布， 不再要求论证和审定过程，不再要求注明发布范围并且收发文要登记，只要控制好版本，正式有效发布即可。可以说是响应国家号召，简化流程，去掉一些不必要的繁琐工作。

2.评审和修订，去掉了必须由领导小组进行评审的要求，这简化了不少工作流程。

安全管理机构和人员

36项调整为26项，把安全管理机构与人员安全管理合并到一起。总体要求简化了不少，但是安全工作领导小组还是要有，三员岗位依旧不能单人单岗，安全管理员不可兼职还是依旧按照1.0的要求。

1.授权和审批方面，去掉了过程文档记录的要求。（省了好多事）

2.沟通合作方面，不再要求要与供应商、专家、安全公司保持沟通，不需要每年聘请安全顾问来指导安全工作。

3. 去掉人员考核整个控制点。也就是说，只要正常对员工进行安全培训以及关键岗位的技术培训，考核与否不作为检查项了，可以公司自由决定。而且，培训记录和培训课程也不用再归档了。

4.外部人员访问管理，新增对外部人员接入网络访问系统的审批要求，更注重信息安全了:

a) 应确保在外部人员接入网络访问系统前先提出书面申请，批准后由专人开设账号、分配权限，并登记备案；

b) 外部人员离场后应及时清除其所有的访问权限；

c) 获得系统访问授权的外部人员应签署保密协议，不得进行非授权操作，不得复制和泄露任何获得系统访问授权的外部人员应签署保密协议，不得进行非授权操作，不得复制和泄露任何敏感信息。

安全建设管理

45项调整为34项。定级和备案合并到了一起，这是比较合理的。

简化了系统安全方案设计的要求，比如不再要求做系统的近期和长期安全建设计划，不再要求定期调整和修订总体安全策略、框架等配套文件。可以说是为甲方省下了一大笔的时间。

1.自行软件开发，增加了新的要求点：

a) 应确保具备软件设计的相关文档和使用指南，并对文档使用进行控制；

b) 应确保在软件开发过程中 对安全性进行测试，在软件安装前对可能存在的恶意代码进行检测；

c) 应确保开发人员为专职人员， 开发人员的开发活动受到控制、监视和审查。

2.开始强调安全在开发层面的重要性，要求必须进行安全测试，也就是说SDL要强制搞起来了。最后一条属于制度方面的约束，主要是防止核心技术或源码泄露，比如这几天B站的那个啥。该防的还是要防，此外员工的日常访谈工作也要做，把一些完全可以通过谈话解决的矛盾，能够避免的事件消灭在萌芽中。

3.外包开发、工程实施、测试验收和系统交付没有新要求，均简化流程，对甲乙方来说都是好事，但不代表可以偷懒，该做的一些流程和审批还是要做的。

4.等级测评稍微简化了一些，有些描述发生了变化。以前三级系统一年一次，二级系统两年一次，这个是必须的，新的标准里只提到了 定期进行等级测评，这个定期是多久没有明确，但是其他研究机构的报告中提到2-4级系统均为一年一次(至少)，但具体如何执行，要看测评中心那边怎么说。

这里再额外说一句，其实按照规定，等保测评必须由测评机构来做，而且是单独的项目，不能由其他厂商或服务商以转包形式打包到项目中。现在好多安服项目都是把等保放在里边作为一项服务，严格来说这么做是不符合规定的。监管部门具体会不会深究这件事，目前还不好说。

安全服务商选择变为服务供应商选择，新增一条要求：

c) 应定期监视、评审和审核服务供应商提供的服务，并对其变更服务内容加以控制。

这条作为检查项我觉得不太好做，虽然是好事，给了甲方更大的权利去要求乙方，这总监控和审核要怎么来量化和评分，感觉掺杂太多的主观意向和背景关系，反正甲方腰板更直了，乙方越来越孙子了。

系统运维管理

62项调整为49项。个别控制点有新要求。

1.环境管理略过，大多都是云计算，新建的混合云自有IDC也是高标准的A类机房。

2.资产管理竟然不要求有资产安全管理制度了，不知道这是怎么个思路，这样的话只要各部门负责好资产梳理和管理就够了。

3.介质管理变化较大，原本6个要求项，现在减少到2个要求项。那么只要根据新的要求来就好：

a) 应确保介质存放在安全的环境中，对各类介质进行控制和保护，实行存储环境专人管理，并根据存档介质的目录清单定期盘点；

b) 应对介质在物理传输过程中的人员选择、打包、交付等情况进行控制，并对介质的归档和查询等进行登记记录。

4.设备维护管理新增2项新要求：

a) 应确保信息处理设备必须经过审批才能带离机房或办公地点，含有存储介质的设备带出工作环境时其中 重要数据必须加密；(前边的审批一般公司都会去做，后边做得不太好，这块之前在1.0解读中有说过，大公司有钱有技术就搞DLP，小公司没钱，那就对介质工软件加密一下)；

b) 含有存储介质的设备在报废或重用前，应进行完全清除或被安全覆盖，确保该设备上的 敏感数据和授权软件无法被恢复重用。(也是提到过的点，量大的交给专业的处理机构，量少的把产品经理头像贴磁盘上交给开发，每人发一个锤子就好了)

5.监控管理和安全管理中心删除，新增 漏洞和风险管理，也是符合当前的实际情况，前几年谈风控，现在谈弱点管理，Gartner又搞出来个CARTA，越来越高大上了。新标准就2点，一是漏洞管理，漏扫、打补丁;二是 定期安全测评，这个可以自己测，也可以找人测，不是等级测评，属于自查的工作。

6.网络安全管理和系统安全管理合并为网络和系统安全管理，由15项简化为9项，没发现有新增的内容，只是描述略微变化。

7.恶意代码防范管理，去除了查杀记录保存的要求，去除了升级、杀毒等过程的分析记录要求；新增一条要求， 定期检验技术措施的有效性。就是不但要及时更新和升级，还要及时调整安全策略，保证防护技术措施确实有效，对于已知的病毒和攻击能够进行防护(apt和ddos这种特殊情况要特殊处理)。

8.新增配置管理控制点，要求备份系统配置信息，至少要包含：网络拓扑、设备安装的组件、软件版本和补丁信息、设备和软件的配置参数；以前没有明确说，现在正是提出了。原文是这两条：

a) 应记录和保存系统的基本配置信息，包括网络拓扑结构、各个设备安装的软件组件、软件组件的版本和补丁信息、各个设备或软件组件的配置参数等；

b) 应将基本配置信息改变纳入系统变更范畴，实施对配置信息改变的控制，并及时更新基本配置信息库。

密码管理和变更管理无明显变化，都不再要求必须有管理制度。备份与恢复管理，不再要求备份恢复管理制度，但要明确备份方式、频率、存储介质和保存期限，感觉还是要写个简化版的制度。不再要求定期开展灾难恢复演练工作和其过程记录，对于很多企业可以说是松了一口气，但是从安全角度来讲，建议还是定期来搞，起码一年一次。

安全事件处置和应急预案管理，简化流程，减少过程文档记录的留存，其他无变化。

等级保护市场的变化

这里借用了一些其他大机构和研究所的数据，毕竟我这边没那么多资金去搞调研。说下个人比较直观的感觉(之前有人预测了等保 2.0 带来的 200 亿市场需求，有些道理)。

这里我说下服务方面，初步统计国内三级系统约5w，二级系统约50w(其他研究团队得来的市场数据)，那么新标准出来后，这些已定级备案的系统必然要重新定级，这部分的服务费用假设取下限：

     L3 Sys x 50000 x 50k = 25亿；
   L2 Sys x 30000 x 500k = 150亿；
   175 x 0.85 = 148.75亿(这里抛开有些企业就是想躲等保定级，不被查到不去重定级的情况)

这是现存的市场量，那么全国新增信息系统数量大概多少，这里推算一下吧。直接数据没有，只能通过间接数据粗略估算一下。能找到的数据是国内企业网站增长数量(国家统计到的数据，应该是有备案的网站)：

(来源：data.stats.gov.cn)

可以看出，2015-2017年增长还算稳定。16年增长率1.71%，17年增长1.66%，那么预计18年的增长也差不多在1.6%左右。这么来看，每年应该会有大概8000个备案的新增网站，这类网站虽然备案但未必达到关键基础设施或需要定二级以上的程度，我们大刀一下，还剩4000个需要定级备案的，按照1:10划分三级和二级系统，即364个三级系统和3636个二级系统，众所周知目前定级推广的还是有限，那么需要三年左右时间来开展工作，就会变成121个三级系统和1212个二级系统。

  121 x 50000 + 1212 x 30000 = 42410000

约为4000w的咨询服务增长，这是每年的。新标准要求二级以上系统至少每年进行一次复测(以前是二级2年1次，三级1年1次，现在都是至少1年1次了)。

这个市场基本就是：

  148.75 + 0.4 = 149.15亿

年增长0.27%，那么累计每个下一年的市场份额为149.15 x (1+0.0027)^n。

这是初步计算的结果，还不包括已在运行，但是未被监管到未定级的系统数量，要知道网安法要求只要信息系统达到一定量级是必须要定级备案的。所以如果按照国家法律法规执行，预估明年应该光咨询服务就有大概150亿左右的市场。

结尾

随着习总书记发表“4·19”重要讲话以及《网络安全法》的颁布、实施，网络安全的重要性不断提高。“没有网络安全就没有国家安全，没有信息化就没有现代化”已深入人心。希望大家能够重视网络安全工作，不要本末倒置。

*本文原创作者：宇宸@默安科技合规研究小组，本文属于FreeBuf原创奖励计划，未经许可禁止转载

猎聘网：2019年Q1中高端人才报告平均年薪为26.38万元

Sun, 21 Apr 2019 20:36:09 CST

猎聘网近日发布2019年第一季度中高端人才报告。报告显示，互联网行业每个月的中高端人才紧缺程度都明显高于全行业水平，这表明互联网行业依然是最有活力的行业之一。报告还显示，在5G这个新兴领域中，2019年第一季度的职位需求同比增长32.12%，而平均年薪为26.38万元。

互联网春天仍在平均年薪23.42万元

猎聘大数据显示，从2018年1月到2019年3月，国内中高端人才紧缺程度总体放缓，全行业人才紧缺指数TSI（TSI 即 Talent Shortage Index 的缩写。TSI>1，表示人才供不应求； TSI<1，表示人才供大于求。如果 TSI 呈上升趋势，表示人才越来越抢手，找工作相对容易）总体呈下降趋势，从2018年1月的最高点1.25降到2019年3月的最低点0.74，人才从供不应求到供大于求。2018年10月是一个转折点，当月开始TSI跌破1。

这与全国整体的经济形势密切相关。2018年下半年，国内经济面临较大的下行压力，用人单位招人整体趋于保守，招聘需求有所放缓，而求职者对换工作也较为谨慎，整体人才紧缺程度随之降低；同时一季度的1、2月处于招聘淡季，又受春节假期因素影响，因而受到了一定程度的冲击。

对比互联网行业与全行业过去15个月的TSI走势，互联网行业每个月的中高端人才紧缺程度都明显高于全行业水平，这表明互联网行业依然是最有活力的行业之一。

由于互联网在前几年的发展过程中存在一些求快、过猛的现象，在经济形势的考验下，在人才需求上逐渐回归理性，为了更好的发展，一些互联网公司积极地进行组织架构和人才结构的调整，以完成组织升级和人才升级，更好地适应当下的经济形势。

根据猎聘统计，国内2019年一季度有融资和上市行为的公司多达1200多家，其中互联网公司近500家，后者人才需求同比2018年一季度增长57.43%；在不同司龄的互联网公司中，猎聘发现新兴互联网公司招聘需求同比2018年一季度增长32.83%。具有10年以上历史的互联网公司的招聘需求同比增长39.30%。

从全国中高端人才平均年薪来看，其中，金融行业的平均年薪依旧遥遥领先其他行业，为24.95万元；其次是互联网行业，平均年薪为23.42万元。

一线城市吸引力强劲北京平均年薪27.44万元

从2019年一季度中高端人才的城市分布来看，一线城市集中度较高，为43%。由于一线城市资源更丰富，行业发展更成熟，为各类人才提供了更多发展机会，工资待遇较为优厚，因此吸引力非常强劲。

从排名来看，一线城市依然稳居前四，杭州的中高端人才占比仅次于一线城市。由于杭州发展速度较快，提供了大量的就业机会，此外杭州地理环境优越、气候温宜，因此吸引大量中高端人才加入。另外，近些年各城市陆续出台各类引才新政，且二线城市引才力度相对较大，因此对中高端人才具有极强的吸引力。

在薪酬方面，北京平均年薪27.44万元，排名第一；其次是上海、深圳和广州，其平均年薪集中在23~26万元之间；值得注意的是，二线城市与新一线城市的薪酬仍存在明显的差距，普遍在20万元以下。虽然二线城市就业政策相对较好，但是生活成本相对较低，在一定程度上也影响了当地的薪资水平。

电竞平均年薪超30万 5G职位需求同比增长32.12%

猎聘还通过大数据分析了18个新兴领域，涵盖5G、AI、AR、VR、区块链、电竞、大数据、新能源汽车、平台经济、共享经济、跨境电商、互联网+教育、工业互联网、新一代信息技术、高端装备、生物医药、新材料、物联网，专门分析了其中职位增长和薪资位居前十的领域，一探其人才需求和收入的详细情况。

在职位增长方面，在2019年一季度，在这些新兴领域职位同比增长最快的十大领域中，增长幅度高度不同，但均为正向增长，增长区间为14.33%-91.42%。

其中，互联网+教育职位需求同比增长排名第一，为91.42%；电竞位居第二，同比增长为89.50%；AI排名第三，职位同比增长为44.30%。今年因为国产5G手机扎堆发布被备受关注的5G领域，比2018年一季度同比增长32.12%。

在这些领域中，5G也是一大热点。2019年被称为“5G发展元年”，随着国内手机大厂在今年2月的2019世界移动通信大会上扎堆发布了各家的5G手机后，5G成为了全民关注的高科技热点，必将拉动该领域对中高端人才的需求。

在薪资排名方面，薪资排名前十的新兴领域中整体水平较高，平均年薪均超23万元，其中平均年薪最高的是电竞，为31.43万元；平均年薪位居第二和第三的新兴领域为区块链和AI，分别为27.10万元、26.38万元；5G领域位居第四，平均年薪26.38万元。

自新浪科技

暴力破解及其流行工具研究

Mon, 25 Feb 2019 15:00:11 CST

暴力破解攻击是最流行的密码破解方法之一，然而，它不仅仅是密码破解。暴力攻击还可用于发现Web应用程序中的隐藏页面和内容，在你成功之前，这种攻击基本上是“攻击一次尝试一次”。这种攻击有时需要更长的时间，但其成功率也会更高。在本文中，我将尝试解释在不同场景中使用的暴力攻击和流行工具，来执行暴力攻击并获得所需结果。

什么是暴力攻击？

当攻击者使用一组预定义值攻击目标并分析响应直到他成功，这就叫做暴力攻击。它的成功取决于预定义值的集合，如果它越大，就会需要更多时间，但成功的可能性也会变大。最常见且最容易理解的暴力攻击是破解密码的字典攻击，在这种情况下，攻击者使用包含数百万个可作为密码的单词的密码字典，然后攻击者逐个尝试这些密码并进行身份验证，如果字典中包含正确的密码，攻击者将会成功。

在传统的暴力攻击中，攻击者只是尝试字母和数字的组合来顺序生成密码。但是，当密码足够长的时候，这种技术就会需要更长的时间，这些攻击可能需要几分钟到几小时甚至是几年的时间，具体取决于所使用的系统和密码的长度。

为了防止暴力破解密码，应始终使用长而复杂的密码。这会使得攻击者很难猜到密码，暴力攻击会花费更多的时间，大多数时候，WordPress用户面临对其网站的暴力攻击。帐户锁定是防止攻击者对Web应用程序执行暴力攻击的一种方法。但是，对于离线软件，事情就没这么简单了。

同样，为了发现隐藏页面，攻击者会尝试猜测页面名称，发送请求并查看响应。如果该页面不存在，它将显示响应404，成功的话就会响应200。这样，它可以在任何网站上找到隐藏页面。

暴力攻击也用于破解散列并从给定散列中猜出密码。这样的话，哈希是从随机密码生成的，然后此哈希与目标哈希匹配，直到攻击者找到正确的哈希。因此，用于加密密码的加密类型（64位、128位或256位加密）越高，暴力破解所需的时间就会越长。

逆向暴力攻击

逆向暴力攻击是另一个与密码破解相关的术语，破解密码采用相反的方法。攻击者针对多个用户名尝试一个密码，想想你是否有知道密码但是不知道用户名的时候，在这种情况下，你可以尝试使用相同的密码去猜测不同的用户名，直到找到匹配组合。

现在，您知道暴力攻击主要用于密码破解，您可以在任何软件，任何网站或任何协议中使用它，只要目标在几次无效尝试后不会组织请求就行。在这篇文章中，我将为不同的协议介绍一些流行的密码破解工具。

暴力破解的流行工具

Aircrack-NG

我相信大家都曾经了解过Aircrack-ng工具，这是一款免费的无线密码破解工具。该工具附带WEP / WPA / WPA2-PSK破解程序和分析工具，可对WiFi 802.11进行攻击。Aircrack-ng可用于任何支持监听模式的网卡。

它基本上是采用密码字典攻击来猜测无线密码，如您所知，攻击的成功取决于密码字典，密码字典越好越有效。

它适用于Windows和Linux平台，它也被移植到iOS和Android平台上运行，您可以尝试使用给定的平台来研究此工具的工作原理。

下载链接： Aircrack-ng

John the Ripper

开膛手约翰也是一款几乎人人皆知的工具，它长期以来一直是进行暴力攻击的最佳选择。这个免费的密码破解工具最初是为Unix系统开发的，后来，开发人员又为其他平台发布了这款工具。现在它支持15种不同的平台，包括Unix\Windows、DOS、Linux、BeOS和OpenVMS等。您可以使用它来识别弱密码或破解密码来通过身份验证。

这款工具非常受欢迎，并结合了各种密码破解功能，它可以自动检测密码中使用的哈希类型。因此，您也可以针对加密密码存储运行它。

基本上，它可以通过组合字母和数字对所有可能的密码执行暴力破解。但是您也可以将其与密码字典一起使用来执行字典攻击。

下载地址： https://www.openwall.com/john/

Rainbow Crack

Rainbow Crack也是一款用于密码破解的流行工具。它会生成彩虹表，以便在执行攻击时使用，这也使得它与其他的暴力破击工具不同。彩虹表是预先计算的，它有助于减少执行攻击的时间。

幸运的是，有各种组织已经为所有互联网用户发布了前计算机的彩虹表，为了节省时间，您可以下载这些彩虹表并在攻击中使用。

该工具仍然在积极开发中，它适用于Windows和Linux，并支持这些平台的所有最新发行版。

下载链接： http://project-rainbowcrack.com

Cain & Able

同样也是一款热门的工具，它可以通过执行暴力攻击、字典攻击和密码分析攻击来帮助破解各种密码。密码分析攻击是通过使用前一种工具中提到的彩虹表来完成的。

值得一提的是，一些病毒查杀软件会将其检测为恶意软件。Avast和Microsoft Security Essentials将其报告为恶意软件并会组织它的运行。如果您需要使用这款软件，您需要先和您的杀毒软件打好招呼。

它的基本功能是：

嗅探网络

使用字典破解加密密码

暴力和密码分析攻击

录制VoIP会话

解码加密密码

恢复无线网络密钥

揭示密码框

发现缓存中的密码

分析路由协议

该工具的最新版本具有很多功能，并添加了嗅探来执行中间人攻击。

下载链接： http://www.oxid.it/cain.html

L0phtcrack

L0phtCrack以破解Windows密码的能力而闻名。它使用字典、暴力破解、混合攻击和彩虹表。L0phtCrack最显著的特性是调度、64位Windows版本的哈希提取、多处理器算法以及网络监控和解码。如果要破解Windows系统的密码，可以尝试使用此工具。

下载链接： http://www.l0phtcrack.com/

Ophcrack

Ophcrack是另一款专门用于破解Windows密码的暴力破解工具。它通过彩虹表使用LM哈希来破解Windows密码。它是一款免费的开源工具，在大多数情况下，它可以在几分钟内破解Windows密码，默认情况下，Ophcrack附带的彩虹表能够破解少于14个字符的密码，其中只包含字母数字字符。其他彩虹表也可供下载。

Ophcrack还可用作LiveCD。

下载地址： http://ophcrack.sourceforge.net/

Crack

Crack是一款古老的密码破解工具，它是Unix系统的密码破解工具，用于通过执行字典攻击来检查弱密码。

下载链接： https://dropsafe.crypticide.com/alecm/software/crack/c50-faq.html

Hashcat

Hashcat号称是最快的基于CPU的密码破解工具。它是免费的，适用于Linux、Windows和Mac OS平台。Hashcat支持各种散列算法，包括LM Hashes、MD4、MD5、SHA系列、Unix Crypt格式、MySQL、Cisco PIX。它支持各种攻击形式，包括暴力破解、组合攻击、字典攻击、指纹攻击、混合攻击、掩码攻击、置换攻击、基于规则的攻击、表查找攻击和Toggle-Case攻击。

下载链接： https://hashcat.net/hashcat/

SAMInside

SAMInside同样专门用于破解Windows操作系统的密码，它类似于Ophcrack和Lophtcrack工具。它声称在一台电脑上最高可以每秒破解大约1000万个密码。它支持各种攻击方法，包括掩码攻击、字典攻击、混合攻击和彩虹表攻击。它支持400多种哈希算法。

下载地址： http://www.insidepro.team/

DaveGrohl

DaveGrohl是适用于Mac OS X的流行破解工具，它支持所有可用版本的Mac OS X，此工具支持字典攻击和增量攻击。它还具有分布式模式，允许您从多台计算机执行攻击以攻击相同的密码哈希。此工具现在是开源的，您可以从源码进行安装。

下载地址： https://github.com/octomagon/davegrohl

Ncrack

Ncrack用于破解网络身份验证，它支持各种协议，包括RDP、SSH、HTTP(S)、SMB、POP3(S)、VNC、FTP和telnet。它可以执行不同的攻击，包括暴力破解等。支持包括Linux、BSD、Windows和Mac OS X等操作系统。

下载链接： https://nmap.org/ncrack/

THC Hydra

九头蛇以其通过执行暴力攻击来破解网络身份验证的能力而闻名。它可对多种协议执行字典攻击，包括telnet、FTP、HTTP、HTTPS、SMB等。它适用于多种平台，包括Linux、Windows、Cygwin、Solaris、FreeBSD、OpenBSD、OSX和QNX/BlackBerry等。

下载地址： https://sectools.org/tool/hydra/

这些都是用于密码破解的流行工具，还有各种其他工具可用于对不同类型的身份验证执行暴力破解，如果我只举几个小工具的例子，你会看到大多数PDF破解、ZIP破解工具使用相同的暴力破解方法来执行攻击，有许多此类工具可免费或付费使用。

结论

暴力破解是破解密码最常用的方法，攻击的成功取决于各种因素，但是，影响最多的因素是密码的长度以及数字、字母和特殊字符的组合。这就是我们谈论强密码的原因：我们通常建议用户使用小写字母、大写字母、数字和特殊字符组合的长密码。它不会使得暴力破解不可能，但会让其变得十分困难。这样，暴力破解会需要更长的时间来破解密码。几乎所有的散列破解算法都使用暴力破解来尝试，当您对数据进行脱机访问时，此攻击最佳。在这种情况下，它易于破解，而且会花费更少的时间。

暴力密码破解在计算机安全性方面非常重要，它用于检查系统、网络或应用程序中使用的弱密码。

防止暴力攻击的最佳方法是限制无效登录，通过这种方式，攻击只能在有限的时间点击并尝试密码。这就是为什么基于网络的服务开始使用验证码，如果您三次输入错误的密码他们会对您的IP地址进行屏蔽。

*参考来源： infosecinstitute，本文由大学新生Bai编译，转载请注明来自FreeBuf.COM

App Store Top 1000 关键词分析

Mon, 08 Oct 2018 09:20:21 CST

做这个分析的主要目的是分析用户的搜索习惯及用户的需求方向，寻找可能的机会。以下分析是7月初进行的，数据比较老，供参考。

在Top 1000的关键词中，82% 是品牌词，足见品牌（口碑）对应App的下载量还是非常的重要。而另外18%的非品牌词也展现了一些打造品牌的机会（用户在该品类下还没有产生思维定势，新的App还存在一定的机会），以下为另外18%的非品牌关键词：

VPN

有需求存在，涉及到相关的法律政策，很难有较好的发展。

排名	关键字	热度	榜首应用	热度搜索结果数
13	vpn	9849	VPN-极速高效稳定的VPN网络加速神器	1149
358	vpn翻墙软件免费	7557	VPN – 无限流量，高速网络vpn	42
596	vpn免费版	7050	VPN-极速高效稳定的VPN网络加速神器	1166
688	极速vpn	6926	VPN-极速高效稳定的VPN网络加速神器	1167

理财

理财的需求没有被很好的满足，这个行业鱼龙混杂，随着P2P的不断爆雷，其他方向的理财或许是一个方向，目前这个行业存在较大的机会。

排名	关键字	热度	榜首应用	热度搜索结果数
31	理财	9450	京东金融-新人领888元大礼包	1410
66	期货	8903	期货直播吧-香港全球期货投资理财专家	1741
181	理财平台	8088	金碗理财-高收益短期理财投资平台	1601
251	理财软件	7849	有理树理财—短期投资理财的手机理财软件	1530
270	投资	7785	立信投资-银行存管对接中	1555
314	外汇	7666	外汇牌价-全球行情分析软件	1693
642	理财工具	6991	八条鱼理财-懒人投资理财神器	1626
536	短期理财	7146	正经事理财-短期投资理财银行存管	1508
578	金融	7083	聪明钱包-简单的金融投资理财软件	1685
613	理财产品	7028	有理树理财—短期投资理财的手机理财软件	1507
626	外汇交易	7010	金道外汇投资-全球期货现货交易平台	1691
673	投资理财	6952	铜掌柜理财-高收益合规p2p金融投资理财平台	1533
676	股票	6948	股市	1631
762	理财管家	6843	帝象理财	1586
872	贵金属	6714	原油交易宝-原油贵金属期货投资平台	1705
932	期货交易	6639	期货交易-全球期货资讯专业平台	1573
940	外汇投资	6634	金道外汇投资-全球期货现货交易平台	1691
986	活期理财	6587	花生米富-银行存管,理财更安全	1360

贷款

与理财相对，有的人钱多，有的人钱少，小额贷款存在一定量的需求，此类风险较大，贷款的核心是尽可能多贷，所以会出现用户尽可能的下载更多的app，进行拆东墙补西墙的操作等，慎。

排名	关键字	热度	榜首应用	热度搜索结果数
41	贷款	9220	贷款钱包-30分钟到账的贷款app	1634
102	借钱	8543	马上借钱-分期贷款现金借钱借款平台	1597
232	闪电借款	7896	闪电借款领先版-小额现金借款	1709
345	贷款平台	7591	贷款钱包-借钱快现金贷款平台	1665
346	现金贷	7587	现金贷-小额分期借钱贷款平台	1713
398	贷款app	7448	闪贷钱包—小额分期贷款的现金贷款APP	1650
423	借款	7388	借款王-身份证就能手机借款的app	1700
515	小额贷款	7184	小额贷款-分期贷款急借钱平台	1717
805	现金贷款	6778	现金借款-手机极速借款app	1727
813	贷	6772	任性贷-有信用即刻下3000-10万的贷款借钱、网贷分期APP	1709
840	借款平台	6752	秒借款-30000元2小时到账的闪电借款平台	1706
897	借贷	6685	借贷宝 – 手机打借条, 体面有保障	1676
938	小额借款	6635	小额借款-极速借钱小额借款贷款软件	1723
973	借钱软件	6597	轻松借-小额分期贷款借钱借贷软件	1657

记账

钱不够花的引导出来的还有一个需求是：记账。记账属于工具类的产品，难点在获利。

排名	关键字	热度	榜首应用	热度搜索结果数
656	账本	6972	鲨鱼记账-3秒钟快速记账手机助手	765
756	记账软件	6851	鲨鱼记账-3秒钟快速记账手机助手	1694

彩票

没钱的状况下，还会考虑一夜暴富，买彩票也存在一定的需求，由于相关法律法规，想要开展互联网彩票非常的困难。

排名	关键字	热度	榜首应用	热度搜索结果数
46	六合彩	9113	重庆时时彩-六合彩资料大全好运彩票出品	780
152	彩票	8236	网易彩票-双色球体彩竞彩预测投注开奖	801
503	六合宝典	7203	奖多多彩票-新人注册送108元	765
793	快三	6795	天天中彩票	1028
827	福利彩票	6761	福利彩票-高低频彩票开奖平台	616
228	抓娃娃	7920	抓娃娃机游戏-天天都想玩的在线抓娃娃	913

游戏

游戏类的关键词会出现较多的品类词，可能原因是用户想要寻找新的游戏导致的，目前也可以看到益智类的游戏品类词较多。

排名	关键字	热度	榜首应用	热度搜索结果数
196	游戏	8016	密室逃脱：逃出神秘宫殿	1644
301	游戏大全	7694	神庙酷跑 – 跑步游戏大全	1575
460	手游	7302	龙骑世界-国民级热血PK手游	1536
987	单机	6587	斗地主单机斗地主单机版全民棋牌比赛	1409
34	吃鸡	9359	绝地求生:刺激战场	1678
123	吃鸡游戏	8377	绝地求生:刺激战场	1422
167	修仙	8142	焚仙-逍遥侠侣修仙手游	1463
799	仙侠	6787	全民寻仙-大型3D国民修仙热恋手游	1485
937	足球	6635	足球大师黄金一代	1248
832	赛车	6756	狂野飙车8：极速凌云	1147
905	炫舞	6673	QQ炫舞	1845
147	百家乐	8247	百家讲坛大全-手机电子书免费书城(得到一个有声小说阅读器管家)	690
279	牛牛	7762	金爵棋牌-真人棋牌游戏	900
327	麻将	7638	腾讯欢乐麻将全集	1159
494	欢乐炸金花	7220	炸金花 – 全民炸金花天天欢乐炸金花	826
766	棋牌	6836	金爵棋牌-真人棋牌游戏	967
877	五子棋	6710	腾讯欢乐五子棋	1415
830	象棋	6758	中国象棋—楚汉争霸，策略小游戏	1664
974	卡牌游戏	6595	三国·军师-全自由实时策略卡牌手游	1442
944	数独	6630	数独—经典数字趣味谜题桌游	1686
149	弹球	8245	物理弹球	1685
239	消消乐	7878	开心消消乐®	1702
394	钢琴	7460	完美钢琴 – 智能键盘, 海量曲谱, 远程连线	1887
447	塔防	7325	塔防三国志 – TD塔防类卡牌手游	1645
764	塔防游戏	6837	塔防三国志 – TD塔防类卡牌手游	1676
454	捕鱼游戏	7313	熊猫捕鱼-捕鱼高手的街机捕鱼游戏	1031
618	跳一跳	7016	欢乐跳跳跳	487
509	拼图	7190	简拼-文艺范视频拼图·美图P图神器	1935
748	拼图软件	6858	海报拼图软件-照片组合器	1872
545	儿童游戏	7140	2-6岁宝宝爱数学-家庭育儿益智启蒙教育必备的免费儿童游戏	1961
964	连连看	6602	宠物连连看经典版-最新免费益智爱消除单机小游戏	1843

系统工具

工具类的需求可能原因是原生类的工具不能很好的满足需求或功能不够强大。核心是产品要在功能点上有亮点。

排名	关键字	热度	榜首应用	热度搜索结果数
50	浏览器	9051	QQ浏览器 – 用腾讯王卡全网免流	1518
333	浏览器IPHONE版	7625	浏览器iPhone版-安全版	1537
201	天气	8001	天气	1749
362	天气预报	7552	天气预报	808
706	天气预报苹果版	6907	天气 – 精准预报实时天气变化	808
238	万年历	7879	万年历-值得信赖的日历黄历查询工具	914
886	万年历黄历	6694	万年历-值得信赖的日历黄历查询工具	908
292	日历	7732	日历	1857
258	计算器	7815	计算器	1855
865	计算机	6724	计算器 – 默认计算器	1870
269	翻译	7792	有道翻译官-出国旅游英语日语翻译必备旅行APP	1790
531	翻译软件	7153	有道翻译官-出国旅游英语日语翻译必备旅行APP	1216
548	录音	7134	专业录音—移动录音专家。	1292
912	变声器	6662	Voice Changer – 变声神器声音特效器	172
737	网络电话	6876	微微电话-通话最好的网络电话	1440
639	指南针	6993	指南针	1297
498	备忘录	7215	备忘录	990
570	输入法	7096	百度输入法-语音输入法	1181
550	音乐播放器	7133	酷狗音乐-《无限歌谣季》官方音乐APP	1289
501	K歌	7206	全民K歌 – K歌短视频互动平台	1370
816	视频播放器	6768	爱奇艺万能播放器 – 观看本地视频神器	1363
845	播放器	6745	播放器OPlayer Lite – 视频播放器	1352
564	空调遥控器苹果版	7116	遥控大师	68
858	空调万能遥控	6728	遥控精灵-手机万能遥控器	147
412	邮箱	7413	邮件	938
115	壁纸	8422	壁纸：高清手机主题桌面动态墙纸	1529
448	动态壁纸	7323	我的动态壁纸	427
767	壁纸大全	6836	壁纸大全 : 百万超高清壁纸库	977
483	铃声	7238	铃声多多-手机铃声大全	1351
530	手机铃声	7153	铃声多多-手机铃声大全	582
854	苹果手机铃声	6735	铃声多多-手机铃声大全	531
213	相机	7961	B612咔叽 – 全球自拍达人的新圣地	1720
462	p图	7297	P图神器-图片编辑拼图修图制作软件	1765
637	证件照	6994	智能证件照-自带美颜拍摄最美证件照	272
796	ps	6789	Adobe Photoshop Express	1807
953	美颜	6615	BeautyCam美颜相机	1612
958	拍照	6611	B612咔叽 – 全球自拍达人的新圣地	1810
264	视频编辑	7801	爱剪辑手机版 – 专业视频剪辑编辑制作	1391
481	视频剪辑	7243	视频剪辑 – 影片裁剪,视频编辑制作	636
665	同步助手	6961	QQ同步助手-手机通讯录安全备份管家	1356
820	电池医生	6766	电池医生-专业电池状态管理	576
908	wifi	6668	WiFi钥匙-安全上网管家	1587

微信分身

工作微信和生活微信分开是很多人存在需求，特别是微商类的。

排名	关键字	热度	榜首应用	热度搜索结果数
119	微信分身版苹果版免费	8405	商信 – 微商达人必备助手	102
302	微信分身版苹果版	7691	商信 – 微商达人必备助手	110
875	微信分身	6711	商信 – 微商达人必备助手	927

小说、视频、新闻

用户闲的时间还是比较多，小说、资讯等还是存在一些发展空间。

排名	关键字	热度	榜首应用	热度搜索结果数
56	免费小说	8958	小说大全 – 小说阅读器大全	1587
70	小说	8861	QQ阅读-拥有海量热门小说、漫画的电子书阅读器	1460
351	免费小说阅读器	7571	小说大全 – 小说阅读器大全	1571
552	看书神器	7132	小说阅读器 – 畅读小说阅读大全	1520
978	小说大全	6592	热门小说大全—小说阅读器之最新电子书小说	1480
591	阅读	7063	小说阅读器 – 畅读小说阅读大全	1611
660	听书	6966	喜马拉雅FM「听书社区」电台有声小说相声评书	1612
339	漫画	7606	快看漫画-高清正版漫画流畅看	1497
800	电子书	6786	QQ阅读-拥有海量热门小说、漫画的电子书阅读器	1637
929	收音机	6642	FM收音机-轻松收听全国广播电台	594
399	视频	7445	视频	1620
603	NBA	7040	NBA LIVE-EA出品 5v5真操控篮球手游	1647
290	直播	7737	腾讯视频-创造101全网独播	1345
502	电视直播	7204	天天看电视直播	1091
728	韩剧	6888	韩剧TV-追剧女生大本营	1557
160	音乐	8195	音乐	1798
241	影视大全	7876	今日影视大全-电影电视剧视频播放器	741
120	新闻	8402	一点资讯-热门新闻头条资讯和娱乐视频	1797
245	头条	7859	今日头条 – 你关心的，才是头条	1693
353	资讯	7569	一点资讯-热门新闻头条资讯和娱乐视频	1722
522	头条新闻	7166	今日头条 – 你关心的，才是头条	1606

交友

原始需求还是非常的旺盛啊

排名	关键字	热度	榜首应用	热度搜索结果数
211	约炮	7970	约单-有你想要的服务	1312
906	同城约炮	6669	成人之美 – 成人交友社区	807
275	交友	7769	他趣 – 成人交友情趣体验社	1359
422	闲聊	7392	闲聊-兴趣部落	1365

购物返利

此部分有一定的发展机会，也容易赚钱，可以好好的发展。

排名	关键字	热度	榜首应用	热度搜索结果数
869	购物	6719	大众点评-会生活的人在大众点评	1609
926	全球购	6644	全球购-全球正品海淘代购特卖商城	1366
231	返利app	7897	返利-专注网购省钱的APP	1599
326	淘宝优惠券	7640	省钱达人-领淘宝优惠券的省钱APP	825
439	返利	7348	返利-专注网购省钱的APP	1587
341	二手车	7602	瓜子二手车直卖网-二手车卖车买车交易平台	1899

生活服务

主要是O2O型的服务，比较适合大型的公司进行发展。

排名	关键字	热度	榜首应用	热度搜索结果数
458	租房	7305	蚂蚁租房 – 掌上租房必备	1489
466	酒店	7283	艺龙旅行-订酒店机票旅游攻略	1879
584	租车	7072	神州租车-万辆新车自由行	1934
587	共享汽车	7065	GoFun出行-首汽共享汽车	320
823	旅游	6765	驴妈妈旅游-订景点门票,选机票酒店	1715
801	外卖	6785	美团外卖-外卖订餐,送啥都快	1739
975	装修	6595	好好住 – 你的家居装修指南	1739
495	兼职	7220	兼客兼职-年轻人兼职找工作必备	1653
526	招聘	7159	Boss直聘-招聘求职找工作神器	1889
790	找工作	6798	Boss直聘-招聘求职找工作神器	1793
475	英语	7264	懒人英语—每日英语听力趣配音秀（基础音标学习雅思扇贝口语）	1837
590	运动软件	7064	Keep – 自由运动场	1847
488	违章查询	7230	车轮(车轮查违章)2018全国违章代缴助手	1423
862	公交车实时查询	6726	车来了-精准的实时掌上公交地铁	103
615	菜谱	7023	菜谱大全-小白学做菜做饭必备烹饪助手	1774
863	汽车	6726	汽车之家-2.2亿家人都在用的汽车App	1726
427	大姨妈	7377	大姨妈月经期助手-女性生理备孕健康工具社区	1118
774	发现精彩	6830	信用卡办卡 – 中国的银行手机银行信用卡快速申请攻略	111

The post App Store Top 1000 关键词分析 appeared first on 标点符.

No related posts.

日益增加的移动诈骗攻击分析简报

Fri, 05 Oct 2018 15:00:30 CST

移动设备，早就已经成为了攻击者的主要目标，因此移动端诈骗攻击的活动愈加频繁也就不足为奇了。目前，有大约58%的数字交易活动是通过移动端设备发起的，而且现在的网络攻击活动中有1/3也是针对移动端设备的。在美国就更加严重了，每年全球针对移动端的诈骗攻击增长率约为24%，但美国的同类攻击增长率每年约为44%，你们说惨不惨…

本文的数据来源于TreatMetrix发布的2018年第二季度网络犯罪报告【 PDF】，而这份报告的采样数据来源于研究人员对2018年第一季度里176亿条数字交易记录的分析结果。

ThreatMetrix的高层Alisdair Faulkner表示：“移动端设备已经迅速成为了人们访问在线商城和网络服务的主要方式了，因此针对移动端设备攻击活动的数量迅速增长，这也在我们的意料之中。除此之外，无论用户还是厂商，他们都喜欢移动端设备，而主要原因就是移动端设备可以当做一个人的身份标识。”

对于厂商来说，移动端交易比桌面端交易要更加安全。而对于用户来说，移动端交易实现起来也更加方便。这个过程中交易机制的基础规则为：独立设备可以通过身份验证机制来进行安全识别，而个人用户能够与移动端设备进行绑定，并通过内置的生物识别功能（例如面部识别、声纹识别和指纹识别）等健壮性较强的验证机制来对个人用户进行安全识别。

比如说，MasterCard（万事达卡）就率先在用户身份识别中采用了基于手机和生物识别的验证方案，但这样只会增加使用移动端设备完成金融交易的用户数量，因为这种方式也是一把双刃剑。卡巴斯基实验室的安全研究专家David Emm认为：“存储在服务提供商的数据库里的生物识别数据跟用户名和密码一样，是有可能被网络犯罪分子窃取的。一旦发生了数据泄露，客户的用户名和密码能够修改，但生物识别数据却是没法修改的，因为这种数据你一辈子都无法改变（整容也没用啊…）”

Faulkner补充说道：“但好消息就是，随着移动端设备的使用频率迅速增长，用户的总体识别成功率也在随之增高，因为各种移动端App为了抢夺市场，他们会设计出各种各样更高精准度的用户身份识别技术。然而，整个过程最关键也是最脆弱的环节就在于应用程序的注册阶段以及用户账号的创建阶段。”

需要注意的是，针对移动端设备的攻击活动很可能会在短期之内迅速增加，尤其是在欧洲的PSD2（开放银行条款）发布之后，而这一条款的主要目的就是推动新兴金融科技公司以及相关应用程序的增长和发展。这样一来，又会有更多的网络犯罪分子将他们的“矛头”指向这些“新人”，这也是不可避免的。其实整个金融服务行业已经徘徊在了改革的“悬崖”边上，而欧洲地区的各大银行也在小心翼翼地等待着，他们都在思考如何向第三方供应商（账户信息服务提供商或支付服务提供商）开放API接口才能让大家都满意。

目前，最大的威胁来自于设备欺骗，欺诈攻击者会尝试欺骗银行让他们认为此次“登录尝试”来自于新的用户设备，而目前有超过5%的交易尝试来被认定为此类攻击。身份欺骗则是第二大威胁，约占3.6%，但对于针对金融服务的特定攻击来说，网络犯罪分子通常会使用的是凭证窃取，而非身份欺骗。除此之外，这一季度有25%的新增电子商务账号应用都是欺诈攻击的产物，而这一数字跟2017年同期相比增加了130%。

其他常见的攻击类型包括IP欺骗、基于浏览器的中间人攻击或BOT攻击。使用僵尸网络发动的攻击活动也越来越频繁了，2018年第二季度总共检测到了26亿次BOT攻击，相较于2018年第一季度增长了60%，而这些BOT会使用自动化脚本和窃取到的凭证来尝试访问目标账号或进行欺诈交易。

ThreatMetrix还警告称，随着全球金融体的连接紧密度在不断加深，企业需要确保他们能够动态地去识别和分析各种欺诈活动，而此时基于行为的欺诈检测系统就可以“大放异彩”了。

*参考来源： securityweek，FB小编Alpha_h4ck编译，转载请注明来自FreeBuf.COM

廉价安卓手机的秘密：暗藏后门来获利

Fri, 05 Oct 2018 07:23:00 CST

与价格并不亲民的苹果手机相比，不少低成本的 Android 手机以低廉的价格和丰富的功能在全球变得越来越受欢迎。

但你可能不知道的是，很多低价的安卓手机是因为早已预装了远程木马来获取用户信息，来提高获利的。

比如，你的廉价手机是否经常收到为你量身定制的各种小广告？你的定位功能是否总是在你不使用的时候也经常处于开启状态？你的手机总反应很慢，即使你只打开了少数的应用……

据外媒 bleepingcomputer 报道，来自安全公司 Sophos 的安全研究员通过对“uleFone S8 Pro”这款手机的分析，发现了很多藏在廉价安卓手机背后的秘密。

这款手机售价为110美元的手机，在出厂时，就被预装了远程访问木马（RAT）。

为何会盯上这款手机，还要从2017年说起。当时，Sophos的研究人员在xda-developers.com上看到一篇文章，用户声称他们的安全软件经常抱怨手机上预装了一个名为Sound Recorder的应用程序。

为了进一步调查，他们购买了报告中所提到的 uleFone S8 Pro 。当他们分析手机时，发现预装的录音机应用实际上是一种恶意变种，其功能类似于远程访问木马（RAT）和后门。

虽然手机制造商包含并从预安装软件中获得收入并不少见，但在这种情况下，质量控制还不足以发现安装的Sound Recoder应用程序不是合法版本。

从上图中可以看出，与合法版本相比，恶意版本添加了额外的代码。

在RAT运行时，Sophos声称它会将信息传输到远程服务器，其中包括：

设备的电话号码

位置信息，包括经度，纬度和街道地址

IMEI标识符和Android ID

屏幕分辨率

制造商，型号，品牌，操作系统版本

CPU信息

网络类型

MAC地址

RAM和ROM大小

SD卡大小

语言和国家

手机服务提供商

该应用程序还具有执行后门功能的能力，下载并安装应用程序、卸载应用、执行shell命令在浏览器中打开URL（虽然此功能似乎是我们分析的样本中正在进行的工作）

什么意思呢？你要你购买了这个手机，手机厂商就可以将你的手机号码、精准位置等敏感信息卖出去，与此同时，还可以在你的手机上安装任何他们想让你安装的应用，并悄悄的运行这些应用。

此前，根据Avast的一份报告，这不是第一次低价Android手机预装了恶意软件。据报道，2016年，许多Android手机都装有恶意软件，但即使在向制造商报告之后，也没有做任何事情。

“我们花了几周的时间试图联系公司，提醒他们注意这些问题，但是，尽管多次使用多种方法试图联系他们，但他们还没有收到回应。”

虽然这并不意味着人们不应该购买便宜的手机，但这确实意味着买家需要做更多的研究，并知道你正在进入什么。

雷锋网 VIA bleepingcomputer

PySpider框架简介及安装

Wed, 15 Aug 2018 12:55:09 CST

PySpider：一个国人编写的强大的网络爬虫系统并带有强大的WebUI。采用Python语言编写，分布式架构，支持多种数据库后端，强大的WebUI支持脚本编辑器，任务监视器，项目管理器以及结果查看器。

PySpider功能简介

PySpider带有强大的WebUI、脚本编辑器、任务监控器、项目管理器以及结果处理器，它支持多种数据库后端、多种消息队列、Javascript渲染页面的爬取，使用起来非常的方便。

PySpider的基本功能：

提供方便易用的 WebUI 系统，可视化地编写和调式爬虫
提供爬取进度监控、爬取结果查看、爬虫项目管理等功能。
支持多种后端数据库，如 MySQL、MongoDB、Reids、SQLite、Elasticsearch、PostgreSQL。
支持多种消息队列、如 RabbitMQ、Beanstalk、Redis、Kombu。
提供优先级控制、失败重试、定时抓取等功能。
对接了 PhantomJS、可以抓取 JavaScript 渲染的页面。
支持单机和分布式部署、支持 Docker 部署。

PySpider的设计基础是：

以python脚本驱动的抓取环模型爬虫
通过python脚本进行结构化信息的提取，follow链接调度抓取控制，实现最大的灵活性
通过web化的脚本编写、调试环境。web展现调度状态
抓取环模型成熟稳定，模块间相互独立，通过消息队列连接，从单进程到多机分布式灵活拓展

PySpider与 Scrapy的比较：

PySpider提供了WebUI，爬虫的编写、调试都是再WebUI中进行。而Scrapy原生是不具备这些功能的，它采取的是代码和命令行操作，但是可通过Portia实现可视化配置。
PySpider调试非常的方便。WebUI操作便捷直观。Scrapy则是使用parse命令进行调试，其方便程度不及PySpider。
PySpider支持PhantomJS来进行Javascript渲染也买你的额采集。Scrapy可以对接Scrapy-Splash组件，这需要额外配置。
PySpider内置了PyQuery作为选择器，Scrapy对接了XPath、CSS选择器和正则匹配。
PySpider的可扩展程度不足，可配置化程度不高。Scrapy可通过对接Middleware、Pipeline、Extension等组件实现非常强大的功能，模块之间的耦合程度低，可扩展程度极高。

如果想要快速方便地实现一个页面的抓取，使用 pyspider 不失为一个好的选择。如快速抓取某个普通新闻网站的新闻内容。但如果应对反爬程度很强、超大规模的抓取、推荐使用 Scrapy、如抓取封 IP、封账号、高频验证的网站的大规模数据采集。

PySpider 的架构

PySpider 的架构主要分为 Scheduler(调度器)、Fetcher(抓取器)、Processer(处理器)三个部分。整个爬取过程受到 Monitor(监控器)的监控，抓取的结果被 Result Worker(结果处理器)处理。

Scheduler 发起任务调度，Fetcher 负责抓取网页内容，Processer 负责解析网页内容，然后将新生成的 Request 发给 Scheduler 进行调度，将生成的提取结果输出保存。

模块	功能
WebUI	web的可视化任务监控 web脚本编写，单步调试异常捕获，log捕获，print捕获等
Scheduler	任务优先级周期定时任务流量控制基于时间周期或前链标签（例如更新时间）的重抓取调度
Fetcher	dataurl支持，用于假抓取模拟传递 method, header, cookie, proxy, etag, last_modified, timeout等抓取调度控制通过适配类似 phantomjs 的webkit引擎支持渲染
Processer	内置的pyquery，以jQuery解析页面在脚本中完全控制调度抓取的各项参数，向后链传递信息异常捕获

PySpider 的任务执行流程的逻辑很清晰，具体过程如下所示：

每个 PySpider项目对应一个 Python 脚本，该脚本定义了一个 Handler 类，它有一个 on_start() 方法。爬取首先调用 on_start() 方法生成最初的抓取任务，然后发送给 Scheduler。
Scheduler 将抓取任务分发给 Fetcher 进行抓取，Fetcher 执行并得到响应、随后将响应发送给 Processer。
Processer 处理响应并提取出新的 URL 生成新的抓取任务，然后通过消息队列的方式通知 Scheduler 当前抓取任务执行情况，并将新生成的抓取任务发送给 Scheduler。如果生成了新的提取结果，则将其发送到结果队列等待 Result Worker 处理。
Scheduler 接收到新的抓取任务，然后查询数据库，判断其如果是新的抓取任务或者是需要重试的任务就继续进行调度，然后将其发送回 Fetcher 进行抓取。
不断重复以上工作、直到所有的任务都执行完毕，抓取结束。
抓取结束后、程序会回调 on_finished() 方法，这里可以定义后处理过程。

PySpider的安装

PySpider的安装非常的简单，只需执行：

pip install pyspider

即可，但是执行过程中可能会报如下错误：

PS C:\windows\system32> pip install pyspider
Looking in indexes: http://mirrors.aliyun.com/pypi/simple/
Collecting pyspider
  Downloading http://mirrors.aliyun.com/pypi/packages/d0/97/d6062c928f53d899ff2a8538fed11d4d425ba3d27c96248a2c601c1c9fef/pyspider-0.3.10.tar.gz (110kB)
    100% |████████████████████████████████| 112kB 178kB/s
Requirement already satisfied: Flask>=0.10 in d:\python37\lib\site-packages (from pyspider) (1.0.2)
Requirement already satisfied: Jinja2>=2.7 in d:\python37\lib\site-packages (from pyspider) (2.10)
Requirement already satisfied: chardet>=2.2 in d:\python37\lib\site-packages (from pyspider) (3.0.4)
Requirement already satisfied: cssselect>=0.9 in d:\python37\lib\site-packages (from pyspider) (1.0.3)
Requirement already satisfied: lxml in d:\python37\lib\site-packages (from pyspider) (4.2.4)
Collecting pycurl (from pyspider)
  Downloading http://mirrors.aliyun.com/pypi/packages/e8/e4/0dbb8735407189f00b33d84122b9be52c790c7c3b25286826f4e1bdb7bde/pycurl-7.43.0.2.tar.gz (214kB)
    100% |████████████████████████████████| 215kB 202kB/s
    Complete output from command python setup.py egg_info:
    Please specify --curl-dir=/path/to/built/libcurl

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 10 in D:\MyConfiguration\qw\AppData\Local\Temp\pip-install-8t_d95bq\pycurl\

发生报错的原因是pycurl没有被正确安装，中间出现了编译错误，解决方案是：到 https://www.lfd.uci.edu/~gohlke/pythonlibs/

下载对应的 .whl文件，并进项安装即可。

PS E:\Download> pip install .\pycurl-7.43.1-cp37-cp37m-win_amd64.whl

安装完成后再命令行执行

pyspider

打开 http://localhost:5000/ 即可访问控制台

参考链接：

PySpider 官网： http://www.pyspider.cn
PySpider 文档： http://docs.pyspider.org/en/latest/
PySpider 源码： https://github.com/binux/pyspider

The post PySpider框架简介及安装 appeared first on 标点符.

使用 iptables 透明代理 TCP 与 UDP

Mon, 16 Jul 2018 17:01:44 CST

本文来自依云's Blog，转载请注明。

很早之前，我在《Linux「真」全局 HTTP 代理方案》中介绍了 redsocks 方案。不过它只处理了 TCP，并没有处理 UDP，DNS 也是采用强制 TCP 的方式来处理的，再加上它本身还要将请求转发到真正的代理客户端，延迟比较高。然后，还可以结合 Wi-Fi 分享或者网络命令空间，玩点更有趣的。

首先要有支持的代理客户端，比如 ss-redir。这个就不用多介绍了，配置好、跑起来即可。以下假设此代理跑在 127.0.0.1 的 $PPROT 端口上。

然后，TCP 的代理设置。使用的是和 redoscks 一样的方案。这个比较简单，除了有一点需要注意： DNAT 到 127.0.0.1 时，需要设置内核选项 net.ipv4.conf.all.route_localnet=1。

最麻烦的是 UDP 的代理，使用的是 TPROXY。首先，需要把要走代理的数据包路由到本地。以下假设我们给要代理的数据包打上标签 1。那么执行：

ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

那个 100 是路由表的编号，可以自己选一个喜欢的。

然后，对于转发流量（来自局域网或者另外的网络命名空间），直接把需要代理的数据包扔给 TPROXY 目标，并且打上对应的标签即可。而对于本地产生的流量，不仅要带有对应的标签，而且需要在 OUTPUT 链打上一个（与之前不同的）标签，触发 reroute check 才行。

最后，对需要代理的数据包设置 iptables 规则：

协议	来源	表	链	目标
TCP	本地	nat	OUTPUT	`-j REDIRECT --to-ports $PPROT`
TCP	转发	nat	PREROUTING	`-j DNAT --to-destination 127.0.0.1:$PPROT`
UDP	本地	mangle	OUTPUT PREROUTING	`-j MARK --set-mark 1` `-j TPROXY --on-port $PPROT --on-ip 127.0.0.1`
UDP	转发	mangle	PREROUTING	`-j TPROXY --on-port $PPROT --on-ip 127.0.0.1 --tproxy-mark 1/1`

比如来自网络命名空间或者局域网的 IP 段 192.168.57.0/24 全部走代理：

iptables -t nat -A PREROUTING -p tcp -s 192.168.57.0/24 ! -d 192.168.57.0/24 -j DNAT --to-destination 127.0.0.1:$PPROT
iptables -t mangle -A PREROUTING -p udp -s 192.168.57.0/24 ! -d 192.168.57.0/24 -j TPROXY --on-port $PPROT --on-ip 127.0.0.1 --tproxy-mark 1/1

今天，我想和你聊聊儿童数据泄露 | 六一特辑

Fri, 01 Jun 2018 22:47:00 CST

今天一早起来，宅宅的朋友圈就被一群天（zhuang）真（nen）的中年儿童刷屏了，纷纷表示这个节日是自己的，为了堵住质疑人士的嘴，还弄出一张严肃的过节证。。。（即使测试的年龄结果是这样的）

总之，这些二三十的“儿童们”对于过节这件事情非常上心，热情一点不比小朋友低~

但其实，这个充满欢声笑语的节日，还有一层颜色是凝重的灰色。它的初衷是为了悼念1942年6月10日的“利迪策惨案”和全世界所有在战争中死难的儿童。1942年6月10日，德国法西斯枪杀了捷克利迪策村16岁以上的男性公民140余人和全部婴儿，并把妇女和90名儿童押往集中营，后者也鲜有人侥幸逃脱。

所以今天，宅宅也想和诸位聊一个有点严肃的话题---儿童数据泄露。

在战争年代有儿童被伤害，在和平年代，也同样有很多儿童正在遭受数据泄露所带来的风险。

市面上过半 Android 应用涉嫌侵犯儿童隐私

跟我们小时候不同，现在的小朋友一出生就生活在信息爆炸的年代（我没有暴露年龄吧？），各类智能电子设备就是他们儿时的玩具，而商家们也绞尽脑汁在上面搭载丰富的应用来获取关注。

但是，这些眼花缭乱的应用又有多少是考虑到了儿童数据安全的？有家研究机构认真的做了一波调查。

根据国际计算机科学研究所在今年的一份新研究报告，市面上起码有过半的 Android 应用，涉嫌违反了《儿童在线隐私保护法案》（COPPA），现在来说说这个结果是如何得出的。

研究人员首先开发并使用了一款自动化工具，对 5855 款标记为“少儿或家庭软件”的 Android 应用进行了分析，一共发现了 3337 款面向儿童或者家庭的手机软件在违规采集少儿隐私信息。

其中，281 个是在并未获得家长同意的条件下，违规采集少儿用户的通讯录和位置信息；另外1100个安卓软件将少儿的隐私信息开放给了外部第三方使用（使用功能受到限制）；而剩下的2281款软件涉嫌违反谷歌的使用条款（与分享持久性标示符有关，可导致跨设备平台的身份追踪）。

在这些数据中，并未包含iOS平台的手机软件。

研究指出，通常苹果 iOS 在第三方软件获取用户隐私信息以及对外分享信息方面受到更加严格的管理，用户隐私保护要好于安卓系统。

出现这种状况的原因之一，是因为谷歌的 Android 是面向全球的开源的系统，各手机厂商可以自由修改定制，对于应用的隐私管理规定，实际上掌握在这些手机厂商手中，而不是谷歌或是各国政府。

千万别以为我这是在给 iOS 打call，苹果的问题同样严重！

iOS 问题也很严重，大量儿童隐私数据已在暗网上售卖

对于家长而言，不得不接受这样一个现实---手机等智能设备正在越来越多的吸引孩子的注意力。

嗅觉灵敏的商家，早就看到了这块巨大的市场，一款名为 TeenSafe 的监管应用就俘获了不少家长的心，他们借此可以掌握小孩的所处位置以及知晓他们发送短信的习惯。

与普通的苹果用户不同，要想实现上述功能，必须双方都下载这个应用，而且必须关闭苹果的双重认证功能，这样才能更容易的登录并查看到孩子的 iCloud 数据，这本是一个为了儿童安全而设计的应用。

但不久前，一位安全研究员 Robert Wiggins 就发现， TeenSafe 这款家长监管应用，是将儿童的数据存放在两台亚马逊服务器上，而这些数据却没有被保护起来，已经有几千个账户信息被泄漏。其中一台服务器保存的是测试数据，而另一台中包含儿童的 Apple ID 邮箱地址和密码，不仅是儿童的账号密码，一些家长的苹果账号恐怕也已经泄露。

事件曝光后，TeenSafe 向媒体发表声明称，它们已经关闭了相关服务器并开始向可能受到影响的客户发出警告。

其实，TeenSafe 并不是第一个被曝光的家长监管应用，早在2015年，另一款针对儿童的安全应用“mSpy”也曾暴露出严重的安全问题，在东窗事发前，这款标榜“家长可以通过 mSpy 对小孩的移动设备进行追踪，7×24小时在线客服和256位加密更让mSpy保障孩子安全”的应用，受到大批父母青睐。

但随后，安全研究人员发现，大量mSpy用户的邮箱、短信、支付信息、位置等数据出现在“暗网”上，这直接导致数以千计的儿童数据陷入危险境地。

这还是被曝光出来的安全问题，但还有多少是黑客已经掌握但还没有被公布的，我们不得而知。

近两年的儿童数据泄露事件

接下来，雷锋网为大家盘点几类儿童数据的安全事件，也许未来你或你的家人在考虑成为使用者时，会有更加理性的认知。

2017年5月，一款名为“Cayla”的智能玩偶遭到了德国的禁售，引起了全球各地父母的担忧，他们主要担忧的一个潜在威胁就是：孩子和其他人之间的对话会被记录并转发。

而在稍早之前，联网玩具 CloudPets 的生产商 Spiral Toys 就遭遇了数据泄漏事件，泄漏了超过两百万儿童及其父母的语音信息，以及超过 80 万电子邮件和密码。

2017年11月，挪威消费者委员会（NCC）和安全公司 Mnemonic 发表的研究报告指出，在给孩子买 Gator 或者 Xplora 这种智能手表时，父母应该三思。因为用户和掌握用户数据的公司之间没有法律协议，在被调查的品牌手表中，没有一款手表可以删除孩子的数据，那些手表厂商也无法确保营销人员不会用这些数据向孩子推销产品。

更为严重的是，对于所有数据的存储位置，商家也没有明确说明。该报告的作者还担心，这种智能手表向用户灌输了一种“错误的安全感”。儿童智能手表一贯推崇它具有紧急呼叫按钮，在儿童遇到紧急状况时，可以按此按钮，分享他们的地理位置，这样当孩子离开了某个特定领域，父母可以收到警示。

但事实上，这些功能在现实测试中被证明是“不可靠的”！

除了娱乐性的应用和玩具，国外安全人员还发现了更加触目惊心的情况---多家医院的儿童病例信息和学校的学生档案也正在被兜售！

黑客 “Skyscraper” 曾在2017年4月向媒体爆料，在暗网上有超过50万份儿童病历可供人下载。这些病历包含了这些儿童及其父母的姓名、社会保险号、电话号码以及住址。

虽然该媒体并未点名被黑客攻击的机构名称，但它提到，除了医院，还有多所小学系统被黑客攻击，超过20万份学生档案被泄露。

说了这么多国外的情况，我国的状况又如何？

据相关数据显示，国内教育 APP总量超过7万个，约占全国APP市场份额的10%，其中，家长对于幼教类APP的花费在教育类APP中位居榜首！这类软件窃取用户隐私的行为非常猖獗，追踪用户位置更会对儿童的人身安全造成显著威胁。

而在未来，类似智能手表、智能玩具、智能音箱等包含有大量的身份信息甚至是互动信息的物联网设备，将越来越多的进入到儿童的生活中，针对数据泄漏的问题，也许欧洲刚刚出台的 GDPR（通用数据保护条例）对我们有些参考作用。

GDPR 对未成年人的数据保护有特殊要求，它规定企业和组织必须取得父母的同意，才能处理 16 岁以下儿童的个人数据，这意味着，未来取得儿童的数据将变得更为困难，而父母作为监护人也将承担更大的责任。

其实，今天正好是《中华人民共和国网络安全法》正式施行一周年，在去年的今天，与《网络安全法》同步施行的还有最高人民法院和最高人民检察院发布的《关于办理侵犯公民个人信息刑事案件适用法律若干问题的解释》（以下简称《解释》），《解释》中明确了“公民个人信息”的范围，以及非法获取公民个人信息的认定标准及量刑标准等。

未来，如果你认为自己或者家人的个人信息受到了侵犯，可以拿起法律武器保护自己。现在，宅宅把其中重点的内容整理如下：

第一，扩大“公民个人信息”范围并明确处理罚则。电商、社交、搜索、地图、直播、云等，收集使用的用户行踪轨迹等活动情况以及全平台账号密码信息被纳入“公民个人信息”范围，未来，大家可以根据具体情况来根据法律条例找到标尺和抓手。

第二，收集个人信息，需让用户“知情同意”。“网络产品、服务具有收集用户信息功能的，其提供者应当向用户明示并取得同意”。

第三，在提供互联网服务的同时，要有能力采取技术措施和其他必要措施，保障网络安全、稳定运行，有效应对网络安全事件，防范网络违法犯罪活动，维护网络数据的完整性、保密性和可用性。

目前，国内的这两部法规都从能够获取用户个人信息的互联网企业及个人，到获取信息后的可处理方式等做了规范，但对于针对违法获取和处理儿童信息，还没有具体的处罚措施，所以未来针对儿童的数据安全仍然任重而道远。

雷锋网 VIA 电脑报、freebuf

最后，希望这篇有些严肃的文章没有影响各位过节的心情，在这里，还是要祝愿各位宝宝节日快乐，特此奉上雷锋网的儿童节海报一张，好了，我去吃零食了~

绕过学校宽带计费系统思路分享

Mon, 23 Apr 2018 08:30:53 CST

PS：本文仅用于技术讨论与分享，严禁用于任何非法用途

没错，就是大家通常想的那样，搭建VPN，但是我是怎么搭建VPN的呢？

校园网环境：

1.每个宿舍楼之间能互相通讯，同时登陆宽带需要收费，每个月50块左右，每天晚上23：30准时断网（PS：并没有断电）

2.教学楼办公区之间，不需要宽带收费，只需要学生自己的账号就能登录，全天24小时不断网不断电（PS：但是教学区域，电脑不会24小时开启）

3.学校的无线和有线是连在一起的可以相互通讯

按道理来说，我这样做是不对的，但是为了每天有网上有WIFI连，我豁出去了，穷得吃土了，这是我们学校的宽带认证界面，使用portal认证方式

一丶搜集学校的IP段

因为学校的网络是互通的，我用自创推算法推算学校的IP段，学校平时的教学机是会关机的（基本全是WIN7），搭建了也没用，重启之后也会还原，毕竟我要的是免费上网加24小时不断网haha~~~

之前我就调查清楚了，教学楼的IP地址是同一个网段，172.18.x.x 每一层楼都一样的，除了第三位网络位不同，并且我还要找出24小时不关机的机器，这是很难的，我们学校有个中兴实验室里面全是服务器和云虚拟机，在想试试能不能拿到，于是我拿出了神器metasploit,msf自带ms017辅助模块和攻击模块，因为学校大多数都是win7，我也就想碰碰运气，利用一下这个远古漏洞！因为我要实现24小时不断网，我选择在晚上23点后再扫描。

二丶利用ms017漏洞

1.打开kali，进入msfconsole控制台

2.找到ms017的辅助扫描模块

我们使用scanner这个扫描漏洞模块来扫描所有ms17漏洞的机器

设置好扫描的IP段线程

run启动

扫描完成之后，发现只有172.18.114.x这个段存活，说明这个就是之前我要找的中兴实验室的网段，全是存活的win7和一台2012

接下来我只要利用攻击模块进入系统提权就行(随便选了台WIN7）2008搭建麻烦

加载模块

成功连接进入shell

直接添加用户到管理员用户组

因为是win7，需要我开启3389

利用msf getgui 开启远程管理

三、搭建VPN

1.按照顺序开启搭建VPN的服务

win7还是自带的搭建简单

Telephony 、Secure SocketTunneling Protocol Service 、Windows EventLog 、Remote Access AutoConnection Manager 、Remote Access ConnectionManager

IP划分到WIN7这个段就行，不然会不能访问计费系统

重启

切换到本机连接VPN

已经划分到114的网段

打开网页，访问计费系统IP

已经成功划分到教学楼的网段，现在登录是免费而且24小时不断网

四．总结

长期观察校园环境，注意细节，挺简单的，学校到处逛逛，会发现意想不到的收获

* 本文作者：你听得到，转载注明来自Freebuf.com

HTTP 连接管理进化论

Thu, 08 Mar 2018 09:47:40 CST

连接管理是一个 HTTP 的关键话题：打开和保持连接在很大程度上影响着网站和 Web 应用程序的性能。在 HTTP/1.x 里有好些个模型： 短连接（short-lived connections）, 持久连接（persistent connections）, 和 HTTP 管道（HTTP pipelining）。

HTTP 的传输协议主要依赖于 TCP 来提供从客户端到服务器端之间的连接。在早期，HTTP 使用一个简单的模型来处理这样的连接—— 短连接。这些连接的生命周期是短暂的：每发起一个请求时都会创建一个新的连接，并在收到应答时立即关闭。

这个简单的模型对性能有先天的限制： 打开每一个 TCP 连接都是相当耗费资源的操作。客户端和服务器端之间需要交换好些个消息。当请求发起时，网络延迟和带宽都会对性能造成影响。现代浏览器往往要发起很多次请求(十几个或者更多)才能拿到所需的完整信息，证明了这个早期模型的效率低下。

有两个新的模型在 HTTP/1.1 诞生了。首先是 长连接模型，它会保持连接去完成多次连续的请求，减少了不断重新打开连接的时间。然后是 HTTP Pipelining，它还要更先进一些，多个连续的请求甚至都不用等待立即返回就可以被发送，这样就减少了耗费在网络延迟上的时间。

要注意的一个重点是 HTTP 的连接管理适用于两个连续节点之间的连接，如 hop-by-hop，而不是 end-to-end。当模型用于从客户端到第一个代理服务器的连接和从代理服务器到目标服务器之间的连接时(或者任意中间代理)效果可能是不一样的。HTTP 协议头受不同连接模型的影响，比如 Connection 和 Keep-Alive，就是 hop-by-hop 协议头，它们的值是可以被中间节点修改的。

短连接（short-lived connections）

HTTP 最早期的模型，也是 HTTP/1.0 的默认模型，是短连接。每一个 HTTP 请求都由它自己独立的连接完成；这意味着发起每一个 HTTP 请求之前都会有一次 TCP 握手，而且是连续不断的。

TCP 协议握手本身就是耗费时间的，所以 TCP 可以保持更多的热连接来适应负载。短连接破坏了 TCP 具备的能力，新的冷连接降低了其性能。

这是 HTTP/1.0 的默认模型(如果没有指定 Connection 协议头，或者是值被设置为 close)。而在 HTTP/1.1 中，只有当 Connection 被设置为 close 时才会用到这个模型。

持久连接（persistent connections）

短连接有两个比较大的问题：创建新连接耗费的时间尤为明显，另外 TCP 连接的性能只有在该连接被使用一段时间后(热连接)才能得到改善。为了缓解这些问题， 持久连接（persistent connections） 的概念便被设计出来了，甚至在 HTTP/1.1 之前。或者这被称之为一个 keep-alive 连接。

HTTP/1.1(以及 HTTP/1.0 的各种增强版本)允许 HTTP 设备在事务处理结束之后将 TCP 连接保持在打开状态，以便为未来的 HTTP 请求重用现存的连接。 在事务处理结束之后仍然保持在打开状态的 TCP 连接被称为持久连接。非持久连接会在每个事务结束之后关闭。持久连接会在不同事务之间保持打开状态，直到客户端或服务器决定将其关闭为止。

一个持久连接会保持一段时间，重复用于发送一系列请求，节省了新建 TCP 连接握手的时间，还可以利用 TCP 的性能增强能力。当然这个连接也不会一直保留着：连接在空闲一段时间后会被关闭(服务器可以使用 Keep-Alive 协议头来指定一个最小的连接保持时间)。

重用已对目标服务器打开的空闲持久连接，就可以避开缓慢的连接建立阶段。而且，已经打开的连接还可以避免慢启动的拥塞适应阶段，以便更快速地进行数据的传输。

持久连接也还是有缺点的；就算是在空闲状态，它还是会消耗服务器资源，而且在重负载时，还有可能遭受 DoS attacks 攻击。这种场景下，可以使用非持久连接，即尽快关闭那些空闲的连接，也能对性能有所提升。

HTTP/1.0 里默认并不适用持久连接。把 Connection 设置成 close 以外的其它参数都可以让其保持持久连接，通常会设置为 retry-after。

在 HTTP/1.1 里，默认就是持久连接的，协议头都不用再去声明它（但我们还是会把它加上，万一某个时候因为某种原因要退回到 HTTP/1.0 呢）。

持久连接与并行连接配合使用可能是最高效的方式。现在，很多 Web 应用程序都会打开少量的并行连接，其中的每一个都是持久连接。

盲中继(blind relay)

那些不理解 Connection 首部，而且不知道在沿着转发链路将其发送出去之前，应该将该首部删除的代理。很多老的或简单的代理都是 盲中继(blind relay)，它们只是将字节从一个连接转发到另一个连接中去，不对 Connection 首部进行特殊的处理。

HTTP Pipelining

默认情况下，HTTP 请求是按顺序发出的。下一个请求只有在当前请求收到应答过后才会被发出。由于会受到网络延迟和带宽的限制，在下一个请求被发送到服务器之前，可能需要等待很长时间。

流水线是在同一条长连接上发出连续的请求，而不用等待应答返回。这样可以避免连接延迟。理论上讲，性能还会因为两个 HTTP 请求有可能被打包到一个 TCP 消息包中而得到提升。就算 HTTP 请求不断的继续，尺寸会增加，但设置 TCP 的最大分段大小 MSS (Maximum Segment Size) 选项，任然足够包含一系列简单的请求。

并不是所有类型的 HTTP 请求都能用到流水线：只有 idempotent 方式，比如 GET、HEAD、PUT 和 DELETE 能够被安全的重试：如果有故障发生时，流水线的内容要能被轻易的重试。

今天，所有遵循 HTTP/1.1 的代理和服务器都应该支持流水线，虽然实际情况中还是有很多限制：一个很重要的原因是，任然没有现代浏览器去默认支持这个功能。

HTTP 流水线在现代浏览器中并不是默认被启用的：

Web 开发者并不能轻易的遇见和判断那些搞怪的代理服务器的各种莫名其妙的行为。

正确的实现流水线式复杂的：传输中的资源大小，多少有效的往返时延 RTT(Round-Trip Time) 会被用到，还有有效带宽，流水线带来的改善有多大的影响范围。不知道这些的话，重要的消息可能被延迟到不重要的消息后面。这个重要性的概念甚至会演变为影响到页面布局！因此 HTTP 流水线在大多数情况下带来的改善并不明显。

流水线受制于队头阻塞 Head-of-line blocking (HOL blocking) 问题。

由于这些原因，流水线已经被更好的算法给代替，如 multiplexing，已经用在 HTTP/2。

HTTP/2 的长连接与多路复用（multiplexing）

长连接

在HTTP/2中，客户端向某个域名的服务器请求页面的过程中，只会创建一条TCP连接，即使这页面可能包含上百个资源。而之前的HTTP/1.x一般会创建6-8条TCP连接来请求这100多个资源。单一的连接应该是HTTP2的主要优势，单一的连接能减少TCP握手带来的时延（如果是建立在SSL/TLS上面，HTTP2能减少很多不必要的SSL握手，大家都知道SSL握手很慢）。

另外我们知道，TCP协议有个滑动窗口，有慢启动这回事，就是说每次建立新连接后，数据先是慢慢地传，然后滑动窗口慢慢变大，才能较高速度地传，这下倒好，这条连接的滑动窗口刚刚变大，http1.x就创个新连接传数据（这就好比人家HTTP2一直在高速上一直开着，你HTTP1.x是一辆公交车走走停停）。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。

所以，HTTP2中用一条单一的长连接，避免了创建多个TCP连接带来的网络开销，提高了吞吐量。

帧（frame）

HTTP/2 是基于帧(frame)的协议。采用分帧是为了将重要信息都封装起来，让协议的解析方可以轻松阅读、解析并还原信息。 帧（frame） 是HTTP/2中数据传输的最小单位，因此帧不仅要细分表达HTTP/1.x中的各个部份，也优化了HTTP/1.x表达得不好的地方，同时还增加了HTTP/1.x表达不了的方式。

HTTP/2 帧结构如下：

流（Stream）

HTTP/2 规范对流(stream)的定义是： HTTP/2 连接上独立的、双向的帧序列交换。你可以将流看作在连接上的一系列帧，它们构成了单独的 HTTP 请求和响应。如果客户端想要发出请求，它会开启一个新的流。然后，服务器将在这个流上回复。这与 h1 的请求 / 响应流程类似，重要的区别在于，因为有分帧，所以多个请求和响应可以交错，而不会互相阻塞。流 ID（帧首部的第 6~9 字节）用来标识帧所属的流。

特点如下：

一个HTTP/2连接可同时保持多个打开的流，任一端点交换帧
流可被客户端或服务器单独或共享创建和使用
流可被任一端关闭
在流内发送和接收数据都要按照顺序
流的标识符自然数表示，1~2^31-1区间，有创建流的终端分配
流与流之间逻辑上是并行、独立存在

多路复用（multiplexing）

就是说在一个TCP连接上，我们可以向对方不断发送一个个的消息，这里每一个消息看成是一帧，而每一帧有个 stream identifier 的字段标明这一帧属于哪个 流，然后在对方接收时，根据 stream identifier 拼接每个 流 的所有帧组成一整块数据。我们把 HTTP/1.x 每个请求都当作一个 流，那么请求化成多个流，请求响应数据切成多个帧，不同流中的帧交错地发送给对方，这就是HTTP/2中的 多路复用。

从上图我们可以留意到：

不同的流在交错发送；
HEADERS 帧在 DATA 帧前面；
流的ID都是奇数，说明是由客户端发起的，这是标准规定的，那么服务端发起的就是偶数了。

多路复用让HTTP连接变得很廉价，只需要创建一个新流即可，这不需要多少时间，而在 HTTP/1.x 时代却要经历三次握手时间或者队首阻塞等问题。而且创建新流默认是无限制的，也就是可以无限制的并行请求下载。不过，HTTP/2 还是提供了 SETTINGS_MAX_CONCURRENT_STREAMS 字段在 SETTINGS 帧 上设置，可以限制并发流数目，标准上建议不要低于 100 以保证性能。

实际的传输可能是这样的：

只看到 帧(Frame)，没有 流（Stream）嘛。

需要抽象化一些，就好理解了：

每一个帧可看做是一个学生，流可以认为是组（流标识符为帧的属性值），一个班级（一个连接）内学生被分为若干个小组，每一个小组分配不同的具体任务。
HTTP/1.x 一次请求-响应，建立一个连接，用完关闭；每一个小组任务都需要建立一个班级，多个小组任务多个班级，1:1比例
HTTP/1.1 Pipeling 解决方式为，若干个小组任务排队串行化单线程处理，后面小组任务等待前面小组任务完成才能获得执行机会，一旦有任务处理超时等，后续任务只能被阻塞，毫无办法，也就是人们常说的线头阻塞
HTTP/2 多个小组任务可同时并行（严格意义上是并发）在班级内执行。一旦某个小组任务耗时严重，但不会影响到其它小组任务正常执行
针对一个班级资源维护要比多个班级资源维护经济多了，这也是多路复用出现的原因。

参考

付费制会员体系初探

Fri, 26 Jan 2018 08:05:06 CST

会员制在中国普遍形态是积分卡，也就是为用户的历史消费记录创建奖励的一种方式。与会员积分制不同的是，付费会员制有几个相当明显的优势。首先，付费会员制激励效果强。从激励手段来看，积分会员制单一且被动。原因在于积分会员制仅以消费者购买金额来代表消费能力，虽是多买多得，但积分所换商品或优惠往往是一种简单的馈赠，且不一定如消费者意愿使其获得与需求对应的商品。

亚马逊Prime

Amazon Prime是贝索斯在2005年推出的付费的会员服务，这个服务最吸引顾客的地方莫过于免运费 2 日送达服务。诞生之初，Prime 被描述成为一个简单的快递服务，目的是鼓励消费者增加购买。《连线》杂志日前刊文，评价十岁的 Prime 是“最奇怪也是最成功的商业模式”。推出 Prime 服务后，亚马逊急剧扩张。据《财富》报道，过去 10 年，可通过 Prime 订购的商品从100 万种增长到了 2000 万种。Prime 还积极进军国际市场，先是登陆日本、英国和德国，然后又挺进法国、意大利和加拿大。除了实物购买，亚马逊也在快递、流媒体服务上大玩花样：推出前 6 年，Prime 只关乎快递服务，2011 年 2 月开始，亚马逊 Prime 增加了 Prime Instant Video 视频服务，会员能够通过亚马逊观看约 4 万部电影和电视剧集以及 50 万本 Kindle 电子书的借阅服务；2013 年，亚马逊公布了 Amazon Prime Air 计划，计划用无人机来运送小型包裹；2014 年，Prime 陆续推出了 Prime Music 和 Prime Photos 服务，会员可以享受免费的在线音乐、存储不限量的照片，年费也从 79 美元悄然提高到 99 美元；年底又在曼哈顿推出了“一小时送达”服务…

参考地址： https://en.wikipedia.org/wiki/Amazon_Prime

亚马逊Prime美国版会员权益

邮寄权益：

免费二日送达
免费当日送达（部分地区）
免费2小时送达（部分地区、部分商品）
发售日送达（针对预售的商品）
慢递服务选择（可获得额外代金券）

流媒体权益:

无限量的电视和电影节目观看资格
收费电视台如HBO、SHOWTIME、STARZ的观看（仅需支付$4.99–$14.99每月）
免费、无广告收听上万首歌曲
以折扣的方式获取亚马逊音乐无限计划
以折扣的方式获取Twitch上的游戏

购物权益：

Amazon Prime Rewards Visa Signature Card可获得5%购物返现
Amazon Prime Store Card消费可获得5%的购物返现
Amazon Dash for Prime，一款智能硬件，可以一键下单。
Amazon Fresh：可化一定的金钱享受生鲜配送服务
Prime Pantry：可购买部分食品杂货
亚马逊家族产品的优惠和折扣
提前30分钟优先获得Z秒杀
Amazon Elements：亚马逊自有品牌商品

阅读权益：

超过35万本Kindle 电子书免费下载
优先阅读部分书籍
有声书的收听
免费获得6个月的华盛顿邮报

其他权益：

会员分享，分享自己的会员权益给家人（一个会员可以2个人享用）
免费的无限照片存储空间
不时会推出的prime会员专享活动

参考地址： https://www.amazon.com/gp/help/customer/display.html/?nodeId=201910640

Amazon Prime 是否是成功的？

Prime 最大的一个谜团，是它的会员到底有多少人。时至今日，亚马逊官方从未透露具体数字，2013 年，亚马逊仅仅称用户量达到“数以千万计”。预估Prime会员的量在8500 万。另有媒体披露，亚马逊的美国用户注册Prime会员的比例首次超过50%。如此算来，仅仅 99 美元的会员费就让 Prime 每年进账40 亿美元。不过，贝索斯也说，2014 年 Prime 在发货的成本上花费了“数十亿”，而且亚马逊还为即时视频投入了 13 亿美元。

亚马逊究竟能不能通过 Prime 服务挣到钱呢？根据第三方机构 MorningStar 的调查，2013年，亚马逊在每一位 Prime 会员身上的平均花费包括55美元的实物运费和35美元的数字内容花费，共计90美元。而2003年的 Prime 服务年费是79美元，也就是说亚马逊要为每一位 Prime 用户付出11美元，但是 Prime 用户的消费能力更强，平均下来每年会比非 Prime 用多给亚马逊带来78美元的利润，看起来亚马逊在 Prime 服务上是有利可图的。但实际上 Prime 还有一个月的免费试用（许多人用完后会取消续费），同时市场可能会有的小额 Prime 代下单等情况，估计亚马逊在这个服务上是挣不到钱的。

据《The Everything Store》一书的记载，在开创 Prime 服务之初，亚马逊也曾面临定价的困扰，公司没有清晰的财务模型来确定一个合适的价格，当时团队制定了几个价格，包括 49 美元和 99 美元。但贝索斯最终将价格定为每年 79 美元，因为如果费用高些可以阻止顾客轻易退出，而费用过低顾客便会经常退出。实际上，对于 Prime 服务是否会促使顾客购买媒体产品以外的其他产品，亚马逊也没数。因为如果快件运输成本是 8 美元，Prime 会员一年达到 20 笔订单，那么公司需要承担的运输成本便达到 160 美元，远超 79 美元的定价。

在知乎上，一名amazon前员工的回复：Amazon从售卖Prime上获得的收益（R）是每个Prime 不到20美金左右（2013），现在涨价了，这个值也绝不会超过25。为什么amazon在即使亏损的情况下，依然还要提供Prime呢？因为Prime被定为为amazon的非企业级服务的核心，对amazon有着至关重要的作用。

Amazon Prime 的价值是什么？

Amazon Prime 对亚马逊来说是意义重大。Prime 能走到今天，原因说起来可能并不复杂——用户觉得这个服务实惠，亚马逊觉得这个服务对公司发展有好处。贝索斯认为，快速送货服务将会改变顾客的消费习惯：当网购变得容易时，顾客会提高他们的消费额，而这将促进公司的飞轮效应产生良性循环，从而降低运输成本。Prime 不仅培养了用户的忠诚度，使得消费者在线购物时不会考虑其他电商平台，同时还激励了用户的购买行为，盘活了 Kindle 的内容消费。

亚马逊推出这项服务的目的是增加用户粘度和忠诚度，促进消费，最终形成自己的生态系统。《华盛顿邮报》的首席数字官拉文德兰曾这样评价亚马逊 Prime 会员服务：“其实收 79 美元并不重要，收费的目的是想改变人们的心理定势，以便它们不再选择其他地方消费”。分析师 Mahaney 说：“Prime 让亚马逊铸造了一条护城河，可以真正的锁住用户。”

用户的反馈

用户A：自从花费50镑加入Amazon Prime会员后，生活中要用到的必需品，除了食物，其他都在Amazon上购买。
用户B：作为一个懒人，我不会找deal，也不会找返还积分的网站，更不会因为有促销而买暂时不需要的东西，我只需要一个网站，给我一个简单的可以接受的价格，点击确认之后就准备发货。

Amazon Prime 在美国受欢迎的原因是什么？为什么不把美国模式直接搬到中国？

亚马逊Prime中国版会员权益：

数百万海外购商品免邮，全年无限次！海外购单笔订单满200元可享（不含预估进口税费）
国内订单零门槛免邮，全年无限次！无订单金额限制
精选Z秒杀，会员优先购！Prime会员可提前30分钟优先抢购部分“Z秒杀”产品

参考链接： https://www.amazon.cn/gp/help/customer/display.html/ref=hp_sd_prime_about?ie=UTF8&nodeId=201910360

大概可以看出来，中国的 Amazon Prime 可以说是一个免邮费的会员计划；而美国的 Amazon Prime 得益于服务与硬件所搭建起来的生态，提供的服务更加吸引人。但是亚马逊并没有直接把美国模式全部搬过来，主要原因：

Prime提供免费隔日送达服务，在中国完全没有竞争力。要知道由于美国人工费用很贵，人口居住又比较分散，快递远没有国内发达，一般快递基本都要一个礼拜才能送到，相比国内京东的上午下单下午送达，完全没有竞争力。
流媒体服务。Prime是提供部分影视作品免费观看的，对于在中国习惯观看免费的视频的我们可能难以想象，美国国影视贵，一部电影要$10 +，一季电视剧要更多，买了prime起码能看不少免费电影电视。在国内，免费视频和免费音乐不是应该的吗？。
Kindle配套服务。由于版权意识强烈，在美国基本没有盗版书存在，而正版书又都是很贵的，Prime提供了对部分Kindle书籍的免费租阅服务，并常常有书籍对Prime用户特价，这对于Kindle用户而言简直超值。

参考链接： https://www.wired.com/2015/02/amazon-prime-one-bizarre-good-business-ideas-ever/

亚马逊Prime Day

Prime Day是亚马逊在2015年7月15日开始推出的专为prime会员举行的为期一天的全球范围购物节，简单的理解为淘宝天猫的双十一吧。活动当天prime会员可以在亚马逊覆盖的全球各个国家站点参加成千上万的劲爆秒杀活动（相对来说要比平时便宜个15%左右，同时免配送费），几乎涵盖了所有的品类。会员能够以独享的最大折扣购买他们想要的商品，每个人都能找到自己想要的东西，而卖家可以通过在卖家后台提报秒杀来参加。

2017亚马逊Prime会员日销售额增长了60% 仅仅针对Prime会员推出的亚马逊Prime Day全球购物日，继去年第一次举办后，今年再次取得巨大成功，在吸引更多新Prime用户加入之外，在美国的销售额较去年购物日也增长了50%，甚至比传统的Cyber Monday（美国感恩节后的网上购物节）的销售额也提高近20%。这其中，亚马逊重度用户（每个月在亚马逊购物超过4次以上的用户）贡献了Prime Day销售的56%。

京东Plus会员

亚马逊Prime服务的内容，是任意金额购物都免除美国境内运费以及两个工作日到达，再就是每年的Prime Day有Prime会员专享的超低折扣价商品。2015年底的时候京东仿照亚马逊Prime服务推出了 Plus会员，由于国内的电商环境与美国有较大的差异，Plus会员并没有照搬亚马逊的模式。

京东先前的会员级别

京东Plus会员价格：

钻石会员￥109/年
金牌会员￥129/年
银牌会员￥139/年

京东Plus会员目前拥有的权益：

1000本电子书畅读，支持可以畅读的书籍大部分是小说类的，价值不是很大。
24小时专属客服，没什么特别的价值。
百万会员特价商品，部分商品可以有几元的差价优惠。
100元/月全品类优惠券，使用有门槛，105元-5元起步，一直到2000元-80元。领取后24h使用。
10倍购物返金豆，京豆和现金的抵扣比例为100:1，花钱多的这一项可以回本。
360元/年运费券礼包，每月5张，想买东西的时候不用想着凑单。
服饰9折（每月折扣券），服饰是高利润的品类，个人没有在京东购习惯，价值不大。
免费上门退换货，这个本来就有的服务，价值不大。
Plus Day 专属购物节，意义不大。

除此之外，部分优惠券的领取，仅限Plus会员也是一个特殊的福利。

自从推出Plus会员后，原先的会员体系就废了。但总体来看，付费的会员制在用户的感知度上更高了。

网易考拉：黑卡会员

黑卡会员的权益

自营96折
税费券（每月2张，每张10元）
运费券（每月2张，每张10元）
黑卡专享价
黑卡专享券（一次性发放9元减10元，139元减69元）
售后无忧（客服优先通道，退货退款优先处理）

黑卡价格：279元

线下零售：山姆会员超市

山姆会员会籍，年费260元/年，享受权益：

高品质精选商品：名产地、好品牌、高等级
进口商品多选择，来自沃尔玛全球采购渠道
高性价比的自由品牌商品
续费或者办理新卡时赠送礼品或优惠券

付费会员制大行其道的原因

付费制会员对用户的价值

用户所获权益和优惠力度都被成倍加强。（获得了VIP的礼遇）

付费制会员对企业的价值

对核心的用户建立了差异化的服务，使得彼此的关系更加亲密和持久，提升忠诚度。
能够更加专注于服务核心用户，以提升所有平台用户对高服务品质的向心力。
在协议期内起到长期激励的作用，提升消费频次。
能够获取会员的信任而形成口碑，便于传播。
有较强的家庭消费辐射能力。
付费会员对品质的要求更高，愿为高品质付出20%的溢价。

电商发展渐入瓶颈期，增速越来越慢。只有让顾客成为自家的忠实客户，才能在“电商下半场”比拼中获胜。付费制会员重新定义了盈利模式。打破“低进高出”的零售规则。重新打造了企业与消费者的关系（以前零售商是要赚消费者钱，在价格方面双方是对立的。而今变成消费者是零售商的雇主，零售商为保证雇主的权益，必然要从消费者的角度出发，想尽办法让消费者购物更简便，买到价格最低，品质最可靠的商品，把零售的加价去掉。）

付费制会员推行可能存在的问题

付费会员制并不主流。无论是传统零售还是电商，目前国内采用付费会员制的企业都不多。尽管独享类付费会员店进入中国已超过二十年，但发展一直较为缓慢，并不主流。不少会员店由于“水土不服”已撤出中国市场或转型。目前，麦德龙、永辉会员体验店等以会员店形式运营的店铺，实际并未向消费者收取会员费。但目前来看，付费会员制在中国的零售业依然是比较小众的存在，这可能与付费会员制所存在的内在矛盾有所关联。

1 、以消费者收入为准，每个层级的消费者均有摇摆现象。

艾瑞的报告显示，无论是月收入3000元以下的消费者还是月收入20000元以上的消费者，都存在绝大部分的摇摆人，甚至有不少人表示明确拒绝购买会员。虽然收入与会员购买意愿大致成正比，但绝大部分消费者相对理智

2 、是否能持续强力击中用户痛点，而不是呈现服务周期性衰退。

对消费者来说，衡量付费会员是否值得的主要标准可能只有一个，比如商品优惠力度是否足够。对高频购物的人群来说，仅商品折扣便能把他们变成忠实的付费会员。但艾瑞报告显示，2017年京东“PLUS会员”和山姆会员商店的续费率均在70%左右。就续费率来看，用户的粘性已经比较强，但选择不续费的用户考虑的问题可能来自两方面。首先，消费频率不及预期，会员优惠没有充分享受到；其次，优惠不及预期，比如心仪商品没有折扣，导致消费欲望降低。对放弃续费的用户来说，成为付费会员可能不会改善或不会明显改善其用户体验，而这又与每个人的消费偏好存在密切关系，难以预测。

3 、与免费会员制的冲突。

对本就不关心会员福利的用户来说，付费会员如果不能拿出区别于免费会员的爆点福利，是很难征服粘性处于中下程度的用户的。付费会员制虽然是针对用户消费心理的一套改善后服务机制，但对不同收入、不同消费习惯的消费者群体来说，电商和零售商们在推出付费会员制前，依然需要做出许多考虑和分析，以提高这一制度本身的容错能力。

付费会员制正确的打开方式是什么？

为用户不论是在线上还是线下购买，其核心关注目标都是产品本身，或者说是对产品的拥有欲望。若想进一步深耕付费会员制，不论是线上的电商巨头们，还是线下的零售巨头，都需要知己知彼。根据艾瑞咨询发布的《2017年中国零售业付费会员消费洞察》报告，2017年付费会员对会员权益的预期中，用户最大的需求为获得更多类型的优惠券，其次为购物专享赠品、会员日抢购、赠送运费券等。

1 、摸透用户需求和痛点

购买商品时，用户的比价心理是常态，所以首先祭出的应该是价格上的优惠。比如京东推出的会员日以及银泰的线下折扣等，更常见的是我们在超市里看到的会员价。其次就是提供看似微不足道但不可或缺的服务。

2 、寻找合适的目标用户

付费会员画像：以一二线城市用户为主
付费会员画像：以高学历白领为主
付费会员更注重生活品质

3 、留住付费会员，提高续费率

公开资料显示，2016财年Costco北美会员续费率90%。高续费率与会员满意度是挂钩的，而costco除了拥有一套完善的会员服务制度外，其核心竞争力——低价也是用户愿意跟随的主要原因。反观线上，京东的续费率在2017年也达到74%，如果算上不到两年的历史，这在一定程度上能够说明京东“PLUS会员”的成功。或者说，一大半的会员认为付费是值得的，他们愿意继续享受这样的服务与优惠。简而言之，由于会员付费一般是以年为单位，会员在做续费决定前必然要衡量上个会员周期内在优惠与服务上的获得与满意度。所以，这就对零售商持续提供优质服务的能力提出了考验，要想留住用户，就需要保持稳定不变甚至持续提高的服务能力与优惠力度。

附件： 2017年中国零售业付费会员消费洞察，提取码：5a4d

The post 付费制会员体系初探 appeared first on 标点符.

IT瘾网络推荐

GDC：2026年游戏业界52%人士认为AI产生负面影响

更多阅读：

数据中心网络高可用技术之从交换机到交换机：MLAG, 堆叠技术

MLAG 技术

堆叠技术

数据中心网络高可用技术系列

聊聊 nostr 和 审查

通讯过程

技术细节摘要

如何对抗网络审查

如何对抗Spam和骗子

怎么理解审查

相关文章

面向推荐的汽车知识图谱构建

一、背景

1、引言

2、发展现状

3、目标及收益

二、图谱构建

1、构建的挑战

2、图谱架构设计

3、具体构建步骤及流程

3.2 知识获取

3.2.1 结构化知识转模

3.2.2 非结构化知识抽取-三元组抽取

3.2.3 挖掘概念，兴趣词标签，关联到车系、实体

3.2.4人效提升：

3.3 知识入库

3.4 图谱查询服务

三、知识图谱在推荐的应用

3.1 知识图谱在推荐冷启动的应用

3.2 知识图谱在推荐理由生成的应用

3.3 知识图谱在推荐排序的应用

四、总结

互联网上的人群为何越来越极端化？

Fiddler 抓包 Android

引言

准备

Fiddler 基本配置

Fiddler 配置 HTTPS

Android 模拟器 配置

配置 Android 模拟器的网络代理

配置 Fiddler 抓包 模拟器 的 HTTPS

部分 APP 不走 系统代理

现象

APP 不走系统代理 原因/实现

解决

Q&A

补充

Fiddler 默认端口

Fiddler 导出 HTTPS 证书

代理抓包原理

原理

部分应用不能抓包的原因

解决方案

参考

基于 Ubuntu 20.04 部署 1.23版K8S 集群

1. 环境说明

2. 集群架构

3. 网络环境

4. 基础环境

4.1 关闭 swapoff

4.2 修改时区

4.3 设置内核参数

5. 基础软件

5.1 安装 Docker

5.2 安装 kubeadm kubectl

6. 构建集群

6.1 部署 master

6.2 部署 worker

6.3 部署 Calico

7. 验收集群

8. 写在最后

网络数字身份认证术

用户密码

密钥对和证书

证书生成过程演示

双向认证 mTLS

相关文章

聊聊 nostr 和审查

Android 模拟器配置

配置 Fiddler 抓包模拟器的 HTTPS

部分 APP 不走系统代理

APP 不走系统代理原因/实现