新氧网站头图怎么做的wordpress文章有模板下载

当前位置： 首页 > news >正文

新氧网站头图怎么做的,wordpress文章有模板下载,产品包装设计网站,如何让做网站1. 协议 1.1. IKE/IPSec 1.1.1. 因特网密钥交换协议#xff08;Internet Key Exchange,IKE#xff09;用于执行IPSec认证和密钥交换 1.1.1.1. 通常以后台守护进程的方式实现#xff0c;使用预共享密钥或X.509证书来认证对端并创建一个安全会话 1.1.2. IKEv1与IKEv2 1.1.2.1… 1. 协议 1.1. IKE/IPSec 1.1.1. 因特网密钥交换协议Internet Key Exchange,IKE用于执行IPSec认证和密钥交换 1.1.1.1. 通常以后台守护进程的方式实现使用预共享密钥或X.509证书来认证对端并创建一个安全会话 1.1.2. IKEv1与IKEv2 1.1.2.1. IKEv1过于复杂性能也不太好 1.1.2.2. 相比于IKEv1, IKEv2更为灵活和可靠 1.1.2.3. 强烈建议使用IKEv2 1.1.3. IPSec不是单一的协议而是一系列协议的集合 1.1.4. IKE可以被认为是IPSec的控制平面它处理会话协商和认证使用协商的结果为端点配置会话密钥和加密算法 1.1.5. 由于核心的IPSec协议内嵌在IP协议栈中因此IPSec通常在内核中实现 1.1.5.1. 密钥交换是一种相对复杂的机制IKE以用户态的守护进程形式实现 1.1.5.2. 内核维护的状态定义了IPSec安全关联流量选择器则定义了对哪些流量应用IPSec策略
1.2. 身份认证凭证 1.2.1. IKEv2支持预共享密钥和X.509证书 1.2.2. 还支持可扩展身份验证协议EAP​ 1.2.3. 支持EAP意味着IKEv2通过代理可以支持大量其他的身份验证方法包括多因素认证 1.2.4. X.509证书是IKE的首选认证方法 1.2.4.1. X.509证书不是为人工使用准备的它们用于设备。证书不但携带信任证明而且提供了带有签名的元数据以及一种利用其身份对数据进行强加密的方法 1.2.5. IKEv2支持预共享密钥但我们强烈反对使用它们其带来了大量的密钥生成和分发问题但最重要的是需要人为记忆这些预共享密钥
1.3. IKE SA_INIT和AUTH 1.3.1. 所有的IKEv2密钥交换都从一对名为IKE_SA_INIT的数据包交换开始这个初始交换决定密码套件的选择和Diffie-Hellman交换一样​ 1.4. 密码套件选择 1.4.1. IPSec的密码选择比TLS稍微复杂一些 1.4.1.1. IPSec是在内核中实现的相较于以软件包的形式实现其对密码支持的要求更严苛 1.4.2. RFC 6379提出了被称为套件B的密码套件该标准是由美国国家安全局撰写的它是一个被广泛接受的IPSec密码套件标准 1.4.3. 不是所有的IPSec实现都支持椭圆曲线算法而套件B强制要求椭圆曲线加密 1.4.4. 对于主流椭圆曲线算法的安全性的担忧许多人认为国家政府相关人员的干预可能会影响其安全性
1.5. IPSec安全关联 1.5.1. 4个不同状态幼年larval、成熟mature、垂死dying和死亡dead​ 1.6. IPSec隧道模式 1.6.1. 隧道模式是目前广泛部署的模式当IPSec在隧道模式下运行时SA包含了远程端点的信息用于封装IP数据包并且在路由到端点的过程中保护它 1.6.2. 经常用于VPN在需要与远程网络建立安全连接的情况下管理员能够采用隧道方式将流向该网络的流量通过安全通道进行传输 1.6.3. 既然是隧道模式那就意味着流量在某个时间点会变得不受保护 1.6.4. 发送者与中间网络之间传输的安全是可以确保的但在此之后将无法保证安全性 1.6.4.1. 认为隧道模式其实与零信任体系结构相矛盾 1.7. IPSec传输模式 1.7.1. 传输模式提供了几乎相同的安全保证只是减去了隧道的部分 1.7.2. 它没有封装整个IP数据包而是封装了IP有效负载这对于主机到主机的直接IP通信非常有用 1.7.3. 传输模式并不是与网络中间设备建立一个安全联盟而是与流量的目的端点直接建立安全联盟确保端到端应用安全这个属性使得传输模式能够很好地适用于零信任网络 1.7.4. 成熟的零信任数据中心架构应该选择IPSec的传输模式
1.8. 将IKE/IPSec用于设备认证 1.8.1. 由于IPSec直接在IP上实现因此它可以处理大多数应用程序流量而不仅仅是TCP和UDP 2. 双向认证TLS 2.1. 传输层安全TLS通常会沿用其前身SSL的称谓是用来保护Web流量的常见协议 2.1.1. 它是一种成熟的、易于理解的协议被广泛地部署和支持并且已经获得一些敏感业务的信任 2.1.2. HTTPS中的S指代的就是TLSSSL 2.1.3. 面向一般公众的服务可以接受客户端身份认证的缺失但其他任何用例都不可接受这种妥协 2.1.4. 双向身份认证是遵循零信任模型安全协议的必要条件TLS也不例外
2.2. 在TLS密码套件中有4个主要的组件 2.2.1. 密钥交换 2.2.2. 身份验证 2.2.3. 块加密 2.2.4. 消息完整性
2.3. 系统的整体安全性取决于较弱的客户端能提供的最强密码套件 2.3.1. 在TLS握手中客户端按优先顺序显示其支持的密码套件列表如果客户端和服务端支持的密码套件有重合那么服务器会从这个列表中选择一个密码套件否则会话建立就可能失败 2.3.2. 建议服务器只支持最合理的密码套件
2.4. 协商是一个弱点 2.4.1. 码套件协商被认为是现代加密协议中的反模式 2.4.2. 较新的协议和框架如Noise旨在消除协议协商
2.5. 密钥交换 2.5.1. TLS的密钥交换描述了在不安全的通道上安全地生成加密密钥的过程 2.5.2. 它们使用数学函数来协商密钥而不用明文进行传输在大多数情况下是这样​ 2.5.3. TLS支持3个主流的密钥交换/协商协议按照优先顺序排列它们是ECDHE、DHE和RSA 2.5.4. ECDHE基于Diffie-Hellman交换使用椭圆曲线来协商一个密钥 2.5.4.1. 椭圆曲线密码具备高强度、高效率的特点它建立在一个难以解决的数学问题的基础之上 2.5.4.2. 从安全性和性能上考虑它是理想的选择 2.5.5. DHE同样基于Diffie-Hellman交换但它使用模运算而不是椭圆曲线来协商一个密钥 2.5.6. RSA密钥交换基于非对称运算来验证数字签名的身份如X.509证书​它使用服务器的公钥来加密传输需要的共享密钥 2.5.7. 当今主流的公钥密码学都基于这样一种假设即分解较大数字的计算开销非常大 2.5.7.1. 经典的计算必须依赖于一种被称为普通数域筛选法的技术来推导出大数因子这是一种相对低效的算法 2.5.7.2. Shor算法是一种比一般数域筛选更有效的量子算法只要有足够强大的量子计算机它就可以被用来快速破解大多数非对称密钥交换协议
2.6. 完美的前向保密性 2.6.1. PFS完美的前向安全性是一种加密属性基于PFS私钥的披露不会导致之前协商的会话的泄露 2.6.2. 可以确保窃听者不能记录会话数据以供之后解密 2.6.3. RSA密钥交换不支持PFS 2.6.3.1. 因为我们是直接使用私钥加密和传输会话密钥的 2.6.4. 必须使用DHE或ECDHE以获得完美的前向安全性 2.6.5. 精心设计服务器端密码套件在可用的情况下先选择DHE协商必要时返回到ECDHE协商
2.7. 认证 2.7.1. 有3种常见的认证方法RSA、DSA和ECDSA 2.7.2. RSA认证是较常见的它在超过99%的基于Web的TLS资源中使用 2.7.3. DSA认证已不再推荐使用 2.7.4. EDCSA是DSA的新表兄它使用椭圆曲线来提供公/私钥对
2.8. 职责分离 2.8.1. 需要保护的资源是设备因此将加密功能独立于工作负载本身非常有意义 2.8.2. 要确保所有这些应用程序都确实通过正确的方式使用TLS在已知漏洞上保持最新状态是非常困难的 2.8.3. 将TLS的配置职责转移到控制平面是非常有用的 2.8.3.1. 到服务的连接被TLS守护进程代理然后本地转发给应用程序 2.8.3.2. TLS守护进程配置了系统证书、信任权限和节点信息 2.8.3.3. 通过这种方式可以确保所有的软件都接受设备认证和TLS的安全保护而不管软件是否支持TLS库 2.8.4. 零信任网络对业务流采用了“白名单”机制所以可通过限制到已知TLS端点的业务流白名单确保应用程序业务流量受到保护
2.9. 块加密 2.9.1. TLS握手主要有两个目的认证和会话密钥的创建 2.9.2. 当无须考虑身份或认证问题时使用对称加密就可以满足所需的安全强度 2.9.3. 对称加密使用一个单独的密钥而不是公/私钥对并且与非对称加密相比其计算成本要低得多 2.9.4. 业界一致建议采用AES 2.9.4.1. 它设计完美并且没有专利保护可以在硬件中广泛实现并且已在软件中普遍采用 2.9.4.2. 它非常高效经过严格的审查/检查并且保持一致性
2.10. ⑩消息完整性 2.10.1. 消息的完整性即使不是必需的也是一个重要属性 2.10.2. 完整性算法的选择仅限于MD5和SHA系列的散列算法 2.10.2.1. 前者已经被破解 2.10.2.2. 这使得SHA系列成为TLS确保消息完整性的唯一合理选择 2.10.2.3. 不断增长的计算能力导致SHA-1脆弱并易受攻击 2.10.2.4. 建议选择可以合理部署的最强SHA散列算法
2.11. ⑾基于双向TLS进行设备认证 2.11.1. TLS是依赖于协议的 2.11.1.1. 它通常基于TCP协议实现虽然基于UDP的协议变种DTLS也是可用的 2.11.2. 只要代理和保护的上游节点被一个计算机网络分离开这种运行模式就不适用于零信任网络 2.11.3. 在零信任网络中基于TLS协议实现的通信代理必须和应用程序部署在一个逻辑主机上 2.11.4. 在用TLS保护数据中心零信任网络时应用需要自动化配置以便使用外部的TLS通信它不像IPSec协议那样是“免费”加密 2.11.5. TLS仍然是目前保护面向客户的零信任网络的较好选择它在软件和传输网络中都得到了广泛的支持并且其运作模式直接而可信赖 2.11.6. 大部分Web浏览器本身就支持双向TLS认证这意味着资源可以直接基于零信任原则进行保护而不需要专门的客户端软件
3. 过滤 3.1. 过滤是数据包被网络上的系统接受或拒绝的过程 3.2. 防火墙确实提供了过滤作用但它们也可以提供其他服务 3.2.1. 网络地址转换NAT 3.2.2. 流量控制 3.2.3. VPN隧道服务
3.3. 传统意义上过滤功能可以由很多系统提供比如路由器或交换机 3.4. 过滤是一种简单的服务在网络系统的很多地方都可以应用它 3.5. 许多零信任概念都集中在高级加密和认证系统上这是因为网络安全的这些方面没有得到应有的设计和考虑 3.5.1. 不应该低估网络过滤的重要性它仍然是零信任架构的关键组成部分 4. 主机过滤 4.1. 过滤主机上的流量 4.1.1. 主机过滤让网络端点成为其自身安全的积极参与者其目标是确保每台主机都被配置为过滤自己的网络流量 4.2. 防火墙利用专用集成电路Application-Specific Integrated Circuit, ASIC来有效地处理流经设备的数据包 4.3. 软件防火墙比硬件防火墙要灵活很多它们提供了一组丰富的服务 4.3.1. 比如根据日期和任意的数据偏移字段来定义策略 4.3.2. Linux:IPtable 4.3.3. BSD系统Berkley包过滤BPF 4.3.4. macOS应用程序防火墙和基于命令行的主机防火墙 4.3.5. Windows:Windows防火墙服务
4.4. 零信任网络假设网络中始终充满威胁需要在每个可能的位置过滤网络流量通常使用主机防火墙实现 4.5. 通过主机防火墙可以过滤不良网络流量来减小主机的攻击面 4.6. 主机过滤非常容易着手实施配置管理系统很好地支持了主机防火墙的管理 4.7. 在安全设计中隔离的好处主机过滤可以从中受益 4.8. 关于主机过滤的问题是其部署点在网络中的位置太“深”了会造成大量的额外成本 4.8.1. 增加了拒绝服务DoS攻击的可能性使内部网络充斥大量的无用流量压垮了相对脆弱的软件防火墙 5. 双向过滤 5.1. 同时过滤主机的出入流量 5.1.1. 一种在接收和发送数据包时同时应用的过滤策略 5.2. 出站入站的反面这个术语用来描述离开主机的网络流这种类型的过滤通常用于管理从私有网络到公共网络的通信它很少在私有网络内部使用 5.2.1. 入站过滤更容易理解因为在构建防火墙规则时可以枚举出所有的监听服务出站过滤则需要更多的记录来得知主机如何进行通信 5.2.2. 通常认为入站过滤能够阻止网络中的不良通信 5.2.3. 出站过滤需要了解每一个预期的流量这在传统网络中不常见
5.3. 即使在系统中出现了关键的错误配置一个部署了全面的双向过滤机制的网络也会受到保护 5.4. 双向过滤不是预防疾病而是保护被错误配置的系统能够免受错误配置带来的潜在影响 5.5. 在系统中构建双向过滤并没有那么困难可以通过程序化实现对通信业务流的捕获捕捉这些流的较好方法是定义细粒度的入站规则 5.6. 出站过滤机制最好与运行在系统上的应用程序隔离建议在虚拟化或容器化环境的外层实现过滤以便拥有健壮的过滤机制 5.7. 当网络流数据库与运行系统隔离时双向过滤是较有效的 5.8. Calico项目是动态调度工作负载的虚拟网络系统 6. 中间过滤 6.1. 通过两个主机间的设备过滤流量 6.1.1. 指除了发送方或接收方之外的设备在零信任网络中可以并且应该参与到流量过滤中 6.2. 边界过滤在零信任网络中可以发挥作用并且在网络结构中的中间设备也可以发挥作用 6.3. 高吞吐量的过滤流量通常是来自互联网入口的流量在理想情况下我们希望尽快过滤流量以减少延迟过滤的影响和成本 6.4. UPnP被认为是有害的 6.4.1. 从主机策略衍生出的边界策略不应该与UPnP混合使用 6.4.2. UPnP是一种用于重新配置用户防火墙的技术 6.4.3. UPnP受到诟病是因为网络上的任何应用程序都可以重新配置边界在零信任模型中主机策略和边界创建的例外规则之间应该存在信任链
6.5. 零信任网络不会抛弃所有的边界概念相反它们鼓励管理员从主机开始向外扩展边界设备最终会以某种方式发挥作用而值得关注的是其在缓解拒绝服务攻击上的应用 6.6. 使用主机策略数据库来动态地规划网络结构本身 6.7. 软件定义网络Software-Defined Network,SDN 6.7.1. 它不会盲目地将数据包路由到目的地址而是根据预期和允许的流量积极管理交换和路由策略 6.7.2. 将潜在的恶意流量挡在主机之外减少了攻击面 6.7.3. 主机上基于软件的防火墙在网络中增加了额外的防御层 6.7.4. 想象一个SDN控制器它只根据强身份认证和授权过程的结果实现流量传输希望访问网络资源的客户端可以向控制平面发出信号提供网络访问请求以及相应的凭证请求成功授权之后网络过滤或转发规则就会被下发并且执行但这些规则仅针对特定的已授权业务流