Linkedin-SRE-中文教程-三-
Linkedin SRE 中文教程(三)
总结
原文:https://linkedin.github.io/school-of-sre/level101/databases_sql/conclusion/
我们已经讲述了 SQL 数据库的基本概念。我们还介绍了 SRE 可能负责的一些任务——还有很多要学和要做的。我们希望本课程给你一个良好的开端,并激励你进一步探索。
进一步阅读
NoSQL
NoSQL 概念
原文:https://linkedin.github.io/school-of-sre/level101/databases_nosql/intro/
先决条件
从本课程中可以期待什么
在培训结束时,您将了解什么是 NoSQL 数据库,它相对于传统 RDBMS 有什么样的优点或缺点,了解不同类型的 NoSQL 数据库,并理解一些基本概念和 w.r.t .到 NoSQL 的权衡。
本课程不包括哪些内容
我们不会深入研究任何特定的 NoSQL 数据库。
课程内容
介绍
当人们使用术语“NoSQL 数据库”时,他们通常用它来指代任何非关系数据库。有人说术语“NoSQL”代表“非 SQL”,有人说它代表“不仅仅是 SQL”不管怎样,大多数人认为 NoSQL 数据库是以关系表以外的格式存储数据的数据库。
一个常见的误解是 NoSQL 数据库或非关系数据库不能很好地存储关系数据。NoSQL 数据库可以存储关系数据,只是存储方式与关系数据库不同。事实上,与 SQL 数据库相比,许多人发现在 NoSQL 数据库中建模关系数据更容易,因为相关数据不必在表之间拆分。
这种数据库自 20 世纪 60 年代末就已经存在,但“NoSQL”这个名字只是在 21 世纪初才被创造出来。美国宇航局使用 NoSQL 数据库跟踪阿波罗任务的库存。随着存储成本的大幅下降,NoSQL 数据库出现在 2000 年代末。仅仅为了减少数据重复而创建复杂、难以管理的数据模型的时代已经一去不复返了。开发人员(而不是存储)正在成为软件开发的主要成本,因此 NoSQL 数据库针对开发人员的工作效率进行了优化。随着敏捷开发方法的兴起,NoSQL 数据库的开发侧重于可伸缩性、快速性能,同时允许频繁的应用更改,并使编程更容易。
NoSQL 数据库的类型:
随着时间的推移,由于这些 NoSQL 数据库是为适应不同公司的需求而开发的,我们最终拥有了相当多类型的数据库。然而,它们可以大致分为 4 种类型。不同类型的数据库之间可能会有一些重叠。他们是
- 文档数据库:它们在文档中存储数据,类似于 JSON (JavaScript 对象符号)对象。每个文档都包含成对的字段和值。值通常可以是各种类型,包括字符串、数字、布尔值、数组或对象,它们的结构通常与开发人员在代码中处理的对象一致。优点包括直观的数据模型&灵活的模式。由于其多种多样的字段值类型和强大的查询语言,文档数据库非常适合各种各样的用例,并且可以用作通用数据库。它们可以横向扩展以容纳大量数据。例如:MongoDB、Couchbase
- 键值数据库:这是一种比较简单的数据库,其中的每一项都包含键值。值通常只能通过引用其键来检索,因此学习如何查询特定的键-值对通常很简单。键值数据库非常适合需要存储大量数据但不需要执行复杂的查询来检索数据的用例。常见的用例包括存储用户偏好或缓存。Ex: 雷迪斯, DynamoDB ,伏地魔 / 威尼斯 (Linkedin)
- 宽列存储:它们在表、行和动态列中存储数据。与关系数据库相比,宽列存储提供了很大的灵活性,因为不要求每行都有相同的列。许多人认为宽列存储是二维键值数据库。当您需要存储大量数据并且可以预测您的查询模式时,宽列存储非常有用。宽列存储通常用于存储物联网数据和用户档案数据。 Cassandra 和 HBase 是两家最受欢迎的宽栏商店。
- 图数据库:这些数据库在节点和边中存储数据。节点通常存储关于人、地点和事物的信息,而边存储关于节点之间关系的信息。图形数据库的底层存储机制可以变化。一些依赖于关系引擎并将图形数据“存储”在表中(尽管表是逻辑元素,因此这种方法在图形数据库、图形数据库管理系统和实际存储数据的物理设备之间强加了另一个抽象级别)。还有一些使用键值存储或面向文档的数据库进行存储,这使它们具有固有的 NoSQL 结构。图形数据库在需要遍历关系以寻找模式的用例中表现出色,例如社交网络、欺诈检测和推荐引擎。Ex: Neo4j
比较
| | 表演 | 可测量性 | 灵活性 | 复杂性 | 功能 |
| 关键字值 | 高的 | 高的 | 高的 | 没有人 | 可变的 |
| 文档存储 | 高的 | 可变(高) | 高的 | 低的 | 可变(低) |
| 列数据库 | 高的 | 高的 | 温和的 | 低的 | 最小的 |
| 图表 | 可变的 | 可变的 | 高的 | 高的 | 图论 |
SQL 和 NoSQL 的区别
下表总结了 SQL 和 NoSQL 数据库之间的主要差异。
| | SQL 数据库 | NoSQL 数据库 |
| 数据存储模型 | 具有固定行和列的表格 | Document: JSON documents,Key-value: key-value 对,Wide-column:包含行和动态列的表,Graph:节点和边 |
| 主要目的 | 通用 | 文档:通用,键值:具有简单查找查询的大量数据,宽列:具有可预测查询模式的大量数据,图形:分析和遍历连接数据之间的关系 |
| 计划 | 严格的 | 灵活的 |
| 扩缩容 | 垂直(纵向扩展到更大的服务器) | 水平(跨商用服务器横向扩展) |
| 多记录酸交易 | 支持 | 大多数不支持多记录 ACID 事务。然而,有些——比如 MongoDB——会。 |
| 连接 | 通常需要 | 通常不需要 |
| 数据到对象的映射 | 需要 ORM(对象关系映射) | 许多不需要 ORM。在大多数流行的编程语言中,文档 DB 文档直接映射到数据结构。 |
优势
-
灵活的数据模型
大多数 NoSQL 系统都具有灵活的模式。灵活的模式意味着您可以轻松地修改数据库模式来添加或删除字段,以支持不断发展的应用需求。这有助于在没有数据库操作开销的情况下不断开发新功能的应用。
-
水平缩放
大多数 NoSQL 系统允许您进行水平扩展,这意味着您可以在任何想要扩展系统的时候添加更便宜的商品硬件。另一方面,SQL 系统通常是垂直扩展的(更强大的服务器)。与传统的 SQL 系统相比,NoSQL 系统还可以托管巨大的数据集。
-
快速查询
由于数据非规范化和水平扩展,NoSQL 通常比传统的 SQL 系统快得多。大多数 NoSQL 系统也倾向于将相似的数据存储在一起,以促进更快的查询响应。
-
开发人员生产力
NoSQL 系统倾向于基于编程数据结构来映射数据。因此,开发人员需要执行更少的数据转换,从而提高生产率和减少错误。
关键概念
原文:https://linkedin.github.io/school-of-sre/level101/databases_nosql/key_concepts/
当我们谈论 NoSQL 或分布式系统时,让我们看看一些关键概念
CAP 定理
在 2000 年 ACM 的 PODC 研讨会上,Eric Brewer 提出了所谓的 CAP-theorem(CAP-theorem ),这是一个被大型网络公司和 NoSQL 社区广泛采用的主题。CAP 首字母缩写代表 C 一致性, A 可用性&T6】P 分割公差。
-
一致性
它指的是系统在执行后的一致性。当一个源所做的写操作对该共享数据的所有读者都可用时,分布式系统被称为一致的。不同的 NoSQL 系统支持不同级别的一致性。
-
可用性
它是指系统如何应对由于硬件和软件故障导致的不同系统的功能丧失。高可用性意味着当系统的某个部分由于故障或升级而停机时,系统仍然可以处理操作(读取和写入)。
-
分区公差
它是系统在网络分区的情况下继续运行的能力。当一个故障导致两个或多个网络孤岛,系统暂时或永久无法通过孤岛相互通信时,就会发生网络分区。
布鲁尔声称,在共享数据系统中,人们最多只能选择这三个特征中的两个。CAP 定理指出,出于一致性、可用性和分区容差,只能对两个选项进行选择。大规模应用中越来越多的用例倾向于重视可靠性,这意味着可用性和冗余比一致性更有价值。因此,这些系统很难满足酸性。他们通过放松一致性要求(即最终一致性)来实现这一点。
最终一致性意味着随着时间的推移,所有的读者都将看到写入:“在稳定状态下,系统最终将返回最后写入的值”。因此,在更新过程中,客户端可能会面临数据不一致的状态。例如,在复制的数据库中,更新可以进行到一个节点,该节点将最新版本复制到包含修改的数据集的副本的所有其他节点,使得副本节点最终将具有最新版本。
NoSQL 系统支持不同级别的最终一致性模型。例如:
-
读自己写的一致性
客户端将在更新完成后立即看到它们。读取操作可能会命中除写入节点之外的节点。但是,他们可能不会立即看到其他客户端的更新。
-
会话一致性
客户端将在会话范围内看到对其数据的更新。这通常表示读取和写入发生在同一个服务器上。使用相同节点的其他客户端将收到相同的更新。
-
偶然的一致性
如果以下条件成立,则系统提供因果一致性:由潜在因果关系相关的写操作被系统的每个进程按顺序看到。不同的进程可能以不同的顺序观察并发写入
如果对相同数据分区的并发更新不太可能,并且如果客户端不立即依赖于读取由它们自己或由其他客户端发出的更新,则最终一致性是有用的。
根据为系统(或部分系统)选择的一致性模型,确定请求的路由位置,例如复制副本。
瓶盖替代品图解
| 选择 | 特征 | 例子 |
| Consistency + Availability(放弃分区) | 2-phase commits 缓存失效协议 | Single-site databases Cluster databases 轻量级目录访问协议 xFS 文件系统 |
| Consistency + Partition tolerance(丧失可用性) | Pessimistic locking 使少数分区不可用 | 分布式数据库分布式锁定多数协议 |
| 可用性+分区容差(丧失一致性) | expirations/leases 冲突解决乐观 | DNSWeb 缓存 |
分布式系统中数据的版本控制
当数据分布在不同的节点上时,可以同时在不同的节点上对其进行修改(假设实施了严格的一致性)。并发更新的冲突解决出现了问题。一些流行的冲突解决机制有
-
时间戳
这是最明显的解决方案。您根据时间顺序对更新进行排序,并选择最新的更新。然而,这依赖于基础设施不同部分之间的时钟同步。当系统的各个部分分布在不同的地理位置时,这变得更加复杂。
-
乐观锁定
您将一个唯一的值(如时钟或计数器)与每次数据更新相关联。当客户机想要更新数据时,它必须指定需要更新哪个版本的数据。这意味着您需要跟踪数据版本的历史。
-
矢量时钟
向量时钟被定义为来自每个节点的时钟值的元组。在分布式环境中,每个节点维护这样的时钟值的元组,该元组表示节点本身及其对等体/副本的状态。时钟值可以是从本地时钟或版本号导出的真实时间戳
矢量时钟插图
与其他冲突解决机制相比,矢量时钟具有以下优势
- 不依赖同步时钟
- 临时推理不需要修订号的总排序
不需要在不同的节点上存储和维护数据的多个版本。
分割
当数据量超过单个节点的容量时,我们需要考虑拆分数据,为负载平衡和灾难恢复创建副本。根据基础设施的动态性,我们有几种方法可以采用。
-
内存缓存
这些是分区的内存数据库,主要用于临时数据。这些数据库通常被用作传统 RDBMS 的前台。最常用的数据从 rdbms 复制到内存数据库中,以便于快速查询,并减轻后端数据库的负担。一个非常常见的例子是 memcached 或 couchbase。
-
聚类
传统的集群机制从客户端抽象出集群拓扑。客户端不需要知道实际数据驻留在哪里,也不需要知道它正在与哪个节点通信。集群在传统的 RDBMS 中非常常用,它可以在一定程度上帮助扩展持久层。
-
将读写分离
在这种方法中,您将拥有托管相同数据的多个副本。传入的写入通常发送到单个节点(主节点)或多个节点(多主节点),而其余的副本(从节点)处理读取请求。领导者将写入异步复制到所有追随者。然而,写入延迟无法完全避免。有时领导者会在将所有数据复制给追随者之前崩溃。当这种情况发生时,一个拥有最一致数据的追随者可以转变为领导者。正如您现在所意识到的,在这个模型中很难实现完全的一致性。您还需要考虑读写流量的比率。当写操作高于读操作时,这种模式没有意义。复制方法也可能千差万别。一些系统定期进行完整的状态转移,而其他系统使用增量状态转移方法。您也可以通过按顺序转移操作来转移状态。然后,跟随者可以应用与领导者相同的操作来赶上。
-
分片
共享是指以这样一种方式划分数据,即数据均匀地分布在一个节点群集中(就存储和处理能力而言)。它还可能意味着数据局部性,这意味着相似和相关的数据存储在一起,以促进更快的访问。反过来,可以进一步复制一个碎片来满足负载平衡或灾难恢复需求。单个碎片复制副本可以接收所有写入(单个领导者),或者多个复制副本可以接收写入(多个领导者)。读取可以分布在多个副本上。由于数据现在分布在多个节点上,客户端应该能够始终如一地找出数据托管的位置。我们将在下面看看一些常见的技术。分片的缺点是分片之间的连接是不可能的。因此,上游/下游应用必须聚合来自多个碎片的结果。
分片示例
散列法
哈希函数是将一段数据(通常描述某种对象,通常为任意大小)映射到另一段数据(通常为整数,称为哈希代码,或简称为哈希的函数。在分区数据库中,将一个键一致地映射到一个服务器/副本是很重要的。
例如:你可以使用一个非常简单的散列作为取模函数。
_p = k mod n_
在哪里
p -> partition,
k -> primary key
n -> no of nodes
这个简单散列的缺点是,每当集群拓扑发生变化时,数据分布也会发生变化。当您处理内存缓存时,将分区分布在各处会很容易。每当一个节点加入/离开拓扑时,分区可以重新排序,缓存未命中可以从后端数据库重新填充。然而,当您查看持久数据时,这是不可能的,因为新节点没有为其提供服务所需的数据。这给我们带来了一致散列。
一致散列法
一致散列是一种分布式散列方案,通过在抽象圆或散列环上给它们分配一个位置,独立于分布式散列表中的服务器或对象的数量进行操作。这允许服务器和对象在不影响整个系统的情况下进行扩展。
假设我们的散列函数 h()生成一个 32 位整数。然后,为了确定我们将向哪个服务器发送密钥 k,我们找到其散列 h(s)是大于 h(k)的最小整数的服务器 s。为了简化这个过程,我们假设这个表是循环的,这意味着如果我们找不到一个散列值大于 h(k)的服务器,我们就绕回并从数组的开头开始查找。
一致散列图
在一致散列中,当服务器被移除或添加时,只有来自该服务器的密钥被重定位。例如,如果服务器 S3 被移除,则来自服务器 S3 的所有密钥将被移动到服务器 S4,但是存储在服务器 S4 和 S2 上的密钥不会被重新定位。但是有一个问题,当服务器 S3 被移除时,来自 S3 的密钥不能在剩余的服务器 S4 和 S2 之间平均分配。它们仅被分配给服务器 S4,这增加了服务器 S4 的负载。
为了在添加或删除服务器时在服务器之间平均分配负载,它会为每个服务器创建固定数量的副本(称为虚拟节点),并沿圆圈分布。因此,代替服务器标签 S1、S2 和 S3,我们将有 S10 S11…S19、S20 S21…S29 和 S30 S31…S39。根据具体情况,多个副本的系数也称为重量。
映射到复制品 Sij 的所有密钥都存储在服务器 Si 上。要找到一个密钥,我们做同样的事情,找到圆上的密钥的位置,然后向前移动,直到找到一个服务器副本。如果服务器复制品是 Sij,则密钥存储在服务器 Si 中。
假设服务器 S3 被移除,那么所有带有标签 S30 S31 … S39 的 S3 复制品必须被移除。现在,邻近 S3X 标签的对象关键点将自动重新分配给 S1X、S2X 和 S4X。最初分配给 S1、S2 和 S4 的所有密钥都不会被移动。
如果我们添加一个服务器,类似的事情也会发生。假设我们想要添加服务器 S5 作为 S3 的替代,那么我们需要添加标签 S50 S51 … S59。在理想情况下,来自 S1、S2 和 S4 的四分之一的密钥将被重新分配给 S5。
当应用于持久存储时,进一步的问题出现了:如果一个节点已经离开场景,存储在这个节点上的数据变得不可用,除非它之前已经被复制到其他节点;在新节点加入其他节点的相反情况下,相邻节点不再负责它们仍然存储但不再被请求的一些数据,因为相应的对象不再被请求客户端散列到它们。为了解决这个问题,可以引入复制因子(r)。
在分区方案中引入副本,除了可靠性优势之外,还可以将读取请求的工作负载分散到负责所请求数据的任何物理节点。如果客户端必须在数据集的多个版本之间做出决定,则可伸缩性不起作用,因为它们需要从服务器的仲裁中读取,这反过来降低了负载平衡的效率。
法定人数
Quorum 是群集中必须联机并且能够相互通信的最小节点数。如果超过此阈值出现任何额外的节点故障,群集将停止运行。
要获得法定人数,您需要大多数节点。通常是(N/2 + 1),其中 N 是系统中节点的总数。对于 ex 来说,
在 3 节点集群中,大多数情况下需要 2 个节点,
在 5 节点集群中,大多数情况下需要 3 个节点,
在 6 节点群集中,大多数情况下需要 4 个节点。
法定人数示例
网络问题会导致群集节点之间的通信失败。一组节点可能能够在网络的功能部分一起通信,但是不能与网络的另一部分中的不同组节点通信。这就是众所周知的在集群或集群分割中的裂脑。
现在,具有仲裁的分区被允许继续运行应用。其他分区将从集群中删除。
例如:在一个 5 节点集群中,考虑如果节点 1、2 和 3 可以相互通信,但不能与节点 4 和 5 通信,会发生什么情况。节点 1、2 和 3 构成了大多数,它们继续作为一个集群运行。作为少数,节点 4 和 5 停止作为集群运行。如果节点 3 失去与其他节点的通信,所有节点将停止作为群集运行。但是,所有运行的节点将继续侦听通信,以便当网络重新开始工作时,群集可以形成并开始运行。
下图演示了在分为两个集的集群上选择仲裁。
集群定额示例
总结
原文:https://linkedin.github.io/school-of-sre/level101/databases_nosql/further_reading/
我们已经讲述了 NoSQL 数据库的基本概念。要学的和要做的还有很多。我们希望本课程给你一个良好的开端,并激励你进一步探索。
进一步阅读
NoSQL:
hostingdata.co.uk/nosql-database/
www.mongodb.com/nosql-explained
www.mongodb.com/nosql-explained/nosql-vs-sql
Cap 定理
www.julianbrowne.com/article/brewers-cap-theorem
可测量性
www . slide share . net/JB oner/scalability-avail ability-stability-patterns
最终一致性
www . all things distributed . com/2008/12/finally _ consistent . html
www.toptal.com/big-data/consistent-hashing
web . Stanford . edu/class/cs 244/papers/chord _ TON _ 2003 . pdf
大数据
大数据
原文:https://linkedin.github.io/school-of-sre/level101/big_data/intro/
先决条件
- Linux 文件系统基础。
- 对系统设计有基本的了解。
从本课程中可以期待什么
本课程涵盖大数据的基础知识,以及它是如何演变成今天的样子的。我们将看看大数据非常适合的几个现实场景。设计大数据系统的一个有趣任务是理解 Hadoop 的架构和围绕它的工具。
本课程不包括哪些内容
编写程序从数据中提取分析。
课程内容
- 大数据概述
- 大数据技术的使用
- Hadoop 的演变
- Hadoop 的架构
- HDFS
- 故事
- MapReduce 框架
- 围绕 hadoop 的其他工具
- 储备
- 猪
- 火花
- 很快
- 数据序列化和存储
大数据概述
- 大数据是无法使用传统计算技术处理的大型数据集的集合。它不是单一的技术或工具,而是已经成为一门完整的学科,涉及各种工具、技术和框架。
- 大数据可能包括
- 结构数据
- 非结构化数据
- 半结构化数据
- 大数据的特征:
- 卷
- 多样化
- 速度
- 变化性
- 大数据生成的例子包括证券交易所、社交媒体网站、喷气发动机等。
大数据技术的使用
- 以交通灯问题为例。
- 截至 2018 年,美国有超过 30 万个交通灯。
- 让我们假设我们在每台机器上放置了一个设备来收集指标,并将其发送到一个中央指标收集系统。
- 如果每个物联网设备每分钟发送 10 个事件,我们每天有 300000 个 0x10x60x24 = 432x10⁷ 事件。
- 你将如何处理这些信息,并告诉我在某一天的上午 10:45 有多少个信号是“绿色”的?
- 考虑统一支付接口(UPI)交易的下一个示例:
- 2019 年 10 月,我们在印度的 UPI 交易量约为 11.5 亿笔。
- 如果我们试着将这个数据推断到一年左右,并试着找出通过某个特定的 UPI ID 发生的一些常见支付,你建议我们怎么做?
Hadoop 的发展
原文:https://linkedin.github.io/school-of-sre/level101/big_data/evolution/
Hadoop 的架构
-
HDFS
- Hadoop 分布式文件系统(HDFS)是一个分布式文件系统,旨在运行在商用硬件上。它与现有的分布式文件系统有许多相似之处。然而,与其他分布式文件系统的区别是显著的。
- HDFS 具有高度容错能力,旨在部署在低成本硬件上。HDFS 提供对应用数据的高吞吐量访问,适用于具有大型数据集的应用。
- HDFS 是 Apache Hadoop 核心项目 T1 的一部分。
HDFS 的主要成分包括:1 .NameNode:是集群中文件命名空间的仲裁器和中央存储库。NameNode 执行打开、关闭和重命名文件和目录等操作。2.DataNode:管理连接到运行它的节点的存储。它负责处理所有的读写请求。它对 NameNode 上的指令执行操作,例如创建、删除和复制块。3.客户端:负责从 namenode 获取所需的元数据,然后与 datanodes 通信以进行读取和写入。
-
YARN 代表“又一个资源谈判者”。它是在 Hadoop 2.0 中引入的,以消除 Hadoop 1.0 中存在的作业跟踪器的瓶颈。YARN 在推出时被描述为“重新设计的资源管理器”,但现在它已经发展成为一个用于大数据处理的大规模分布式操作系统。
纱线结构的主要组成部分包括:1 .客户机:它向资源管理器提交 map-reduce(MR)作业。2.资源管理器:它是 YARN 的主守护进程,负责所有应用之间的资源分配和管理。每当它接收到一个处理请求时,它就将其转发给相应的节点管理器,并相应地分配资源以完成该请求。它有两个主要组成部分:1 .调度程序:它根据分配的应用和可用资源执行调度。它是一个纯粹的调度程序,这意味着它不执行其他任务,如监视或跟踪,也不保证在任务失败时重新启动。YARN scheduler 支持容量调度器和公平调度器等插件来划分集群资源。2.应用管理器:它负责接受应用并协商来自资源管理器的第一个容器。如果任务失败,它还会重新启动应用管理器容器。3.节点管理器:它负责 Hadoop 集群上的各个节点,并管理应用和工作流以及特定的节点。它的主要工作是跟上节点管理器。它监视资源使用情况,执行日志管理,并根据资源管理器的指示终止容器。它还负责创建容器进程,并在应用主机的请求下启动它。4.应用主程序:应用是提交给框架的单个作业。应用管理器负责与资源管理器协商资源,跟踪状态,并监视单个应用的进度。应用主机通过发送容器启动上下文(CLC)向节点管理器请求容器,该上下文包括应用运行所需的一切。一旦应用启动,它会不时地向资源管理器发送健康报告。5.容器:它是一个物理资源的集合,例如单个节点上的 RAM、CPU 内核和磁盘。容器由容器启动上下文(CLC)调用,CLC 是包含诸如环境变量、安全令牌、依赖性等信息的记录。
MapReduce 框架
- 术语 MapReduce 代表 Hadoop 程序执行的两个独立且不同的任务——映射作业和简化作业。地图作业将数据集作为输入,并对其进行处理以生成键值对。Reduce job 获取地图作业的输出,即键值对,并聚合它们以生成所需的结果。
- Hadoop MapReduce(Hadoop Map/Reduce)是一个在计算集群上分布式处理大型数据集的软件框架。Mapreduce 有助于将输入数据集分割成多个部分,同时并行运行所有数据部分的程序。
- 请查找以下字数示例,演示 MapReduce 框架的用法:
围绕 Hadoop 的其他工具
-
- 使用一种叫做 HQL 的语言,它非常像 SQL。让非程序员能够在 Hadoop 中查询和分析数据。基本上是 map-reduce 之上的一个抽象层。
- 《出埃及记》HQL 质问:
- SELECT pet.name,评论来自(pet.name = event.name)上的宠物加入活动;
- 在 mysql 中:
- SELECT pet.name,评论来自 pet,event 其中 pet . name = event . name;
-
- 使用一种称为 Pig Latin 的脚本语言,这种语言更受工作流驱动。不需要成为专业的 Java 程序员,但需要一些编码技能。也是 map-reduce 之上的一个抽象层。
- 这里有一个简单的问题:针对下图中左栏中的数据运行右栏中的 pig 查询的输出是什么?
输出:
7,Komal,Nayak,24,9848022334,trivendram 8,Bharathi,Nambiayar,24,9848022333,Chennai 5,Trupthi,Mohanthy,23,9848022336,Bhuwaneshwar 6,Archana,Mishra,23,9848022335,Chennai
-
- Spark 为内存集群计算提供了原语,允许用户程序将数据加载到集群的内存中并重复查询,使其非常适合机器学习算法。
-
- Presto 是一个针对大数据的高性能分布式 SQL 查询引擎。
- 其架构允许用户查询各种数据源,如 Hadoop、AWS S3、Alluxio、MySQL、Cassandra、Kafka 和 MongoDB。
- 示例快速查询:
use studentDB; show tables; SELECT roll_no, name FROM studentDB.studentDetails where section=’A’ limit 5;
数据序列化和存储
- 为了在网络上传输数据或存储在一些永久存储器上,我们使用将数据结构或对象状态转换成二进制或文本形式的过程。我们称这个过程为序列化..
- Avro 数据存储在容器文件(. avro 文件)中,其模式(。avsc 文件)与数据文件一起存储。
- Apache Hive 支持将表存储为 Avro,并且还可以查询这种序列化格式的数据。
任务和结论
原文:https://linkedin.github.io/school-of-sre/level101/big_data/tasks/
培训后任务:
参考资料:
系统设计
系统设计
原文:https://linkedin.github.io/school-of-sre/level101/systems_design/intro/
先决条件
常用软件系统组件的基础:
- Linux 基础知识
- Linux 联网
- 数据库 RDBMS
- NoSQL 概念
从本课程中可以期待什么
考虑和设计大型软件系统的可伸缩性、可用性和可靠性。
本课程不包括哪些内容
单个软件组件的可伸缩性和可靠性问题,例如数据库,虽然可以应用相同的可伸缩性原则和思想,但这些单个组件在伸缩它们和考虑它们的可靠性时有它们自己的特定细微差别。
我们将更多地关注概念,而不是设置和配置负载平衡器等组件来实现系统的可伸缩性、可用性和可靠性
课程内容
介绍
那么,你如何着手学习设计一个系统呢?
像大多数伟大的问题一样,这个问题表现出惊人的天真。我能给出的唯一简短的答案是,从本质上讲,你通过设计系统并找出什么可行,什么不可行,学会了如何设计一个系统。”Jim Waldo,Sun Microsystems,关于系统设计
由于软件和硬件系统有多个移动部分,我们需要考虑这些部分将如何增长,它们的故障模式,它们的相互依赖性,它将如何影响用户和业务。
学习或做系统设计没有一蹴而就的方法或途径,我们只有通过设计和迭代来学习设计系统。
本课程将是一个开端,使人们在系统设计过程中思考可伸缩性、可用性和容错性。
背景
让我们设计一个简单的内容共享应用,用户可以在我们的应用中共享他们的朋友喜欢的照片和媒体。让我们从应用的简单设计开始,并随着我们学习系统设计概念而发展它
可测量性
原文:https://linkedin.github.io/school-of-sre/level101/systems_design/scalability/
可伸缩性对一个系统/服务意味着什么?一个系统由服务/组件组成,每个服务/组件的可伸缩性需要单独处理,而系统的可伸缩性作为一个整体。
如果随着资源被添加到系统中,服务的性能以与添加的资源成比例的方式提高,则称该服务是可伸缩的
如果添加资源以促进冗余不会导致性能损失,则称永远在线服务是可伸缩的
参考
可扩展性- AKF 规模的立方体
Scale Cube 是一个用于细分服务、定义微服务和扩展产品的模型。它还为团队在设计解决方案时讨论与规模相关的选项创造了一种通用语言。下一节根据我们对 AKF 立方体的推断来讨论某些扩展模式
可扩展性-水平扩展
水平伸缩代表应用或服务的克隆,这样工作就可以毫无偏见地轻松分配到不同的实例中。
让我们看看我们的单片应用如何利用这一原则进行改进
这里,DB 与应用分开缩放。这是为了让您知道每个组件的扩展能力可能是不同的。通常,web 应用可以通过添加资源来扩展,除非应用中存储了状态。但是,通过添加更多的跟随者,数据库只能针对读取进行扩展,但写入必须只针对一个领导者,以确保数据的一致性。有一些数据库支持多领导写,但我们在这一点上把它们排除在范围之外。
应用应该能够区分读取和写入,以选择合适的数据库服务器。负载平衡器可以透明地在相同的服务器之间分割流量。
什么:复制服务或数据库以分散事务负载。
何时使用:读写比率非常高的数据库(5:1 或更高—越高越好)。因为只能缩放数据库的读取副本,而不能缩放主数据库。
使用方法:简单地克隆服务,实现一个负载均衡器。对于数据库,确保访问代码理解读和写之间的区别。
原因:允许以复制数据和功能为代价快速扩展交易。
关键要点:这实现起来很快,从开发人员的角度来看成本很低,并且可以很好地扩展交易量。但是,从数据运营成本的角度来看,它们往往成本较高。这里的成本意味着,如果我们有 3 个追随者和 1 个领导者数据库,相同的数据库将作为 4 个副本存储在 4 个服务器。因此增加了存储成本
参考
可伸缩性模式-负载平衡
改善多种计算资源(如计算机、计算机集群、网络链接、中央处理器或磁盘驱动器)之间的工作负载分配。一种常用的技术是在相同的服务器集群之间负载平衡流量。类似的原理被用于通过 ECMP ,磁盘驱动器通过 RAID 等来平衡网络链路上的流量
旨在优化资源使用,最大化吞吐量,最小化响应时间,并避免任何单个资源过载。使用具有负载平衡的多个组件而不是单个组件可以通过冗余提高可靠性和可用性。在我们更新的架构图中,我们有 4 台服务器来处理应用流量,而不是一台服务器
执行负载平衡的设备或系统称为负载平衡器,缩写为 LB。
参考
en . Wikipedia . org/wiki/Load _ balancing _(计算)
blog . envoy proxy . io/introduction-to-modern-network-load-balancing-and-proxy-a57f 6 ff 80236
learning . oreilly . com/library/view/load-balancing-in/9781492038009/
learning . oreilly . com/library/view/practical-load-balancing/9781430236801/
shop.oreilly.com/product/9780596000509.do
可伸缩性模式- LB 任务
LB 是做什么的?
服务发现:
系统中有哪些后端可用?在我们的架构中,有 4 台服务器可用于服务应用流量。LB 充当单个端点,客户端可以透明地使用它来访问 4 个服务器中的一个。
健康检查:
哪些后端目前是健康的,可以接受请求?如果 4 个应用服务器中有一个坏了,LB 会自动缩短路径,这样客户端就不会感觉到任何应用宕机
负载平衡:
应该使用什么算法来平衡健康后端的各个请求?有许多算法可以在四台服务器之间分配流量。基于观察/经验,SRE 可以选择适合他们模式的算法
可伸缩性模式- LB 方法
常见的负载平衡方法
最少联系方法
将流量定向到活动连接最少的服务器。当在服务器之间不均匀分布的流量中有大量持久连接时最有用。如果客户端保持长期连接,则有效
最短响应时间法
将流量定向到具有最少活动连接和最低平均响应时间的服务器。这里,响应时间用于提供服务器健康状况的反馈
循环法
通过将流量定向到第一个可用的服务器来轮换服务器,然后将该服务器移动到队列的底部。当服务器规格相同并且没有很多持久连接时最有用。
IP 哈希
客户端的 IP 地址决定了哪个服务器接收请求。这有时会导致分布偏斜,但如果应用在本地存储一些状态并需要一些粘性,这是有用的
更高级的客户端/服务器端示例技术-https://docs.nginx.com/nginx/admin-guide/load-balancer/-http://cbonte.github.io/haproxy-dconv/2.2/intro.html#3.3.5-https://Twitter . github . io/finagle/guide/clients . html #负载平衡
可扩展性模式-缓存-内容交付网络(CDN)
cdn 被添加到离客户位置更近的地方。如果应用有静态数据,如图像、Javascript、CSS,它们不会经常改变,它们可以被缓存。由于我们的例子是一个内容共享网站,静态内容可以缓存在 cdn 中,并有一个合适的有效期。
什么:使用 cdn(内容交付网络)来减少你网站的流量。
何时使用:当速度提高和规模保证额外成本时。
如何使用:大多数 cdn 利用 DNs 为您的网站提供内容。因此,您可能需要对 DNS 进行微小的更改或添加,并将内容从新的子域名转移到其他域名。
media-exp1.licdn.com 是 Linkedin 用来提供静态内容的一个域名
这里,CNAME 将域指向 CDN 提供商的 DNS
挖 media-exp1.licdn.com+做空
2-01-2c3e-005c.cdx .雪松. net。
原因:cdn 有助于减轻流量高峰,通常是扩展网站部分流量的经济方式。它们通常还会大大缩短页面下载时间。
要点:cdn 是一种快速、简单的方法,可以抵消流量峰值和总体流量增长。确保执行成本效益分析并监控 CDN 的使用情况。如果 CDN 有很多缓存未命中,那么我们不会从 CDN 中获得太多,并且仍然使用我们的计算资源来服务请求。
可扩展性-微服务
这种模式代表了应用中服务或功能的工作分离。微服务旨在解决与代码库和数据集中的增长和复杂性相关的问题。目的是创建故障隔离并减少响应时间。
微服务可以扩展事务、数据大小和代码库大小。它们在扩展代码库的规模和复杂性方面最为有效。因为工程团队需要重写服务,或者至少需要将服务从最初的单一应用中分离出来,所以它们的成本往往比水平扩展要高一些。
WHAT: 该规则有时被称为通过服务或资源进行扩展,它侧重于通过沿着动词(服务)或名词(资源)的边界划分数据集、事务和工程团队来进行扩展。
何时使用:不需要数据间关系的超大型数据集。大型复杂系统,其中扩展工程资源需要专业化。
如何使用:用动词拆分动作,用名词拆分资源,或者混合使用。按照动词/名词方法定义的路线来划分服务和数据。
原因:不仅允许高效扩展事务,还允许扩展与这些事务相关的超大型数据集。它还允许团队的有效扩展。
要点:微服务支持高效扩展事务、大型数据集,并有助于故障隔离。它有助于减少团队的通信开销。代码库变得不那么复杂,因为不相交的功能被解耦并作为新的服务旋转,从而让每个服务根据其需求独立扩展。
参考
可伸缩性-分片
该模式表示基于在事务时查找或确定的属性的工作分离。最常见的是,这些被实现为由请求者、顾客或客户进行的分割。
通常,需要为这些类型的拆分编写查找服务或确定性算法。
分片有助于扩展事务增长、扩展指令集和减少处理时间(最后一点是通过限制执行任何事务所需的数据)。这对于扩大顾客或客户的增长更有效。它可以帮助灾难恢复工作,并将事件的影响限制在特定的客户群。
在这里,auth 数据基于用户名进行分片,这样数据库可以更快地响应,因为数据库在查询期间必须处理的数据量已经大大减少。
还可以有其他的分割方式
在这里,整个数据中心被分割和复制,客户端根据其地理位置被定向到数据中心。这有助于提高性能,因为客户端被定向到最近的数据中心,并且随着我们添加更多的数据中心,性能也会提高。这种方法需要注意一些复制和一致性开销。这还通过将测试特性推广到一个站点并在对该地理区域有影响时回滚来提供容错
WHAT: 这通常是根据客户的某些独特方面进行的划分,如客户 ID、姓名、地理位置等。
何时使用:非常大、相似的数据集,例如大型且快速增长的客户群,或者当地理上分散的客户群的响应时间很重要时。
使用方法:识别您所知道的关于客户的一些信息,例如客户 ID、姓氏、地理位置或设备,并根据该属性拆分或划分数据和服务。
原因:客户的快速增长超过了其他形式的数据增长,或者您需要在扩展时在某些客户群之间执行故障隔离。
关键要点:碎片可以有效地帮助您扩展客户群,但也可以应用于无法使用微服务方法分离的其他超大型数据集。
参考
SRE 角色中的应用
- SREs 与网络团队合作,研究如何将用户流量映射到特定站点。https://engineering.linkedin.com/blog/2017/05/trafficshift 负荷测试规模
- SREs 与开发团队紧密合作,将 monoliths 拆分为多个易于运行和管理的微服务
- SREs 致力于提高负载平衡器的可靠性、服务发现和性能
- sre 紧密合作,将数据分割成碎片,并管理数据的完整性和一致性。https://engineering . LinkedIn . com/espresso/introducing-espresso-linkedins-hot-new-distributed-document-store
- sre 负责设置、配置和提高 CDN 缓存命中率。
高可用性—可用性—常见的“9”
原文:https://linkedin.github.io/school-of-sre/level101/systems_design/availability/
可用性通常用“9”来表示,常见的“9”列举如下。
可用性% | 每年停机时间 | 每月停机时间 | 每周停机时间 | 每天停机时间 |
---|---|---|---|---|
99%(两个 9) | 3.65 天 | 7.31 小时 | 1.68 小时 | 14.40 分钟 |
99.5%(两个半九) | 1.83 天 | 3.65 小时 | 50.40 分钟 | 七点二十分钟 |
99.9%(三个九) | 8.77 小时 | 43.83 分钟 | 10.08 分钟 | 1.44 分钟 |
99.95%(三个半九) | 4.38 小时 | 21.92 分钟 | 5.04 分钟 | 43.20 秒 |
99.99%(四个九) | 52.60 分钟 | 4.38 分钟 | 1.01 分钟 | 8.64 秒 |
99.995%(四个半九) | 26.30 分钟 | 2.19 分钟 | 三十点二十四秒 | 4.32 秒 |
99.999%(五个九) | 5.26 分钟 | 26.30 秒 | 6.05 秒 | 864.0 毫秒 |
参考
高可用性系列组件
如果一个部件的故障导致组合变得不可操作,则带有部件的系统串联运行。
例如,如果我们架构中的 LB 失败,所有对应用层的访问都将失败。LB 和 app 层是串行连接的。
系统的综合可用性是单个部件可用性的乘积
A = Ax x Ay x …..
参考
高可用性并行组件
如果一个部件的故障导致另一个部件接管故障部件的操作,则具有部件的系统并行操作。
如果我们有一个以上的 LB,并且如果在一个 LB 出现故障时,其余的 LB 可以接管流量,那么 LB 是并行运行的
系统的综合可用性为
A = 1 - ( (1-Ax) x (1-Ax) x …..)
参考
HA -核心原则
消除单点故障(SPOF) 这意味着为系统增加冗余,这样一个组件的故障并不意味着整个系统的故障。
可靠的交叉在冗余系统中,交叉点本身往往会成为单点故障。可靠的系统必须提供可靠的交叉。
故障发生时的检测如果遵守上述两个原则,用户可能永远也看不到故障
参考
哈- SPOF
什么:从不实施,总是消除单点故障。
何时使用:在架构评审和新设计期间。
如何使用:在架构图上识别单个实例。争取主动/主动配置。至少我们应该有一个备用实例在活动实例失败时接管控制权。
为什么:通过多个实例实现可用性最大化。
要点:争取主动/主动解决方案,而不是主动/被动解决方案。使用负载平衡器来平衡服务实例之间的流量。对于需要单一实例的模式,使用带有主动/被动实例的控制服务。
高可用性可靠交叉
内容:确保系统组件故障转移时能够可靠地进行。
何时使用:在架构评审、故障建模和设计期间。
如何使用:确定交叉期间系统的可用性,并确保其在可接受的范围内。
为什么:最大化可用性并确保数据处理语义得到保留。
关键要点:争取主动/主动解决方案,而不是主动/被动解决方案,它们不可靠的风险更小。使用 LB 和正确的负载平衡方法来确保可靠的故障转移。建模并构建您的数据系统,以确保在交叉发生时数据得到正确处理。通常,数据库系统遵循主动/被动的写语义。主设备接受写入,当主设备停机时,从设备被提升为主设备(从被动变为主动)以接受写入。这里我们必须小心,切换永远不会引入一个以上的主设备。这个问题叫做裂脑。
SRE 角色中的应用
- SRE 致力于决定一个可接受的 SLA,并确保系统可用于实现 SLA
- SRE 从建立数据中心开始就参与架构设计,以确保该站点不受网络交换机、硬件、电源或软件故障的影响
- SRE 还进行故障模拟演习,以观察系统在未知领域的表现,并在出现失误时提出改善可用性的计划。https://engineering . LinkedIn . com/blog/2017/11/resilience-engineering-at-LinkedIn-with-project-water bear
贴出我们对 HA 的理解,我们的架构图如下所示
容错
原文:https://linkedin.github.io/school-of-sre/level101/systems_design/fault-tolerance/
在任何系统中,故障都是不可避免的,而且会一直发生,因此我们需要构建能够容忍故障或从故障中恢复的系统。
- 在系统中,失败是常态而不是例外。
- “任何可能出错的事情都会出错”——墨菲定律
- “复杂系统包含潜在的不断变化的故障组合”——复杂系统是如何失败的。
容错-故障度量
为任何系统测量和跟踪的常见故障指标。
平均修复时间(MTTR): 修复和恢复故障系统的平均时间。
平均故障间隔时间(MTBF): 一个设备故障或系统故障与下一个设备故障或系统故障之间的平均运行时间。
平均无故障时间(MTTF): 设备或系统在出现故障前预期运行的平均时间。
平均检测时间(MTTD): 从问题出现到组织检测到问题的平均时间。
平均调查时间(MTTI): 从发现事件到组织开始调查其原因和解决方案的平均时间。
恢复服务的平均时间(MTRS): 从检测到事件到受影响的系统或组件再次可供用户使用的平均时间。
系统事件平均间隔时间(MTBSI): 检测到两个连续事件之间的平均经过时间。MTBSI 可以通过将 MTBF 和 MTRS 相加来计算(MTBSI = MTBF + MTRS)。
故障率:另一个可靠性指标,衡量组件或系统发生故障的频率。它表示为单位时间内的失败次数。
参考
容错-故障隔离术语
系统应该有短路。比方说,在我们的内容共享系统中,如果“通知”不起作用,网站应该通过删除功能而不是关闭整个网站来优雅地处理这一故障。
泳道是常用的故障隔离方法之一。Swimlane 为该服务添加了一个来自其他服务的屏障,因此其中任何一个服务的故障都不会影响到另一个服务。假设我们在内容分享应用中推出了一项新功能“广告”。我们可以有两种架构
如果在每个新闻订阅源请求期间动态同步生成广告,则广告功能中的错误会传播到新闻订阅源功能。相反,如果我们将“广告生成”服务泳道化,并使用共享存储来填充 Newsfeed 应用,广告故障不会级联到 Newsfeed,最糟糕的情况是,如果广告不符合 SLA,我们可以拥有没有广告的 Newsfeed。
让我们再举一个例子,我们已经为我们的内容分享应用提出了一个新的模型。在这里,我们推出了一个企业内容共享应用,企业为服务付费,内容不应在企业外部共享。
泳道原则
原则 1: 什么都不分享(又称“尽量少分享”)。泳道内共享的越少,泳道的故障隔离性就越强。(如企业用例所示)
原则 2: 没有东西越过泳道边界。同步(通过预期请求而不是传输协议来定义)通信从不跨越泳道边界;如果有,则边界绘制不正确。(如广告特写所示)
泳道进场
方法 1: 泳道赚钱。永远不要让你的收银机受到其他系统的损害。(企业使用案例中的第 1 层与第 2 层)
方法二:泳道事件的最大来源。确定疼痛的重复原因并隔离它们。(如果广告功能处于黄色代码状态,游泳是最佳选择)
方法三:泳道天然屏障。顾客边界是很好的泳道。(公共与企业客户)
参考
SRE 角色中的应用
- 与 DC 技术或云团队合作,通过在数据中心内创建故障区域来分布基础架构,使其不受交换机或电源故障的影响 https://docs . Microsoft . com/en-us/azure/virtual-machines/manage-avail ability # use-avail ability-zones-to-protect-from-Data Center-level-failures
- 与合作伙伴一起工作,设计服务之间的交互,这样一个服务故障不会以级联方式扩大到所有上游
总结
原文:https://linkedin.github.io/school-of-sre/level101/systems_design/conclusion/
有了这些原则,我们希望这门课能给设计软件系统一个新的视角。在第一天就得到所有这些可能是过度工程化了。但是有些从一开始就非常重要,比如消除单点故障,通过增加副本来提供可扩展的服务。当达到一个瓶颈时,我们可以按服务分割代码,按比例分割数据。随着组织的成熟,引入混沌工程来测量系统如何应对失败将有助于设计健壮的软件系统。
度量和监控
先决条件
原文:https://linkedin.github.io/school-of-sre/level101/metrics_and_monitoring/introduction/
从本课程中可以期待什么
监控是任何系统不可或缺的一部分。作为一名 SRE,您需要对监控服务基础设施有一个基本的了解。本课程结束时,您将对以下主题有更好的理解:
-
什么是监控?
-
需要衡量什么
-
如何使用收集的指标来改进业务决策和整体可靠性
-
带警报的主动监控
-
日志处理及其重要性
-
-
什么是可观测性?
-
分布式跟踪
-
日志
-
韵律学
-
本课程没有涵盖哪些内容
-
监控基础设施设置指南
-
深入研究不同的监控技术以及任何工具的基准测试或比较
课程内容
介绍
监控是从系统中收集实时性能指标、分析数据以获得有意义的信息,并将数据显示给用户的过程。简单地说,您定期测量各种指标以了解系统的状态,包括但不限于用户请求、延迟和错误率。什么被测量,什么被固定 -如果你能测量什么,你就能推理它,理解它,讨论它,并自信地采取行动。
监控的四个黄金信号
为系统设置监控时,您需要决定测量什么。监控的四个黄金信号提供了对服务性能的良好理解,并为监控系统奠定了基础。这四个黄金信号是
-
交通
-
潜伏
-
错误
-
浸透
这些指标有助于您了解系统性能和瓶颈,并创建更好的最终用户体验。正如在谷歌 SRE 的书中所讨论的,如果你只能衡量你的服务的四个指标,那么专注于这四个。让我们来看看这四个黄金信号。
-
交通 - 交通更好地了解服务需求。通常被称为服务 QPS (每秒查询数),流量是服务所服务的请求的度量。该信号帮助您决定何时需要扩大服务规模以应对不断增长的客户需求,何时需要缩小规模以实现成本效益。
-
延迟 - 延迟是服务处理传入请求和发送响应所花费的时间。测量服务延迟有助于及早发现服务的缓慢下降。区分成功请求的延迟和失败请求的延迟非常重要。例如,由于失去与数据库或其他关键后端的连接而触发的 HTTP 5XX 错误可能会很快得到处理。但是,因为 HTTP 500 错误表示请求失败,所以将 500 秒计入总延迟可能会导致误导性的计算。
-
错误(速率) - 错误是对失败的客户端请求的度量。根据响应代码( HTTP 5XX 错误)可以很容易地识别这些故障。可能会出现由于错误的结果数据或违反策略而导致响应被视为错误的情况。例如,您可能得到一个 HTTP 200 响应,但是主体具有不完整的数据,或者响应时间超出了商定的 SLA s。因此,您需要有其他机制(代码逻辑或工具)来捕获响应代码之外的错误。
-
饱和度 - 饱和度是服务对资源利用率的度量。这个信号告诉您服务资源的状态以及它们有多满。这些资源包括内存、计算、网络 I/O 等。甚至在资源利用率达到 100%之前,服务性能就会缓慢下降。因此,有一个利用率目标是很重要的。等待时间的增加是饱和的良好指示;测量潜伏期的第 99 百分位数有助于饱和的早期检测。
根据服务的类型,您可以用不同的方式测量这些信号。例如,您可以测量 web 服务器每秒处理的查询数。相比之下,对于数据库服务器,通过执行的事务和创建的数据库会话,您可以了解数据库服务器处理的流量。借助额外的代码逻辑(监控库和仪器),您可以定期测量这些信号,并存储它们以供将来分析。尽管这些指标让您了解了服务端的性能,但是您还需要确保在客户端提供相同的用户体验。因此,您可能需要从服务基础设施之外监控服务,这将在第三方监控中讨论。
为什么监控很重要?
监控在服务的成功中起着关键的作用。如前所述,监控为理解服务健康状况提供了性能洞察。通过访问随时间收集的历史数据,您可以构建智能应用来满足特定需求。一些关键的使用案例如下:
-
缩短解决问题的时间 -有了良好的监控基础设施,您可以快速发现问题并解决它们,从而减少问题造成的影响。
-
业务决策 -在一段时间内收集的数据可以帮助您做出业务决策,例如确定产品发布周期、投资哪些功能以及关注哪些地理区域。基于长期数据的决策可以改善整体产品体验。
-
资源规划 -通过分析历史数据,您可以预测服务计算资源需求,并合理分配资源。这有助于做出经济高效的决策,而不会影响最终用户体验。
在深入探讨监控之前,让我们先了解一些基本术语。
-
指标——指标是对特定系统属性的定测量量——例如,内存或 CPU
-
节点或主机 -运行应用的物理服务器、虚拟机或容器
-
QPS - 每秒查询数,这是一个衡量服务每秒处理的流量的指标
-
延迟——用户操作和服务器响应之间的时间间隔——例如,从向数据库发送查询到收到第一个响应位所花费的时间
-
错误 速率 -在特定时间段(通常是一秒钟)内观察到的错误数量
-
图表 -在监控中,图表代表一段时间内收集的一个或多个指标值
-
仪表板 -仪表板是一组图表的集合,提供系统健康状况的概述
-
事件 -事件是指扰乱系统正常运行的事件
-
MTTD - 平均检测时间是服务故障开始和检测到该故障之间的时间间隔
-
MTTR -平均解决时间是修复服务故障并使服务恢复正常状态所花费的时间
在讨论监控应用之前,让我们先来看看监控基础设施。下图是一个基本的监控系统。
图 1:监控基础设施的图示
图 1 显示了一个监控基础设施机制,用于在系统上聚集指标,并收集和存储数据以供显示。此外,监控基础设施包括警报子系统,用于在任何异常行为期间通知相关方。让我们看一下这些基础架构组件:
-
主机指标代理-主机指标代理是运行在主机上的一个进程,它收集内存、CPU 和网络等主机子系统的性能统计数据。这些指标会定期传递给指标收集器进行存储和可视化。一些例子是 collectd 、 telegraf 和 metricbeat 。
-
指标聚合器-指标聚合器是运行在主机上的进程。运行在主机上的应用使用工具收集服务指标。收集的指标将通过 API 发送到聚合器流程或直接发送到指标收集器(如果可用)。收到的指标会定期汇总,并成批转发给指标收集器。一个例子是 StatsD 。
-
指标收集器-指标收集器进程从运行在多台主机上的指标聚合器收集所有指标。收集器负责解码并将这些数据存储在数据库中。度量收集和存储可能由一个单独的服务负责,比如我们接下来讨论的 InfluxDB 。一个例子是碳守护进程。
-
指标服务器-指标服务器可以像以图形方式呈现指标数据的 web 服务器一样简单。此外,度量服务器提供了聚合功能和 API,用于以编程方式获取度量数据。一些例子是 Grafana 和石墨网。
-
警报管理器-警报管理器定期轮询可用的度量数据,如果检测到任何异常,就会通知您。每个警报都有一套识别此类异常的规则。如今,许多度量服务器,如 Grafana 都支持警报管理。我们将在稍后的中详细讨论报警。例如 Grafana 和 Icinga 。
命令行工具
原文:https://linkedin.github.io/school-of-sre/level101/metrics_and_monitoring/command-line_tools/
今天的大多数 Linux 发行版都附带了一套工具来监控系统的性能。这些工具帮助您测量和理解各种子系统统计数据(CPU、内存、网络等)。让我们看看一些主要使用的工具。
-
ps/top
-进程状态命令(ps)显示 Linux 系统中当前运行的所有进程的信息。top 命令类似于 ps 命令,但它会定期更新显示的信息,直到程序终止。top 的一个高级版本叫做 htop,有一个更加用户友好的界面和一些额外的功能。这些命令行实用程序带有修改命令操作和输出的选项。以下是 ps 命令支持的一些重要选项。-
-p <pid1, pid2,...>
-显示与指定进程 id 匹配的进程的信息。类似地,您可以使用-u <uid>
和-g <gid>
来显示属于特定用户或组的进程的信息。 -
-a
-显示其他用户的进程信息,以及自己的进程信息。 -
-x
-当显示与其他选项匹配的进程时,包括没有控制终端的进程。
-
图 2:最高命令的结果
-
ss
-socket statistics 命令(ss)显示系统上网络插座的信息。这个工具是 netstat 的继任者,后者已被弃用。以下是 ss 命令支持的一些命令行选项:-
-t
-显示 TCP 套接字。同样,-u
显示 UDP 套接字,-x
表示 UNIX 域套接字,以此类推。 -
-l
-仅显示监听插座。 -
-n
-指示命令不解析服务名。而是显示端口号。
-
图 3:系统上的监听套接字列表
free
-free 命令显示主机上的内存使用统计信息,如可用内存、已用内存和可用内存。最常见的是,这个命令与-h
命令行选项一起使用,它以人类可读的格式显示统计信息。
图 4:主机上可读形式的内存统计数据
df --
df 命令显示磁盘空间使用统计数据。-i
命令行选项也经常用于显示 inode 的使用统计。-h
命令行选项用于以人类可读的格式显示统计数据。
图 5:以人类可读的形式显示系统上的磁盘使用统计信息
-
sar
-sar 实用程序实时监控各种子系统,如 CPU 和内存。该数据可以存储在由-o
选项指定的文件中。这个工具有助于识别异常情况。 -
【The interface top 命令(
iftop
)显示接口上主机的带宽利用率。此命令通常用于识别活动连接的带宽使用情况。-i
选项指定监视哪个网络接口。
图 6:主机上活动连接的网络带宽使用情况
-
tcpdump
-tcpdump 命令是一个网络监控工具,它捕获流经网络的网络数据包,并显示所捕获数据包的描述。以下是可用的选项:-
-i <interface>
-监听界面 -
host <IP/hostname>
-过滤进出指定主机的流量 -
src/dst
-显示从源(src)到目的地(dst)的单向流量 -
port <port number>
-过滤进出特定端口的流量
-
图 7:主机上docker0接口上数据包的 tcpdump
第三方监控
原文:https://linkedin.github.io/school-of-sre/level101/metrics_and_monitoring/third-party_monitoring/
如今,大多数云提供商都提供各种监控解决方案。此外,许多公司,如 Datadog 也提供监控即服务。在本节中,我们不会深入讨论监控即服务。
近年来,越来越多的人可以上网。许多服务都在网上提供,以迎合日益增长的用户群。结果,网页变得越来越大,客户端脚本也越来越多。用户希望这些服务快速无误。从服务的角度来看,在编写响应体时,发送一个 HTTP 200 OK 响应,一切看起来都没问题。但是在传输过程中或者在客户端可能会有错误。如前所述,从服务基础设施内部监控服务可以很好地了解服务的健康状况,但这还不够。您需要监控用户体验,特别是客户端服务的可用性。许多第三方服务,如 Catchpoint 、 Pingdom 等,都可以用来实现这个目标。
第三方监控服务可以生成模拟来自世界各地的用户请求的合成流量,以确保服务可以在全球范围内访问。针对真实用户监控(RUM)的其他第三方监控解决方案提供不同地理位置的性能统计数据,如服务正常运行时间和响应时间。这允许您从这些位置监视用户体验,这些位置可能具有不同的互联网主干、不同的操作系统以及不同的浏览器和浏览器版本。 Catchpoint 全球监控网络是一个 3 分钟的综合视频,解释了监控客户体验的重要性。
使用警报的主动监控
原文:https://linkedin.github.io/school-of-sre/level101/metrics_and_monitoring/alerts/
前面我们讨论了从服务及其底层基础设施收集关键指标数据点的不同方法。这些数据让我们更好地了解服务的执行情况。监控的主要目标之一是尽早发现任何服务降级(减少平均检测时间)并通知利益相关方,以便避免或尽早解决问题,从而减少平均恢复时间(MTTR)。例如,如果服务的资源使用率超过 90%时通知您,您可以采取预防措施来避免由于资源短缺而导致的任何服务中断。另一方面,当服务由于某个问题而关闭时,及早发现和通知此类事件可以帮助您快速修复问题。
图 8:在松弛时间收到的警告通知
如今,大多数可用的监控服务都提供了一种机制,可以根据一个或多个指标设置警报,从而主动监控服务的健康状况。这些警报有一组已定义的规则或条件,当违反规则时,您会收到通知。这些规则可以简单到在指标值超过 n 时发出通知,也可以复杂到对一段时间内的标准偏差进行周与周(WoW)比较。监控工具会向您通知活动警报,其中大多数工具都支持即时消息(IM)平台、SMS、电子邮件或电话。图 8 显示了一个样例警报通知,当内存使用量超过主机上总 RAM 空间的 90%时,会在 Slack 上收到该通知。
监控的最佳实践
原文:https://linkedin.github.io/school-of-sre/level101/metrics_and_monitoring/best_practices/
为服务设置监控时,请记住以下最佳实践。
-
使用正确的度量类型——目前大多数可用的库都提供了各种度量类型。选择适当的度量类型来监视您的系统。以下是指标的类型及其用途。
-
量规- 量规是一种常量类型的公制。初始化度量后,度量值不会改变,除非您有意更新它。
-
计时器- 计时器测量完成一项任务所需的时间。
-
计数器- 计数器统计特定事件发生的次数。
-
有关这些度量类型的更多信息,请参见数据类型。
-
避免过度监控 -监控可能是一项重大的工程任务 。 因此,一定不要在监控服务上花费太多的时间和资源,还要确保所有重要的指标都被捕获。
-
防止警报疲劳 -为重要且可行的指标设置警报。如果您收到太多非关键警报,随着时间的推移,您可能会开始忽略警报通知。因此,关键警报可能会被忽略。
-
为警报准备一本操作手册 -对于每一个警报,确保你有一份文件解释当警报触发时需要执行的操作和检查。这使得团队中的任何工程师都能够处理警报并采取必要的措施,而无需他人的任何帮助。
可观测性
原文:https://linkedin.github.io/school-of-sre/level101/metrics_and_monitoring/observability/
当提到构建可靠的系统时,工程师经常使用可观测性。可观测性是一个源自控制理论的术语,它是一个衡量系统的内部状态可以从其外部输出的知识中推断出来的程度的指标。日常使用的服务基础设施变得越来越复杂;仅靠主动监控不足以快速解决导致应用故障的问题。通过监控,您可以防止已知的过去的故障再次发生,但是对于复杂的服务架构,许多未知的因素会导致潜在的问题。为了解决这种情况,您可以使服务变得可观测。一个可观测的系统提供了对隐含故障模式的高度精细的洞察。此外,一个可观测的系统提供了关于其内部工作的丰富背景,这开启了揭示更深层次的系统问题的能力。
监控使故障检测成为可能;可观测性有助于更好地理解系统。在工程师中,有一种普遍的误解,认为监控和可观测性是两回事。实际上,可观测性是监控的超集;也就是说,监控提高了服务的可观测性。可观测性的目标不仅是检测问题,而且是理解问题在哪里,是什么导致了问题。除了度量之外,可观测性还有两个支柱:日志和跟踪,如图 9 所示。尽管这三个组件并不能使系统 100%可观测,但它们是最重要和最强大的组件,可以让我们更好地理解系统。这些支柱中的每一个都有其缺陷,这些缺陷在零答案的三个支柱中有所描述。
图 9:可观测性的三个支柱
因为我们已经讨论了指标,所以让我们看看另外两个支柱(日志和跟踪)。
日志
日志(通常称为事件)是服务在运行时执行的活动的记录,带有相应的时间戳。度量给出了关于系统降级的抽象信息,日志给出了导致这些降级的原因的详细视图。应用和基础架构组件创建的日志通过提供有关应用错误、异常和事件时间表的详细信息,有助于有效了解系统的行为。日志帮助您及时了解导致失败的事件。因此,检查日志对于排除系统故障至关重要。
日志处理包括来自单个应用的不同日志的聚合,以及随后将它们发送到中央存储。将日志移动到中央存储有助于保存日志,以防应用实例不可访问或者应用由于故障而崩溃。在中央位置提供日志后,您可以分析日志以从中获取有用的信息。出于审计和合规性目的,您可以将这些日志在中央存储上存档一段时间。日志分析器从日志行中获取有用的信息,比如请求用户信息、请求 URL(特性)、响应头(比如内容长度)和响应时间。这些信息基于这些属性进行分组,并通过可视化工具提供给您,以便快速理解。
您可能想知道这个日志信息有什么帮助。该信息给出了在所有涉及的实体上执行的活动的整体视图。例如,假设有人正在对 web 应用进行 DoS(拒绝服务)攻击。在日志处理的帮助下,您可以快速查看来自访问日志的顶级客户端 IP,并确定攻击来自何处。
同样,如果应用中的某个特性在使用特定的请求参数值访问时导致高错误率,日志分析的结果可以帮助您快速识别行为不当的参数值,并采取进一步的措施。
图 10:使用 ELK 堆栈的日志处理和分析
图 10 展示了一个使用 ELK (Elasticsearch,Logstash,Kibana)的日志处理平台,它提供了集中式的日志处理。Beats 是一个轻量级数据发送器的集合,可以通过网络发送日志、审计数据、网络数据等等。在这个用例中,我们使用 filebeat 作为日志发送器。Filebeat 监视服务日志文件,并将日志数据发送到 Logstash。Logstash 解析这些日志并转换数据,准备存储在 Elasticsearch 上。转换后的日志数据存储在 Elasticsearch 上,并编制索引以便快速检索。Kibana 搜索并显示存储在 Elasticsearch 上的日志数据。Kibana 还提供了一组可视化工具,用于图形化显示从日志数据中获得的摘要。
存储日志非常昂贵。并且服务器上每个事件的大量日志记录是昂贵的,并且占用更多的存储空间。随着服务数量的增加,这一成本会与服务数量成比例增加。
描摹
到目前为止,我们已经讨论了度量和日志记录的重要性。度量给出了系统的抽象概述,日志给出了所发生事件的记录。想象一个有多个微服务的复杂分布式系统,其中一个用户请求由系统中的多个微服务处理。度量和日志记录为您提供了一些关于系统如何处理这些请求的信息,但它们无法提供所有微服务的详细信息以及它们如何影响特定的客户端请求。如果缓慢的下游微服务导致响应时间增加,您需要详细了解所有涉及的微服务,以识别此类微服务。这种需求的答案是请求跟踪机制。
跟踪是一系列跨度,其中每个跨度是由不同微服务执行以服务于客户端请求的事件的记录。简而言之,跟踪是来自不同物理机器上的各种微服务的客户端请求服务的日志。每个 span 包括 span 元数据,如跟踪 ID 和 span ID,以及上下文,其中包括有关执行的事务的信息。
图 11:URL 缩写请求的跟踪和跨度
图 11 是我们之前在学习 Python 时提到的URL shorter例子中捕获的轨迹的图形表示。
与监视类似,跟踪基础结构包含一些用于收集、存储和访问跟踪的模块。每个微服务运行一个跟踪库,该库在后台收集跟踪,创建内存中的批处理,并提交跟踪后端。跟踪后端对接收到的跟踪数据进行规范化,并将其存储在持久性存储上。追踪数据来自多个不同的微服务;因此,跟踪存储通常被组织为增量存储数据,并通过跟踪标识符进行索引。这种组织有助于跟踪数据的重建和可视化。图 12 展示了分布式系统的结构。
图 12:分布式跟踪的剖析
今天,有一组工具和框架可用于构建分布式跟踪解决方案。以下是一些流行的工具:
-
OpenTelemetry :云原生软件的可观测性框架
-
Jaeger :开源分布式追踪解决方案
-
Zipkin :开源分布式追踪解决方案
总结
原文:https://linkedin.github.io/school-of-sre/level101/metrics_and_monitoring/conclusion/
强大的监控和警报系统对于系统维护和故障排除是必要的。带有关键指标的仪表板可以让您在一个地方了解服务性能。定义良好的警报(具有现实的阈值和通知)进一步使您能够快速识别服务基础架构和资源饱和中的任何异常。通过采取必要的措施,您可以避免任何服务降级并减少服务故障的 MTTD。
除了内部监控之外,监控真实的用户体验可以帮助您了解用户所感知的服务性能。很多模块都涉及到为用户服务,而且大部分都不在你的控制范围内。因此,您需要对真实用户进行监控。
度量给出了关于服务性能的非常抽象的细节。为了更好地理解系统并在事故期间更快地恢复,您可能希望实现可观测性的另外两个支柱:日志和跟踪。日志和跟踪数据可以帮助您了解导致服务失败或降级的原因。
以下是一些资源,可帮助您了解有关监控和可观测性的更多信息:
-
Yuri Shkuro 掌握分布式追踪
参考
-
工程博客 LinkedIn 、 Grafana 、【Elastic.co】T4、 OpenTelemetry
安全性
安全性
原文:https://linkedin.github.io/school-of-sre/level101/security/intro/
先决条件
从本课程中可以期待什么
本课程涵盖了信息安全的基础知识,并触及了系统安全、网络和 web 安全等主题。本课程旨在让您熟悉日常运营中的信息安全基础知识&然后作为一名 SRE,培养在开发解决方案时确保安全的心态。本课程还介绍了常见风险和最佳实践,以及找出易受攻击的系统和漏洞的实用方法,如果不加以保护,这些系统和漏洞可能会受到危害。
本课程不包括哪些内容
该课件不是一个道德黑客研讨会,也不是对问题的基础的深入探究。本课程不涉及黑客攻击或闯入系统,而是一种如何确保您不会陷入这种情况的方法,并让您了解系统可能被入侵的不同方式。
课程内容
第一部分:基础知识
原文:https://linkedin.github.io/school-of-sre/level101/security/fundamentals/
SRE 安全概述介绍
- 如果你仔细观察,站点可靠性工程和安全工程都与保持系统可用有关。
- 像不完整的发布、容量短缺和错误配置这样的问题会使系统不可用(至少暂时不可用)。
- 破坏用户信任的安全或隐私事件也会破坏系统的有用性。
- 因此,系统安全性应该是 SREs 最关心的问题。
-
SREs 应该参与重要的设计讨论和实际的系统变更。
-
它们在系统设计中有相当大的作用&因此有时是第一道防线。
-
SRE 帮助防止会影响基础设施整体安全性的不良设计和实施。
-
成功地设计、实现和维护系统需要对整个系统生命周期的承诺。只有当安全性和可靠性成为系统架构的核心要素时,这种承诺才有可能实现。
-
信息安全的核心支柱:
-
保密性–只允许用户访问被允许访问的数据
-
完整性–确保数据不被未授权用户篡改或更改
-
可用性–确保授权用户在需要时可以使用系统和数据
-
像安全工程师一样思考
-
启动新的应用或重构现有应用时,您应该考虑每个功能特性,并考虑:
- 围绕此功能的过程是否尽可能安全?换句话说,这是一个有缺陷的过程吗?
- 如果我是邪恶的,我会如何滥用这个特性?或者更具体地说,未能解决一个特性如何被滥用会导致设计缺陷。
- 该功能是否需要默认开启?如果是,是否有限制或选项可以帮助降低此功能带来的风险?
-
OWASP(开放网络应用安全项目)的安全原则
-
最小化攻击表面积:
- 添加到应用中的每个功能都会给整个应用增加一定的风险。安全开发的目的是通过减少攻击面来降低整体风险。
- 例如,web 应用通过搜索功能实现在线帮助。搜索功能可能容易受到 SQL 注入攻击。如果帮助功能仅限于授权用户,攻击的可能性就会降低。如果帮助功能的搜索功能是通过集中式数据验证例程实现的,那么执行 SQL 注入的能力就会大大降低。然而,如果帮助功能被重写以消除搜索功能(例如,通过更好的用户界面),这几乎消除了攻击表面区域,即使帮助功能在互联网上普遍可用。
-
建立安全默认值:
- 有许多方法可以为用户提供“开箱即用”的体验。然而,默认情况下,体验应该是安全的,如果允许的话,应该由用户决定降低他们的安全性。
- 例如,默认情况下,应该启用密码老化和复杂性。用户可能被允许关闭这两个功能,以简化他们对应用的使用,并增加他们的风险。
- 路由器、物联网设备的默认密码应该更改
-
最小特权原则
- 最小特权原则建议帐户拥有执行其业务流程所需的最小特权。这包括用户权限、资源权限(如 CPU 限制)、内存、网络和文件系统权限。
- 例如,如果一个中间件服务器只需要访问网络、读取数据库表以及写入日志的能力,那么这就描述了应该授予的所有权限。在任何情况下都不应该授予中间件管理特权。
-
纵深防御原则
- 深度防御原则表明,在一种控制措施合理的情况下,以不同方式应对风险的更多控制措施会更好。当深入使用控制时,可以使严重的漏洞变得非常难以利用,因此不太可能发生。
- 对于安全编码,这可能采取基于层的验证、集中审计控制以及要求用户登录所有页面的形式。
- 例如,如果一个有缺陷的管理界面能够正确地控制对生产管理网络的访问、检查管理用户授权并记录所有访问,那么它就不太可能容易受到匿名攻击。
-
安全失败
- 由于多种原因,应用经常无法处理事务。它们如何失败可以决定应用是否安全。
is _ admin = true 请尝试{ code _ which _ may _ faile();is _ admin = is _ user _ assigned _ role(" Adminstrator ");} catch(Exception err){ log . error(err . tostring());} ` ` `-如果 codeWhichMayFail()或 isUserInRole 失败或抛出异常,默认情况下,用户是管理员。这显然是一个安全隐患。
-
不要相信服务
- 许多组织利用第三方合作伙伴的处理能力,这些合作伙伴很可能具有与您不同的安全策略和状态。你不太可能影响或控制任何外部第三方,无论他们是家庭用户还是主要供应商或合作伙伴。
- 因此,对外部运行系统的隐式信任是没有保证的。所有外部系统都应该被类似地对待。
- 例如,忠诚计划提供商提供网上银行使用的数据,提供奖励点数和潜在兑换项目的小列表。但是,应该检查数据,以确保向最终用户显示是安全的,并且奖励积分是正数,而不是不可能的大。
-
职责分离
- 欺诈控制的关键是职责分离。例如,请求计算机的人不能签收,也不应该直接收到计算机。这防止了用户请求许多计算机并声称它们从未到达。
- 某些角色具有不同于普通用户的信任级别。特别是管理员不同于普通用户。通常,管理员不应该是应用的用户。
- 例如,管理员应该能够打开或关闭系统,设置密码策略,但不应该能够作为超级特权用户登录店面,例如能够代表其他用户“购买”商品。
-
通过模糊来避免安全
- 通过模糊实现的安全性是一种弱的安全控制,当它是唯一的控制时,几乎总是失败。这并不是说保守秘密是个坏主意,它只是意味着系统的安全性不应该依赖于隐藏细节。
- 例如,应用的安全性不应该依赖于对保密源代码的了解。安全性应依赖于许多其他因素,包括合理的密码策略、纵深防御、业务交易限制、稳固的网络架构、欺诈和审计控制。
- 一个实际的例子是 Linux。Linux 的源代码随处可得,但是如果保护得当,Linux 是一个安全且健壮的操作系统。
-
保持简单的安全性
- 攻击表面积和简单性是相辅相成的。某些软件工程实践更喜欢过于复杂的方法,而不是相对简单明了的设计。
- 当更简单的方法会更快更简单时,开发人员应该避免使用双重否定和复杂的架构。
- 例如,尽管在一个单独的中间件服务器上运行大量的单例实体 beans 可能很流行,但是简单地使用带有适当互斥机制的全局变量来防止竞争情况会更安全、更快。
-
正确修复安全问题
- 一旦确定了安全问题,就必须对其进行测试,并了解问题的根本原因。当使用设计模式时,安全问题可能在所有代码库中普遍存在,因此开发正确的修复方法而不引入回归是至关重要的。
- 例如,一个用户发现他们可以通过调整他们的 cookie 来查看另一个用户的余额。修复看起来相对简单,但是由于 cookie 处理代码是在所有应用之间共享的,所以对一个应用的更改会渗透到所有其他应用。因此,必须在所有受影响的应用上测试该修复程序。
-
可靠性和安全性
- 可靠性和安全性都是真正可信的系统的重要组成部分,但是构建既可靠又安全的系统是很困难的。虽然对可靠性和安全性的要求有许多共同的属性,但它们也需要不同的设计考虑。人们很容易忽略可靠性和安全性之间微妙的相互作用,这可能会导致意想不到的结果
- 例如:密码管理应用故障是由可靠性问题触发的,即负载平衡和减载策略不佳,其恢复后来因多种措施而变得复杂(HSM 机制需要插入服务器机架,作为一种身份验证& HSM 令牌应该锁在箱子里..&问题可以进一步拉长)设计来增加系统的安全性。
身份验证与授权
- 认证是验证用户就是他们所声称的那个人的行为。密码是最常见的身份验证因素,如果用户输入正确的密码,系统会认为身份有效并授予访问权限。
- 其他技术,如一次性 pin 码、认证应用,甚至生物识别技术也可以用于身份认证。在某些情况下,系统要求在授予访问权限之前成功验证多个因素。这种多因素身份验证(MFA)要求通常用于提高安全性,而不仅仅是密码。
- 系统安全中的授权是给予用户访问特定资源或功能的许可的过程。该术语通常与访问控制或客户端权限互换使用。授予某人在服务器上下载特定文件的权限,或者为单个用户提供对应用的管理访问权限都是很好的例子。在安全环境中,授权必须总是在身份验证之后,用户应该首先证明他们的身份是真实的,然后组织的管理员才能授予他们访问所请求的资源的权限。
通用认证流程(本地认证)
- 用户使用用户名/电子邮件/手机等标识符进行注册
- 应用将用户凭据存储在数据库中
- 应用发送验证电子邮件/消息来验证注册
- 注册成功后,用户输入登录凭证
- 身份验证成功后,用户就可以访问特定的资源
OpenID/OAuth
OpenID 是一种认证协议,允许我们在不使用本地认证系统的情况下认证用户。在这种情况下,用户必须向 OpenID 提供者注册,并且同一个提供者应该与您的应用的身份验证流集成在一起。为了验证细节,我们必须将身份验证请求转发给提供者。身份验证成功后,我们会收到一条成功消息和/或配置文件详细信息,我们可以使用这些信息执行必要的流程。
OAuth 是一种授权机制,允许你的应用用户访问某个提供商(Gmail/脸书/Instagram/etc)。成功响应后,我们(您的应用)会收到一个令牌,应用可以用它来代表用户访问某些 API。如果您的业务用例需要某些面向用户的 API,比如访问 Google Drive 或代表您发送 tweets,那么 OAuth 非常方便。大多数 OAuth 2.0 提供者可以用于伪认证。话虽如此,如果您在本地身份验证系统之上使用多个 OAuth 提供者来验证用户,事情会变得相当复杂。
密码系统
-
它是一门隐藏任何文本的科学和研究,只有预定的接收者或授权的人才能阅读它,任何文本甚至可以使用诸如隐形墨水或过去的机械密码术机器之类的东西。
-
密码术对于保护关键或专有信息是必要的,并且用于通过将一些明文转换成密文来对私人数据消息进行编码。其核心是,有两种方法可以做到这一点,更先进的方法都是建立在。
密码
- 密码是密码学的基石。密码是对消息执行加密或解密的一组算法。加密算法(E)采用密钥(k)和消息(m)并产生密文(c)。类似地,解密算法(D)采用秘密密钥(K)和先前产生的密文(C)。它们表示如下:
E(k,m) = c
D(k,c) = m
```sh
* 这也意味着要成为一个密码,它必须满足如下的一致性等式,这样才有可能解密。
D(k,E(k,m)) = m
流密码:
* 消息被分成字符或比特,并用与明文比特流一样长的密钥或密钥流(应该是随机的并且独立于消息流生成)进行加密。
* 如果密钥流是随机的,这个方案将是不可破解的,除非密钥流被获取,使得它是无条件安全的。密钥流必须以安全的方式提供给双方以防止其泄露。
分组密码:
* 块密码—处理块中的消息,然后对每个块进行加密或解密。
* 分组密码是一种对称密码,其中明文块被视为一个整体,并用于生成密文块。块密码采用 b 位长的块,并将它们加密成 b 位长的块。块大小通常为 64 或 128 位长。
![image5](https://gitee.com/OpenDocCN/geekdoc-linux-zh/raw/master/docs/lkin-sre/img/23e8c25bd836f461b7ef4d0866adc499.png) ![image6](https://gitee.com/OpenDocCN/geekdoc-linux-zh/raw/master/docs/lkin-sre/img/69e020203dce92b771f8f3370c6302ce.png)
加密
* **密钥(对称密钥)**:同一密钥用于加密和解密
* **公钥(非对称密钥)**在非对称中,加密密钥和解密密钥不同但相关。加密密钥称为公钥,解密密钥称为私钥。公钥和私钥被称为密钥对。
对称密钥加密
是吗
* 数据加密标准(DES)长期以来一直是世界范围的加密标准。IBM 在 1975 年开发了 DES,它在多年的密码分析中表现出色。DES 是一种对称加密算法,密钥长度固定为 56 位。算法还是不错的,但是因为密钥长度短,容易受到资源充足的蛮力攻击。
* DES 通常以块模式工作,以 64 位块加密数据。加密和解密使用相同的算法和密钥。
* 因为 DES 是基于简单的数学函数,所以很容易在硬件中实现和加速。
三重 DES
* 随着计算机处理能力的提高,最初的 56 位 DES 密钥变得太短,以至于无法抵御预算有限的攻击者。增加 DES 的有效密钥长度而不改变经过充分分析的算法本身的一种方法是连续几次使用不同密钥的相同算法。
* 将 DES 连续三次应用到纯文本块的技术称为三重 DES (3DES)。3DES 技术如图所示。今天,对 3DES 的暴力攻击被认为是不可行的。因为基本算法已经在现场测试了超过 25 年,所以被认为比它的前辈更值得信赖。![image7](https://gitee.com/OpenDocCN/geekdoc-linux-zh/raw/master/docs/lkin-sre/img/961efaf5e4ad56f7010144ecbe654492.png)
俄歇电子能谱
* 2000 年 10 月 2 日,美国国家标准和技术研究所(NIST)宣布选择 Rijndael 密码作为 AES 算法。琼·代蒙和文森特·里门开发的这种密码具有可变的分组长度和密钥长度。该算法目前规定了如何使用长度为 128、192 或 256 位的密钥来加密长度为 128、192 或 256 位的块(密钥长度和块长度的所有九种组合都是可能的)。块和密钥长度都可以轻松扩展到 32 位的倍数。
* 之所以选择 AES 来取代 DES 和 3DES,是因为它们要么太弱(DES,就密钥长度而言),要么太慢(3DES),无法在现代高效的硬件上运行。在相同的硬件上,AES 的效率更高,速度更快,通常是 DES 的 5 倍。AES 也更适合高吞吐量,尤其是在使用纯软件加密的情况下。然而,AES 是一个相对年轻的算法,正如密码学的黄金法则所说,“一个更成熟的算法总是更受信任。”
非对称密钥算法
![image8](https://gitee.com/OpenDocCN/geekdoc-linux-zh/raw/master/docs/lkin-sre/img/acb447b08812b9977c969b3c4afa632e.png)
* 在对称密钥系统中,Alice 首先将秘密消息放入一个盒子中,然后使用她有钥匙的锁将盒子挂锁。然后她通过普通邮件把盒子寄给鲍勃。当 Bob 收到盒子时,他使用 Alice 的密钥(他先前已经获得)的相同副本来打开盒子并阅读消息。
* 在非对称密钥系统中,Bob 不是在收到盒子时打开它,而是简单地将他自己的个人锁添加到盒子中,并通过公共邮件将盒子返回给 Alice。爱丽丝用她的钥匙打开锁,把盒子还给鲍勃,鲍勃的锁还在。最后,鲍勃用他的钥匙打开了锁,并阅读了爱丽丝发来的信息。
* 非对称系统的关键优势在于 Alice 从不需要向 Bob 发送其密钥的副本。这降低了第三方(例如,不道德的邮局主管)在密钥传输给 Bob 的过程中复制密钥的可能性,从而允许第三方监视 Alice 将来发送的所有消息。此外,如果 Bob 粗心大意,允许其他人复制他的密钥,Alice 给 Bob 的消息就会泄露,但是 Alice 给其他人的消息仍然是保密的
**注**:在 TLS 密钥交换方面,这是常见的做法。
迪菲-赫尔曼
* 该协议有两个系统参数 p 和 g,它们都是公开的,可以被任何人使用。参数 p 是一个素数,参数 g(通常称为生成元)是一个小于 p 的整数,但具有以下性质:对于 1 到 p–1 之间的每个数 n,都有一个 g 的幂 k,使得 n = gk mod p。
* Diffie Hellman 算法是一种非对称算法,用于为对称密钥算法建立共享机密。现在大多数人使用混合密码系统,即对称和非对称加密的组合。非对称加密被用作密钥交换机制中的一种技术来共享秘密密钥,并且在发送方和接收方之间共享密钥之后,通信将使用对称加密来进行。共享密钥将用于加密通信。
* 参考:[`medium . com/@ akhigbemanuel/what-is-the-diffie-hellman-key-exchange-algorithm-84d 60025 a30d`](https://medium.com/@akhigbemmanuel/what-is-the-diffie-hellman-key-exchange-algorithm-84d60025a30d)
南非共和国(Republic of South Africa)
* RSA 算法非常灵活,具有可变的密钥长度,如果需要,可以用速度换取算法的安全级别。RSA 密钥通常是 512 到 2048 位长。RSA 经受住了多年的广泛密码分析。虽然那些年既没有证明也没有否定 RSA 的安全性,但它们证明了该算法的可信度。RSA 安全性基于分解非常大的数字的困难性。如果发现了分解这些大数的简单方法,RSA 的有效性将被破坏。
* 参考:[`medium . com/curiositypapers/a-complete-explain-of-RSA-asymmetric-encryption-742 c 5971 e0f`](https://medium.com/curiositypapers/a-complete-explanation-of-rsa-asymmetric-encryption-742c5971e0f)
**注意** : RSA 密钥可以像 Diffie Hellman 一样用于密钥交换
哈希算法
* 哈希是用于保证数据完整性的机制之一。哈希基于单向数学函数,相对容易计算,但很难逆转。
* 哈希函数,是一种单向函数,用于输入数据以生成输出数据的固定长度摘要(指纹)。摘要在加密上是强的;也就是说,不可能从摘要中恢复输入数据。如果输入数据变化很小,摘要(指纹)就会发生很大的变化,这就是所谓的雪崩效应。
* 更多:
* [`medium . com/@ Raul Jordan/the-state-of-hashing-algorithms-the-why-the-how-and-the-future-b21 D5 c 0440 de`](https://medium.com/@rauljordan/the-state-of-hashing-algorithms-the-why-the-how-and-the-future-b21d5c0440de)
* [`medium . com/@ Stevie cellis/the-beautiful-hash-algorithm-f18d 9 D2 b 84 FB`](https://medium.com/@StevieCEllis/the-beautiful-hash-algorithm-f18d9d2b84fb)
讯息摘要 5
* MD5 是一种单向函数,利用它可以很容易地从给定的输入数据中计算出散列值,但是如果只给定一个散列值,则计算输入数据是不可行的。
SHA-1
* MD5 被认为不如 SHA-1 安全,因为 MD5 有一些弱点。
* HA-1 还使用更强的 160 位摘要,这使得 MD5 成为散列方法的第二选择。
* 该算法接收长度小于 264 位的消息,并生成 160 位的消息摘要。该算法比 MD5 稍慢。
**注意** : SHA-1 最近也被证明是被打破的,目前的最低建议是 SHA-256
数字证书
* 数字签名提供了一种对设备和个人用户进行数字身份验证的方法。在诸如 RSA 加密系统之类的公钥加密系统中,每个用户都有一个包含公钥和私钥的密钥对。密钥作为补充,用其中一个密钥加密的任何东西都可以用另一个密钥解密。简单地说,当数据用用户的私钥加密时,就形成了签名。接收者通过用发送者的公钥解密消息来验证签名。
* 密钥管理通常被认为是设计和实现加密系统中最困难的任务。企业可以通过使用公钥基础设施(PKI)来简化安全数据通信中遇到的一些部署和管理问题。因为公司经常通过 Internet 移动安全敏感的通信,所以必须实施有效的机制来保护敏感信息免受 Internet 上的威胁。
* PKI 为管理数字安全属性提供了一个分层框架。每个 PKI 参与者都持有由 CA(公共或私人)颁发的数字证书。证书包含几个在各方协商安全连接时使用的属性。这些属性必须包括证书有效期、终端主机身份信息、将用于安全通信的加密密钥以及颁发 CA 的签名。根据 PKI 的要求和能力,可以包括可选的属性。
* CA 可以是受信任的第三方,如 VeriSign 或 Entrust,也可以是您在组织内建立的私有(内部)CA。
* 可以使用发送者的公钥解密消息的事实意味着私钥的持有者创建了消息。这个过程依赖于接收方拥有发送方公钥的副本,并且非常确定地知道它确实属于发送方,而不是某个冒充发送方的人。
* 为了验证 CA 的签名,接收者必须知道 CA 的公钥。通常,这是在带外处理的,或者通过在证书安装期间执行的操作来处理。例如,默认情况下,大多数 web 浏览器都配置了几个 ca 的根证书。
CA 注册过程
1. 终端主机生成一个私钥-公钥对。
2. 终端主机生成一个证书请求,并将其转发给 CA。
3. 需要人工干预来批准注册请求,注册请求由 CA 接收。
4. CA 操作员批准请求后,CA 用其私钥签署证书请求,并将完成的证书返回给终端主机。
5. 终端主机将证书写入非易失性存储区域(PC 硬盘或 Cisco 路由器上的 NVRAM)。
**参见**:[`www . ssh . com/manuals/server-zos-product/55/ch 06s 03s 01 . html`](https://www.ssh.com/manuals/server-zos-product/55/ch06s03s01.html)
## 登录安全性
### 嘘
* 安全 Shell SSH 是一种流行的、强大的、基于软件的网络安全方法。
* 每当计算机向网络发送数据时,SSH 会自动加密(加密)数据。然后,当数据到达预期的接收者时,SSH 会自动解密(解码)它。
* 结果是透明加密:用户可以正常工作,不知道他们的通信在网络上被安全加密。此外,SSH 可以使用基于其配置方式的现代安全加密算法,并且在大公司的任务关键型应用中非常有效。
* SSH 有一个客户机/服务器架构
* SSH 服务器程序通常由系统管理员安装和运行,接受或拒绝到其主机的传入连接。然后,用户通常在其他计算机上运行 SSH 客户端程序,向 SSH 服务器发出请求,例如“请让我登录”、“请给我发送一个文件”或“请执行这个命令”客户端和服务器之间的所有通信都经过安全加密,不会被修改。
![image9](https://gitee.com/OpenDocCN/geekdoc-linux-zh/raw/master/docs/lkin-sre/img/b576dbf01e7ba9e6468e12d90c0d8e3e.png)
SSH 不是什么:
* 尽管 SSH 代表安全 shell,但它并不是 Unix Bourne shell 和 C shell 意义上的真正 Shell。它不是命令解释器,也不提供通配符扩展、命令历史等等。相反,SSH 创建了一个在远程计算机上运行 shell 的通道,在两个系统之间进行端到端的加密。
SSH 协议的主要特性和保证是:
* 通过高度加密保护您的数据隐私
* 通信的完整性,保证它们没有被改变
* 认证,即发送者和接收者的身份证明
* 授权,即账户的访问控制
* 转发或隧道来加密其他基于 TCP/IP 的会话
### 麻省理工学院开发的安全认证系统
* 根据希腊神话,Kerberos (Cerberus)是一种巨大的三头狗,它守卫着冥界的大门,防止死者离开。
* 因此,当谈到计算机科学时,Kerberos 是一种网络身份验证协议,并且是当前 Microsoft Active Directory 使用的默认身份验证技术,用于在局域网内对用户的服务进行身份验证。
* Kerberos 使用对称密钥加密,并需要可信的第三方身份验证服务来验证用户身份。因此,他们将 Kerberos 的名称用于他们的计算机网络身份验证协议,因为 Kerberos 的三个头代表:
* 客户端:用户/服务
* 服务器:受 Kerberos 保护的主机驻留在
![image10](https://gitee.com/OpenDocCN/geekdoc-linux-zh/raw/master/docs/lkin-sre/img/0d42df3062b18b5060ddd91aadf61450.png) -密钥分发中心(KDC),充当可信的第三方认证服务。
KDC 包括以下两台服务器:
* 身份验证服务器(AS ),执行初始身份验证并为用户颁发票证授予票证(TGT)。
* 票证授予服务器(TGS),它根据初始票证授予票证(TGT)颁发服务票证。
![image11](https://gitee.com/OpenDocCN/geekdoc-linux-zh/raw/master/docs/lkin-sre/img/2bca4c0d83649a22381b19a2dadd7d4b.png)
### 证书链
OpenSSL 命令输出的第一部分显示了编号为 0、1 和 2(不再是 2)的三个证书。每个证书都有一个主题 s 和一个颁发者 I。第一个证书编号为 0,称为终端实体证书。主题行告诉我们它对 google.com 的任何子域都有效,因为它的主题被设置为*.google.com
`$ openssl s_client -connect www.google.com:443 -CApath /etc/ssl/certs CONNECTED(00000005) depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign verify return:1 depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com verify return:1``--- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com i:/C=US/O=Google Trust Services/CN=GTS CA 1O1 1 s:/C=US/O=Google Trust Services/CN=GTS CA 1O1 i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign ---`T2】
* issuer 行表明它是由 Google Internet Authority G2 发布的,这也是第二个证书(编号 1)的主题
* OpenSSL 命令行在这里没有显示的是信任存储,它包含运行 OpenSSL 的系统所信任的 CA 证书列表。
* GlobalSign Authority 的公共证书必须存在于系统的信任存储中,才能关闭验证链。这被称为信任链,下图概括了它的高层次行为。
![image122](https://gitee.com/OpenDocCN/geekdoc-linux-zh/raw/master/docs/lkin-sre/img/fd748c4caa2b918bba4a4e569aa03ec5.png)
* 应用于验证网站真实性的信任链概念的高级视图。Firefox 信任存储中的根 CA 提供初始信任来验证整个链并信任终端实体证书。
### TLS 握手
1. 客户端向服务器发送一条 HELLO 消息,其中包含它支持的协议和算法列表。
2. 服务器回应你好并发送它的证书链。基于客户端的能力,服务器选择一个密码套件。
3. 如果密码套件支持临时密钥交换,如 ECDHE(ECDHE 是一种被称为椭圆曲线 Diffie-Hellman 交换的算法),服务器和客户端将使用 Diffie-Hellman 算法协商预主密钥。预主密钥从不通过网络发送。
4. 客户端和服务器创建一个会话密钥,用于加密通过连接传输的数据。
握手结束时,双方都拥有一个秘密的会话密钥,用于为连接的其余部分加密数据。这就是 OpenSSL 所说的万能钥匙
**注**
* TLS 有 3 个版本,TLS 1.0、1.1 和 1.2
* TLS 1.0 发布于 1999 年,是一个有近 20 年历史的协议。众所周知,它容易受到攻击,如 BEAST 和 POODLE,多年来,除了支持薄弱的加密技术,不能保持现代连接足够安全。
* TLS 1.1 是被遗忘的“老二”。和它的弟弟一样,它也有糟糕的加密技术。在大多数软件中,它被 TLS 1.2 所超越,很少看到 TLS 1.1 被使用。
### “完美”前向保密
* 密钥交换中的术语“短暂的”提供了一个重要的安全特征,它被错误地命名为完美前向保密(PFS)或简称为“前向保密”。
* 在非临时密钥交换中,客户端通过使用服务器的公钥对预主密钥进行加密,将其发送给服务器。然后,服务器用其私钥解密预主密钥。如果在稍后的某个时间点,服务器的私钥被泄露,攻击者可以回到这个握手,解密预主密钥,获得会话密钥,并解密整个流量。非短暂的密钥交换容易受到将来可能发生在记录的流量上的攻击。因为人们很少改变他们的密码,解密过去的数据对攻击者来说仍然是有价值的。
* 像 DHE 或它在椭圆曲线上的变体 ECDHE 这样的短暂密钥交换通过不在网络上传输预主密钥来解决这个问题。相反,预主密钥是由客户端和服务器使用公开交换的非敏感信息单独计算的。因为预主密钥以后不能被攻击者解密,所以会话密钥不会受到将来的攻击:因此,术语“完美前向保密”是安全的。
* 沿着流每隔 X 个块改变一次密钥。这就防止了攻击者简单地嗅探数据流并使用暴力破解整个系统。“前向保密”意味着仅仅因为我可以解密块 M,并不意味着我可以解密块 Q
* 缺点:
* PFS 的缺点是所有这些额外的计算步骤会导致握手延迟,降低用户速度。为了避免在每次连接时重复这项昂贵的工作,双方都通过一种称为会话恢复的技术缓存会话密钥以备将来使用。这就是 session-ID 和 TLS 票证的用途:它们允许共享一个会话 ID 的客户机和服务器跳过会话密钥的协商,因为它们之前已经同意了一个会话密钥,并直接安全地交换数据。
# 第二部分:网络安全
> 原文:<https://linkedin.github.io/school-of-sre/level101/security/network_security/>
## 介绍
* TCP/IP 是当今占主导地位的网络技术。它是一个五层架构。这些层从上到下依次是应用层、传输层(TCP)、网络层(IP)、数据链路层和物理层。除了 TCP/IP,还有其他网络技术。为了方便起见,我们使用 OSI 网络模型来表示非 TCP/IP 网络技术。不同的网络通过网关相互连接。网关可以放在任何一层。
* OSI 模型是一个七层体系结构。OSI 体系结构类似于 TCP/IP 体系结构,只是 OSI 模型在 TCP/IP 体系结构的应用层和传输层之间指定了两个附加层。这两层是表示层和会话层。图 5.1 显示了 TCP/IP 层和 OSI 层之间的关系。TCP/IP 中的应用层对应于 OSI 中的应用层和表示层。TCP/IP 中的传输层对应于 OSI 中的会话层和传输层。TCP/IP 体系结构中的其余三层与 OSI 模型中的其余三层一一对应。
TCP/IP 体系结构和 OSI 模型各层之间的对应关系。还示出了网络层中加密算法的布局,其中虚线箭头表示加密算法的实际通信
OSI 各层的功能简述如下:
1. 应用层是应用和网络程序之间的接口。它支持应用和最终用户处理。常见的应用层程序包括远程登录、文件传输、电子邮件和 Web 浏览。
2. 表示层负责处理不同形式的数据。该协议层允许位于具有不同平台的通信信道的不同端的应用层程序理解彼此的数据格式,而不管它们是如何呈现的。
3. 会话层负责创建、管理和关闭通信连接。
4. 传输层负责提供可靠的连接,如数据包排序、流量控制和拥塞控制。
5. 网络层负责将与设备无关的数据包从当前跳路由到下一跳。
6. 数据链路层负责将设备无关的数据包封装到设备相关的数据帧中。它有两个子层:逻辑链路控制和媒体访问控制。
7. 物理层负责通过某些物理介质传输设备相关的帧。
8. 从应用层开始,应用生成的数据逐层传递到物理层。来自前一层的数据被包含在当前层的新信封中,其中来自前一层的数据也只是包含来自前一层的数据的信封。这类似于将一个较小的信封装入一个较大的信封。每层添加的信封包含足够的信息来处理数据包。应用层数据被分成足够小的块,以便在下一层封装在信封中。
9. 根据以下基本步骤,应用数据块在 TCP/IP 体系结构中被“修饰”。在发送端,当应用数据块被向下传递到 TCP 层时,它被封装在 TCP 数据包中。换句话说,TCP 数据包由报头和有效载荷组成,其中报头对应于 TCP 信封,有效载荷是应用数据块。同样,当 TCP 数据包被向下传递到 IP 层时,它将被封装在 IP 数据包中。IP 数据包由报头和有效载荷组成,有效载荷是从 TCP 层向下传递的 TCP 数据包。当 IP 分组被向下传递到数据链路层时,它将被封装在设备相关的帧(例如,以太网帧)中。一帧有一个帧头,也可能有一个帧尾。例如,除了报头之外,以太网帧还有 32 位循环冗余校验(CRC)报尾。当帧被传递到物理层时,它将被转换成一系列媒体信号进行传输
![image15](https://gitee.com/OpenDocCN/geekdoc-linux-zh/raw/master/docs/lkin-sre/img/241bbeb68439ce365d32a097c35b826d.png)数据包生成流程图
10. 在目的端,媒体信号由物理层转换成帧,然后向上传递到数据链路层。数据链路层将帧有效负载(即封装在帧中的 IP 数据包)向上传递到 IP 层。IP 层将 IP 有效载荷(即封装在 IP 包中的 TCP 包)向上传递到 TCP 层。TCP 层将 TCP 有效负载(即应用数据块)向上传递到应用层。当数据包到达路由器时,它仅向上到达 IP 层,在那里修改 IP 报头中的某些字段(例如,TTL 的值减 1)。然后,这个修改后的分组被逐层向下传递回物理层,以便进一步传输。
### 公钥基础设施
* 为了在网络应用中部署加密算法,我们需要一种使用开放网络分发密钥的方法。公钥加密是分发这些密钥的最佳方式。要使用公钥加密,我们需要构建一个公钥基础设施(PKI)来支持和管理公钥证书和证书颁发机构(CA)网络。特别是,公钥基础设施被设置为执行以下功能:
* 在向用户颁发公钥证书之前,确定用户的合法性。
* 应用户请求颁发公钥证书。
* 根据用户请求延长公钥证书的有效时间。
* 应用户请求或当相应的私钥泄露时,撤销公钥证书。
* 存储和管理公钥证书。
* 防止数字签名者否认他们的签名。
* 支持 CA 网络以允许不同的 CA 对其他 CA 颁发的公钥证书进行身份验证。
* x . 509:[`certificatedecoder.dev/?gclid = eaiaiqobchmi 0m 731 o 6g 6 givvsqrch 04 bqaaaeaayaaegkrkpd _ BwE`](https://certificatedecoder.dev/?gclid=EAIaIQobChMI0M731O6G6gIVVSQrCh04bQaAEAAYASAAEgKRkPD_BwE)
### IPsec:网络层的安全协议
* IPsec 是网络层的主要安全协议
* IPsec 为构建虚拟专用网络(VPN)提供了一个强大的平台。VPN 是覆盖在公共网络上的私有网络。
* 在网络层部署加密算法的目的是加密或验证 IP 数据包(或者只是有效载荷,或者是整个数据包)。
* IPsec 还规定了如何交换密钥。因此,IPsec 由认证协议、加密协议和密钥交换协议组成。它们分别被称为认证报头(AH)、封装安全负载(ESP)和互联网密钥交换(IKE)。
### PGP & S/MIME:电子邮件安全性
* 应用层有几种安全协议。这些协议中最常用的是电子邮件安全协议,即 PGP 和 S/MIME。
* SMTP(“简单邮件传输协议”)用于通过端口 25 从客户端向服务器发送和交付:它是发送服务器。相反,POP(“邮局协议”)允许用户接收邮件并下载到他们的收件箱:它是接收服务器。邮局协议的最新版本被命名为 POP3,从 1996 年开始使用;它使用端口 110
电子邮件加密程序
* PGP 实现了所有主要的加密算法、ZIP 压缩算法和 Base64 编码算法。
* 它可用于验证消息、加密消息或两者兼而有之。PGP 遵循以下一般过程:身份验证、ZIP 压缩、加密和 Base64 编码。
* Base64 编码过程使邮件准备好进行 SMTP 传输
GPG (GnuPG)
* GnuPG 是另一个公司可以使用的基于 OpenPGP 的免费加密标准。
* GnuPG 是赛门铁克 PGP 的替代品。
* 主要区别在于支持的算法。然而,GnuPG 在设计上与 PGP 配合得很好。因为 GnuPG 是开放的,一些企业更喜欢 Symantec 的 PGP 提供的技术支持和用户界面。
* 需要注意的是,GnuPG 和 PGP 的兼容性之间存在一些细微差别,例如某些算法之间的兼容性,但在大多数应用如电子邮件中,都有变通方法。其中一个算法是 IDEA 模块,由于专利问题,它没有包含在 GnuPG 中。
s/哑剧
* SMTP 只能处理 7 位 ASCII 文本(您可以使用 UTF-8 扩展来缓解这些限制)消息。虽然 POP 可以处理除 7 位 ASCII 之外的其他内容类型,但是在通用默认设置下,POP 可以将存储在邮件服务器中的所有消息下载到用户的本地计算机。之后,如果 POP 从邮件服务器中删除这些邮件。这使得用户很难从多台计算机上阅读他们的消息。
* 多用途 Internet 邮件扩展协议(MIME)旨在支持发送和接收各种格式的电子邮件,包括由文字处理器生成的非文本文件、图形文件、声音文件和视频剪辑。此外,MIME 允许单个消息以这些格式的任意组合包含混合类型的数据。
* 在 TCP 端口 143 上运行的互联网邮件访问协议(IMAP )(仅用于非加密)在邮件服务器中存储(可在服务器和客户端上配置,就像 PoP 一样)传入的电子邮件消息,直到用户有意删除它们。这允许用户从多台机器访问他们的邮箱,并将消息下载到本地机器,而不用从邮件服务器的邮箱中删除它。
SSL/TLS
* SSL 通过要求服务器使用由可信 CA 签署的安全证书,使用 PKI 来决定服务器的公钥是否可信。
* 当 Netscape Navigator 1.0 发布时,它信任由 RSA 数据安全公司运营的单个 CA。
* 服务器的公共 RSA 密钥过去被存储在安全证书中,然后可以被浏览器用来建立安全的通信通道。我们今天使用的安全证书仍然依赖于 Netscape Navigator 1.0 当时使用的同一标准(名为 X.509)。
* Netscape 打算训练用户(尽管后来没有成功)区分安全通信和不安全通信,所以他们在地址栏旁边放了一个锁图标。当锁打开时,通信是不安全的。关闭的锁意味着通信已经通过 SSL 得到了保护,这需要服务器提供一个签名的证书。很明显,你对这个图标很熟悉,因为从那以后它就出现在每个浏览器中。网景公司的工程师们真正创造了安全互联网通信的标准。
* 在发布 SSL 2.0 一年后,Netscape 修复了几个安全问题,并发布了 SSL 3.0,这是一个协议,尽管自 2015 年 6 月以来被正式否决,但在推出 20 多年后,仍在世界上的某些地区使用。为了使 SSL 标准化,因特网工程任务组(IETF)创建了一个稍加修改的 SSL 3.0,并在 1999 年将其公布为传输层安全(TLS) 1.0。SSL 和 TLS 之间的名称变化至今仍在困扰着人们。从官方角度来说,TLS 是新的 SSL,但实际上,人们可以互换使用 SSL 和 TLS 来谈论任何版本的协议。
* 必看:
* [`tls.ulfheim.net/`](https://tls.ulfheim.net/)
* [`davidwong.fr/tls13/`](https://davidwong.fr/tls13/)
## 网络边界安全
让我们看看如何检查周边,即边缘,这是第一层保护
### 通用防火墙框架
* 需要防火墙,因为加密算法不能有效地阻止恶意数据包进入边缘网络。
* 这是因为无论 IP 数据包是否加密,它们总是可以被转发到边缘网络。
* 20 世纪 90 年代开发的防火墙是帮助限制网络访问的重要工具。防火墙可以是硬件设备、软件包或两者的组合。
* 从外部流入内部网络的数据包应该在被允许进入之前进行评估。防火墙的一个关键要素是它能够在不影响通信速度的情况下检查数据包,同时为内部网络提供安全保护。
* 防火墙执行的数据包检查可以使用几种不同的方法来完成。根据防火墙使用的特定方法,它可以被描述为包过滤、电路网关、应用网关或动态包过滤。
### 数据包过滤器
* 它检查从外部进入内部网络的入站数据包,并检查从内部网络出去的出站数据包
* 打包过滤只检查 IP 报头和 TCP 报头,而不检查在应用层生成的有效负载
* 包过滤防火墙使用一组规则来确定是允许还是拒绝数据包通过。
* 两种类型:
* 无国籍的
* 它将每个数据包视为一个独立的对象,并且不跟踪任何以前处理过的数据包。换句话说,无状态过滤会在数据包到达时对其进行检查,并在不留下任何被检查数据包记录的情况下做出决定。
* 宏伟威严的
* 状态过滤,也称为连接状态过滤,跟踪内部主机和外部主机之间的连接。连接状态(或简称状态)表示是 TCP 连接还是 UDP 连接,以及连接是否建立。
### 电路网关
* 电路网关也称为电路级网关,通常在传输层运行
* 它们评估 TCP(或 UDP)报头中包含的 IP 地址和端口号信息,并使用这些信息来确定是否允许内部主机和外部主机建立连接。
* 通常的做法是将包过滤和电路网关结合起来形成动态包过滤(DPF)。
### 应用网关(ALG)
* 又名代理服务器
* 应用层网关(ALG)充当内部主机的代理,处理来自外部客户端的服务请求。
* ALG 对每个 IP 数据包(入口或出口)执行深度检查。
* 特别地,ALG 检查包含在分组中的应用格式(例如,MIME 格式或 SQL 格式),并检查其有效载荷是否被允许。
* 因此,ALG 能够检测有效载荷中包含的计算机病毒。由于 ALG 会检查数据包的有效负载,因此除了阻止带有可疑 IP 地址和 TCP 端口的数据包之外,它还能够检测恶意代码并隔离可疑数据包。另一方面,ALG 也会导致大量的计算和空间开销。
### 可信系统和堡垒主机
* 可信操作系统(TOS)是满足一组特定安全要求的操作系统。操作系统是否可信取决于几个因素。例如,对于要被认证为可信的特定计算机上的操作系统,除了别的以外,还需要验证满足以下四个要求:
* 其系统设计没有缺陷;
* 其系统软件没有漏洞;
* 其系统配置正确;和
* 其系统管理得当。
* 堡垒主机
* 堡垒主机是具有强大防御机制的计算机。它们通常用作实现应用网关、电路网关和其他类型防火墙的主机。堡垒主机在可信的操作系统上运行,该操作系统不得包含不必要的功能或程序。这一措施有助于减少错误概率,并使安全检查更容易进行。只有那些必要的网络应用,例如 SSH、DNS、SMTP 和身份验证程序,才安装在堡垒主机上。
* Bastion 主机也主要用作受控的入口点,以便安全监控可以更精确地关注发生在单个点上的动作。
* * *
## 常用技术&扫描、数据包捕获
### 使用 Nmap 扫描端口
* Nmap(“网络映射器”)是一个免费的开源(许可)工具,用于网络发现和安全审计。许多系统和网络管理员也发现它对于诸如网络库存、管理服务升级计划以及监控主机或服务正常运行时间等任务非常有用。
* Nmap 最好的一点是它是免费和开源的,非常灵活和通用
* Nmap 通常用于确定网络中的活动主机、这些主机上的开放端口、这些开放端口上运行的服务以及该端口上该服务的版本标识。
* 更多在 http://scanme.nmap.org/
```sh
nmap [scan type] [options] [target specification]
Nmap 使用 6 种不同的端口状态:
- 开放 —开放端口是主动接受 TCP、UDP 或 SCTP 连接的端口。开放的端口是我们最感兴趣的,因为它们容易受到攻击。开放端口还显示网络上可用的服务。
- 关闭 —接收和响应 Nmap 探测数据包的端口,但没有应用在该端口上侦听。有助于识别主机是否存在以及操作系统检测。
- Filtered — Nmap 无法确定端口是否打开,因为包过滤会阻止其探测器到达该端口。过滤可能来自防火墙或路由器规则。在扫描过程中,过滤端口通常很少给出信息,因为过滤器可能会丢弃探测而不作出响应,或者以无用的错误消息作出响应,例如目的地不可达。
- 未过滤 —端口可访问,但 Nmap 不知道它是打开的还是关闭的。仅在用于映射防火墙规则集的确认扫描中使用。其他扫描类型可用于识别端口是否打开。
- 打开/过滤 — Nmap 无法确定是打开还是过滤。当打开的端口没有响应时,就会发生这种情况。没有响应可能意味着数据包筛选器丢弃了该探测,或者任何响应都被阻止。
- 关闭/过滤 — Nmap 无法确定端口是关闭还是过滤。仅用于 IP ID 空闲扫描。
Nmap 扫描的类型:
-
TCP 连接
-
TCP 连接扫描完成三次握手。
-
如果端口打开,操作系统完成 TCP 三次握手,端口扫描器立即关闭连接以避免 DOS。这是“嘈杂”的,因为服务可以记录发送者的 IP 地址,并可能触发入侵检测系统。
-
UDP 扫描
-
该扫描检查是否有任何 UDP 端口正在侦听。
-
由于 UDP 不像 TCP 那样以肯定的确认来响应,而是仅在端口关闭时才响应传入的 UDP 数据包,
-
同步扫描
-
SYN 扫描是 TCP 扫描的另一种形式。
-
这种扫描类型也称为“半开扫描”,因为它实际上从不打开完整的 TCP 连接。
-
端口扫描器生成一个 SYN 数据包。如果目标端口是开放的,它将使用 SYN-ACK 数据包进行响应。扫描仪主机用 RST 数据包响应,在握手完成前关闭连接。
-
如果端口关闭但未过滤,目标将立即用 RST 数据包响应。
-
SYN 扫描的优点是各个服务实际上从不接收连接。
-
手指扫描
-
这是一种秘密扫描,类似于 SYN 扫描,但发送的是 TCP FIN 数据包。
-
确认扫描
-
Ack 扫描确定端口是否被过滤。
-
零扫描
-
另一种非常隐秘的扫描,将所有 TCP 报头标志设置为 off 或 null。
-
这通常不是有效的数据包,一些主机不知道如何处理。
-
圣诞扫描
-
类似于空扫描,只是 TCP 报头中的所有标志都设置为 on
-
RPC 扫描
-
这种特殊类型的扫描寻找对 RPC(远程过程调用)服务的机器应答
-
空闲扫描
-
这是一种超级隐蔽的方法,扫描数据包从外部主机上反弹回来。
-
您不需要控制另一台主机,但它必须设置并满足某些要求。你必须输入我们的“僵尸”主机的 IP 地址和使用的端口号。这是 Nmap 中比较有争议的选项之一,因为它只用于恶意攻击。
扫描技术
一些扫描技术可用于获取有关系统及其端口的更多信息。你可以在medium . com/infosec-adventures/nmap-cheat sheet-a 423 fcd da 0 ca
了解更多信息
OpenVAS
- OpenVAS 是一个全功能的漏洞扫描器。
- OpenVAS 是一个服务和工具框架,它提供了一个全面而强大的漏洞扫描和管理包
- OpenVAS 是一个开源程序,最初是一度更受欢迎的扫描程序 Nessus 的一个分支。
- OpenVAS 由三个主要部分组成。这些是:
- 网络漏洞测试(NVTs)的定期更新馈送;
- 运行 NVTs 的扫描仪;和
- 一个 SQLite 3 数据库,用于存储您的测试配置以及 NVTs 的结果和配置。
www.greenbone.net/en/install_use_gce/
WireShark
- Wireshark 是一个协议分析器。
- 这意味着 Wireshark 不仅可以解码数据包的位和字节,还可以解码数据包和协议之间的关系。
- Wireshark 理解协议序列。
Wireshark 的简单演示
-
仅捕获 udp 数据包:
-
捕获筛选器= "udp "
-
仅捕获 tcp 数据包
-
捕获筛选器= "tcp "
-
TCP/IP 三次握手
-
按 IP 地址过滤:显示来自 IP 的所有流量,无论是源流量还是目的流量
-
ip.addr == 192.168.1.1
-
按源地址过滤:仅显示来自 IP 源的流量
-
ip.src == 192.168.0.1
-
按目标过滤:仅显示来自 IP 目标的流量
-
ip.dst == 192.168.0.1
-
按 IP 子网过滤:显示来自子网的流量,无论是来源还是目的地
-
ip.addr = 192.168.0.1/24
-
按协议过滤:按协议名称过滤流量
-
十进位计数制
-
超文本传输协议(HTTP)(Hyper Text Transport Protocol 的缩写)
-
文件传输协议(File Transfer Protocol 的缩写)
-
阿尔普
-
嘘
-
远程登录
-
网间控制报文协议
-
排除 IP 地址:删除进出 IP 地址的流量
-
!ip.addr ==192.168.0.1
-
显示两个特定子网之间流量
* ip.addr == 192.168.0.1/24,ip.addr == 192.168.1.1/24
- 显示两个特定工作站之间的流量
* ip.addr == 192.168.0.1,ip.addr == 192.168.0.2
- 按 MAC 过滤
* eth.addr = 00:50:7f:c5:b6:78
- 过滤 TCP 端口
* tcp.port == 80
- 过滤 TCP 端口源
* tcp.srcport == 80 - 过滤 TCP 端口目标
* tcp.dstport == 80 - 查找用户代理
* http.user_agent 包含 Firefox
* !http.user_agent 包含||!http.user_agent 包含 Chrome - 过滤广播流量
* !(arp 或 icmp 或 dns) - 过滤 IP 地址和端口
* TCP . port = = 80 & & IP . addr = = 192 . 168 . 0 . 1
- 过滤所有 http get 请求
* 请求
- 过滤所有 http get 请求和响应
* http.request 或 http.response - 过滤三次握手
* tcp.flags.syn1 或(tcp.seq1 且 tcp.ack1 且 tcp.len0 且 tcp.analysis.initial_rtt) - 按类型查找文件
* 框架包含“(附件|tar|exe|zip|pdf)” - 基于关键字查找流量
* tcp 包含 facebook
* 框架包含 facebook - 检测 SYN 泛洪
* tcp.flags.syn == 1,tcp.flags.ack == 0
Wireshark 混杂模式 -默认情况下,Wireshark 只捕获进出其运行的计算机的数据包。通过在捕获设置中选中在混杂模式下运行 Wireshark 的复选框,您可以捕获 LAN 上的大部分流量。
倾倒帽
- Dumpcap 是一个网络流量转储工具。它从实时网络中捕获数据包数据,并将数据包写入文件。Dumpcap 的原生捕获文件格式是 pcapng,这也是 Wireshark 使用的格式。
- 默认情况下,Dumpcap 使用 pcap 库从第一个可用的网络接口捕获流量,并将收到的原始数据包数据以及数据包的时间戳写入 pcapng 文件。捕获过滤器语法遵循 pcap 库的规则。
- Wireshark 命令行实用程序“dumpcap.exe”可用于捕获一段时间内的 LAN 流量。
- 也可以使用 Wireshark 本身,但是 dumpcap 在长时间捕获时不会大量使用计算机的内存。
DaemonLogger
- Daemonlogger 是一个专门设计用于网络和系统管理(NSM)环境的数据包记录应用。
- Daemonlogger 提供的最大好处是,像 Dumpcap 一样,它很容易用于捕获数据包。为了开始捕获,您只需要调用命令并指定一个接口。
- daemonlogger–I et h1
- 默认情况下,该选项将开始捕获数据包并将它们记录到当前工作目录中。
- 将收集数据包,直到捕获文件大小达到 2 GB,然后将创建一个新文件。这将无限期地继续下去,直到进程停止。
网络嗅探
- Netsniff-NG 是一个高性能的数据包捕获工具
- 到目前为止,我们讨论的实用程序依赖 Libpcap 进行捕获,而 Netsniff-NG 利用零拷贝机制来捕获数据包。这样做是为了支持在高吞吐量链路上捕获完整的数据包。
- 要开始用 Netsniff-NG 捕获包,我们必须指定一个输入和输出。在大多数情况下,输入将是网络接口,输出将是磁盘上的文件或文件夹。
netsniff-ng –i eth1 –o data.pcap
网络流
-
NetFlow 是 Cisco 路由器在 1996 年左右推出的一项功能,能够在 IP 网络流量进出接口时收集流量。通过分析 NetFlow 提供的数据,网络管理员可以确定流量的来源和目的地、服务等级以及拥塞原因等。典型的流监控设置(使用 NetFlow)由三个主要组件组成:[1]
-
流导出器:将数据包聚合成流,并向一个或多个流收集器导出流记录。
-
流收集器:负责接收、存储和预处理从流导出器接收的流数据。
-
分析应用:例如,在入侵检测或流量分析环境中分析接收到的流数据。
- 支持 NetFlow 的路由器和交换机可以收集启用了 NetFlow 的所有接口上的 IP 流量统计信息,然后将这些统计信息作为 NetFlow 记录导出到至少一个 NetFlow 收集器,通常是进行实际流量分析的服务器。
标识部分(Identification Section)
一种安全解决方案,可检测环境中与安全相关的事件,但不会阻止它们。IDS 传感器可以基于软件和硬件来收集和分析网络流量。这些传感器有两种类型,网络 id 和主机 id。
- 主机 IDS 是一个特定于服务器的代理,它运行在服务器上,监控操作系统的开销最小。
- 网络 IDS 可以嵌入网络设备、独立设备或监控网络流量的模块中。
基于签名的 IDS
-
基于签名的 IDS 监控网络流量或观察系统,并在已知的恶意事件发生时发出警报。
-
它通过将数据流与已知攻击模式的数据库进行比较来做到这一点
-
这些签名明确定义了哪些流量或活动应被视为恶意的。
-
十多年来,基于签名的检测一直是基于网络的防御安全的基础,部分原因是它非常类似于使用防病毒实用程序在主机级别检测恶意活动的方式
-
公式相当简单:分析师观察恶意活动,从活动中得出指标,并将其发展为签名,然后这些签名将在活动再次发生时发出警报。
-
例如:SNORT & SURICATA
基于策略的 IDS
- 基于策略的 IDSs(主要是主机 IDSs)在违反配置的策略时触发警报。
- 这个配置的策略是或者应该是安全策略的表示。
- 这种类型的 IDS 非常灵活,可以根据公司的网络需求进行定制,因为它确切地知道什么是允许的,什么是不允许的。
- 另一方面,基于签名的系统依赖于供应商的细节和默认设置。
基于异常的入侵检测
- 基于异常的 IDS 寻找偏离正常的流量,但是什么是正常网络流量模式的定义是棘手的部分
- 基于异常的入侵检测系统有两种类型:统计异常检测和非统计异常检测
- 统计异常检测以交互方式学习一段时间内的流量模式。
- 在非统计方法中,IDS 有一个预定义的假定可接受和有效的流量模式配置。
基于主机的 IDS 和基于网络的 IDS
-
主机 IDS 可以被描述为驻留在需要保护的网络的每个服务器上的分布式代理。这些分布式代理与底层操作系统紧密相关。
-
另一方面,网络 IDSs 可以被描述为智能嗅探设备。网络 IDS 从网络中捕获数据(原始数据包),而主机 IDS 从安装它们的主机上捕获数据。
蜜罐
- 使用诱饵机器将入侵者的注意力从受保护的机器上引开是防止入侵攻击的主要技术。任何用作诱饵来引诱攻击者远离重要资产并收集入侵或滥用行为的设备、系统、目录或文件都被称为蜜罐。
- 蜜罐可以实现为物理设备或仿真系统。其思想是在局域网中设置诱饵机器,或在文件系统中设置诱饵目录/文件,使它们看起来很重要,但有几个可利用的漏洞,引诱攻击者攻击这些机器或目录/文件,以便其他机器、目录和文件可以避开入侵者的注意。诱饵机器可以是主机计算机或服务器计算机。同样,我们也可以建立假路由器,甚至假局域网。
盔甲上的漏洞(TCP/IP 安全问题)
IP 欺骗
- 在这种类型的攻击中,攻击者用不同的地址替换发件人的 IP 地址,或者在极少数情况下替换目的地的 IP 地址。
- IP 欺骗通常用于攻击目标主机。在其他情况下,它被用来发起拒绝服务(DoS)攻击。
- 在 DoS 攻击中,攻击者修改 IP 数据包,误导目标主机接受原始数据包,将其视为来自可信主机的数据包。攻击者必须知道可信主机的 IP 地址,才能修改数据包报头(源 IP 地址),使数据包看起来好像来自该主机。
IP 欺骗检测技术
-
直接 TTL 探针
-
在这种技术中,我们向可疑欺骗 IP 主机发送一个数据包,该主机触发回复并将 TTL 与可疑数据包进行比较;如果回复中的 TTL 与被检查的数据包不同;这是一个欺骗数据包。
-
当攻击者与受害者位于不同的子网时,这种技术就成功了。
-
IP 标识号。
-
向可疑欺骗流量的主机发送一个探测,触发回复并将 IP ID 与可疑流量进行比较。
-
如果 IP IDs 不在被检查的数据包的邻近值中,则可疑流量是欺骗的
-
TCP 流量控制方法
-
发送欺骗 TCP 数据包的攻击者不会收到目标的 SYN-ACK 数据包。
-
因此,攻击者无法对拥塞窗口大小的变化做出响应
-
当接收器在窗口大小用尽后仍接收到流量时,最有可能的情况是数据包被欺骗。
隐蔽通道
-
隐蔽或秘密通道可以被最好地描述为两个实体之间的管道或通信通道,它可以被以违反系统安全规范的方式传输信息的进程或应用所利用。
-
更具体地说,对于 TCP/IP,在某些情况下,建立隐蔽通道,并且数据可以在两个终端系统之间秘密地传递。
-
例如:ICMP 位于 TCP/IP 协议组的互联网层,在所有 TCP/IP 主机中实现。根据 ICMP 协议的规范,ICMP 回应请求消息应该有一个 8 字节的报头和一个 56 字节的有效载荷。ICMP 回应请求数据包不应在有效负载中携带任何数据。然而,这些数据包经常被用来携带秘密信息。ICMP 数据包稍作改动,以便在有效载荷中携带机密数据。这使得数据包变得更大,但是在协议栈中没有控制来消除这种行为。ICMP 数据包的改变使得入侵者能够对专门的客户机-服务器对进行编程。这些小段代码在不通知网络管理员的情况下导出机密信息。
-
ICMP 不仅可以用于数据过滤。例如,一些 C&C 工具,如 Loki,早在 1996 年就使用 ICMP 信道建立加密的交互式会话。
-
深度数据包检测已经走过了漫长的道路。许多 IDS/IPS 检测 ICMP 隧道。
- 检查不包含与请求相同的有效负载的回应响应
- 检查 ICMP 流量,尤其是超出可接受阈值的流量
IP 碎片攻击
-
TCP/IP 协议族,或者更具体地说是 IP,允许分组的分段。(这是一个特性,而不是一个错误)
-
IP 分段偏移量用于跟踪数据报的不同部分。
-
该字段中的信息或内容在目的端用于重组数据报
-
所有这样的片段具有相同的标识字段值,并且分段偏移指示当前片段在原始分组的上下文中的位置。
-
许多接入路由器和防火墙不执行分组重组。在正常操作中,IP 片段不会重叠,但是攻击者可以创建人为分割的数据包来误导路由器或防火墙。通常,由于数据和计算开销,这些数据包很小,对于终端系统几乎不切实际。
-
IP 碎片攻击的一个很好的例子是 Ping of Death 攻击。死亡 Ping 攻击会发送一些片段,当这些片段在终端站重新组合时,会产生一个比最大允许长度更大的数据包。
TCP 标志
-
在三次握手完成之前,不会使用 TCP 进行数据交换。这种握手使用不同的标志来影响 TCP 数据段的处理方式。
-
TCP 报头中有 6 位通常称为标志。即:
-
6 个不同的标志是 TCP 报头的一部分:紧急指针字段(URG)、确认字段(ACK)、推送功能(PSH)、重置连接(RST)、同步序列号(SYN)以及发送方完成该连接(FIN)。
-
攻击者可以滥用这些标志的正常操作或设置来发起 DoS 攻击。这会导致网络服务器或 web 服务器崩溃或挂起。
| SYN | FIN | PSH | RST | Validity|
|------|------|-------|------|---------|
| 1 |1 |0 |0 |Illegal Combination
| 1 |1 |1 |0 |Illegal Combination
| 1 |1 |0 |1 |Illegal Combination
| 1 |1 |1 |1 |Illegal Combination
- 攻击者的最终目标是编写特殊的程序或代码片段,这些程序或代码片段可以构造这些非法组合,从而导致有效的 DoS 攻击。
合成洪水
- 攻击者经常使用 3 次握手中的计时器(或缺少某些计时器)来禁用服务,甚至进入系统。
- 在三次握手的步骤 2 之后,在接收到 SYN 之后的等待时间没有限制。攻击者向 XYZ 公司的 web 服务器发起许多连接请求(几乎可以肯定是用一个假冒的 IP 地址)。
- web 服务器发送回原始源 IP 地址的 SYN+ACK 数据包(步骤 2)不会得到回复。这使得 TCP 会话在 web 服务器上处于半开状态。多个数据包导致多个 TCP 会话保持打开。
- 基于服务器的硬件限制,有限数量的 TCP 会话可以保持打开,因此,一旦达到某个限制,web 服务器就拒绝来自任何主机的进一步连接建立尝试。在可以建立新的连接之前,这些半开连接需要被完成或超时。
鳍攻击
-
在正常操作中,发送方设置 TCP FIN 标志,表示不再传输数据,连接可以关闭。
-
这是一种四向握手机制,发送方和接收方都需要在收到 FIN 数据包时发送确认。
-
在试图破坏连接的攻击中,会构造一个伪造的 FIN 数据包。该数据包还具有正确的序列号,因此目标主机会认为该数据包是有效的。这些序列号很容易预测。这一过程被称为 TCP 序列号预测,攻击者要么嗅探连接的当前序列号和确认(SEQ/ACK)号,要么通过算法预测这些号码。
连接劫持
- 一个授权用户(员工 X)通过与 web 服务器的 TCP 会话发送 HTTP 请求。
- 只有当数据包具有正确的 SEQ/ACK 号时,web 服务器才会接受来自员工 X 的数据包。如前所述,这些数字对于 web 服务器区分不同的会话并确保它仍在与员工 X 通话非常重要。想象一下,黑客开始使用正确的 seen 确认组合向 web 服务器发送数据包,假冒员工 X 的 IP 地址。web 服务器接受数据包并增加 ACK 号。
- 与此同时,员工 X 继续发送数据包,但发送的 SEQ/ACK 号不正确。由于发送了不同步的数据包,来自员工 X 的所有数据在被 web 服务器接收时都会被丢弃。攻击者使用正确的数字伪装成员工 X。这最终导致黑客劫持了连接,由此员工 X 完全被弄糊涂了,并且 web 服务器假定黑客正在发送正确的同步数据来回复。
步骤:
- 攻击者使用网络监视器检查流量,并注意到从员工 X 到 web 服务器的流量。
- web 服务器将数据返回或回显给始发站(员工 X)。
- 员工 X 确认了该数据包。
- 黑客向服务器发送一个欺骗数据包。
- 网络服务器响应黑客。破解者开始验证 SEQ/ACK 号,以再次检查是否成功。此时,破解程序从员工 X 处接管会话,这导致员工 X 的会话挂起。
- 黑客可以开始向网络服务器发送流量。
- web 服务器返回所请求的数据,用正确的 ACK 号确认交付。
- 破解者可以继续发送数据(跟踪正确的 SEQ/ACK 号),直到最终设置 FIN 标志来终止会话。
缓冲区溢出
- 缓冲区是用于存储程序代码和数据的临时数据存储区域。
- 当一个程序或进程试图在一个缓冲区中存储比原来预期的更多的数据时,就会发生缓冲区溢出。
- 缓冲区是内存中的临时存储位置(内存或缓冲区大小通常以字节为单位),可以存储固定数量的字节数据。当检索的数据超过缓冲区位置可以存储的数据时,附加信息必须进入相邻的缓冲区,导致覆盖其中保存的有效数据。
机制:
- 缓冲区溢出漏洞有不同的类型。但所有缓冲区溢出攻击的总体目标都是控制特权程序,如果可能的话,还包括主机。攻击者有两个任务来实现这个目标。首先,脏代码需要在程序的代码地址空间中可用。第二,特权程序应该跳转到代码的特定部分,这确保了正确的参数被加载到内存中。
- 第一项任务可以通过两种方式实现:将代码注入正确的地址空间,或者使用现有的代码并稍微修改某些参数。第二个任务稍微复杂一点,因为需要修改程序的控制流,使程序跳转到脏代码。
对策:
- 最重要的方法是集中精力编写正确的代码。
- 第二种方法是使程序代码的数据缓冲区(内存位置)地址空间不可执行。这种类型的地址空间使代码无法执行,代码可能会在攻击过程中渗透到程序的缓冲区中。
更多欺骗
地址解析协议欺骗
- 地址解析协议(ARP)提供了一种将已知 IP 地址解析或映射到 MAC 子层地址的机制。
- 利用 ARP 欺骗,黑客可以通过欺骗主机 b 的硬件地址来利用这种硬件地址认证机制。基本上,攻击者可以使本地网络上的任何主机或网络设备相信黑客的工作站是可信的主机。这是交换环境中常用的方法。
- 通过在网络中的所有主机和路由器上实施静态 ARP 表,可以防止 ARP 欺骗。或者,您可以实现一个 ARP 服务器,代表目标主机响应 ARP 请求。
DNS 欺骗
- DNS 欺骗是黑客使目标机器相信它想要连接的系统就是黑客的机器的方法。
- 黑客修改了一些记录,使主机的名称条目与攻击者的 IP 地址相对应。存在整个 DNS 服务器被攻击破坏的实例。
- 为了对抗 DNS 欺骗,反向查找会检测这些攻击。反向查找是一种根据名称验证 IP 地址的机制。IP 地址和名称文件通常保存在不同的服务器上,这使得泄密更加困难
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 如何给本地部署的DeepSeek投喂数据,让他更懂你
· 从 Windows Forms 到微服务的经验教训
· 李飞飞的50美金比肩DeepSeek把CEO忽悠瘸了,倒霉的却是程序员
· 超详细,DeepSeek 接入PyCharm实现AI编程!(支持本地部署DeepSeek及官方Dee
· 用 DeepSeek 给对象做个网站,她一定感动坏了
2020-09-14 TensorFlow 卷积神经网络实用指南 | iBooker·ApacheCN