通过 IP 地址,我们就可以知道判断访问对象服务器的位置,通过这个 IP 地址就可以判断访问对象服务器的位置,从而将消息发送到服务器。一般发送者发出的消息首先经过子网的集线器,转发到最近的路由器,然后根据路由位置访问下一个路由器的位置,直到重点
IP头部格式
IP头部格式
IP欺骗技术
骗呗,拐骗,诱骗!
IP 欺骗技术就是伪造某台主机的 IP 地址的技术。通过IP 地址的伪装使得某台主机能够伪装另外的一台主机,而这台主机往往具有某种特权或者被另外的主机所信任。
假设现在有一个合法用户 (1.1.1.1) 已经同服务器建立正常的连接,攻击者构造攻击的 TCP 数据,伪装自己的 IP 为 1.1.1.1,并向服务器发送一个带有 RSI 位的 TCP 数据段。服务器接收到这样的数据后,认为从 1.1.1.1 发送的连接有错误,就会清空缓冲区中建立好的连接。
这时,如果合法用户 1.1.1.1 再发送合法数据,服务器就已经没有这样的连接了,该用户就必须从新开始建立连接。攻击时,伪造大量的IP地址,向目标发送 RST 数据,使服务器不对合法用户服务。虽然IP地址欺骗攻击有着相当难度,但我们应该清醒地意识到,这种攻击非常广泛,入侵往往从这种攻击开始。 2 SYN Flooding
SYN Flooding简介
拒绝服务攻击(DDoS)从1970 年出现直到今天都依然在作祟,并给全球范围内的各大组织带来了不可估量的损失。SYN Flood是互联网上最经典的DDoS攻击方式之一,最早出现于 1999 年左右,雅虎是当时最著名的受害者。SYN Flood攻击利用了 TCP 三次握手的缺陷,能够以较小代价使目标服务器无法响应,且难以追查。 SYN flood 是一种常见的 DOS(denial of service拒绝服务)和 DDos (distributed denial of serivce 分布式拒绝服务)攻击方式。这是一种使用TCP协议缺陷,发送大量的伪造的 TCP 连接请求,使得被攻击方 CPU 或内存资源耗尽,最终导致被攻击方无法提供正常的服务。
TCP SYN Flood攻击原理
TCP SYN Flood 攻击利用的是 TCP 的三次握手(SYN -> SYN/ACK -> ACK),假设连接发起方是A,连接接受方是 B,即 B 在某个端口(Port)上监听A发出的连接请求,过程如下图所示,左边是A,右边是B。
A 首先发送 SYN(Synchronization)消息给 B,要求 B 做好接收数据的准备;B 收到后反馈 SYN-ACK(Synchronization-Acknowledgement) 消息给A,这个消息的目的有两个:
向 A 确认已做好接收数据的准备,
同时要求 A 也做好接收数据的准备,此时 B 已向 A 确认好接收状态,并等待 A 的确认,连接处于半开状态(Half-Open),顾名思义只开了一半;A 收到后再次发送 ACK (Acknowledgement) 消息给B,向 B 确认也做好了接收数据的准备,至此三次握手完成,「连接」就建立了,
大家注意到没有,最关键的一点在于双方是否都按对方的要求进入了可以接收消息的状态。而这个状态的确认主要是双方将要使用的消息序号(SquenceNum),TCP 为保证消息按发送顺序抵达接收方的上层应用,需要用消息序号来标记消息的发送先后顺序的。 TCP是「双工」(Duplex)连接,同时支持双向通信,也就是双方同时可向对方发送消息,其中 SYN 和 SYN-ACK 消息开启了A→B的单向通信通道(B 获知了 A 的消息序号);SYN-ACK 和 ACK 消息开启了B→A单向通信通道(A获知了B的消息序号)。
上面讨论的是双方在诚实守信,正常情况下的通信。
但实际情况是,网络可能不稳定会丢包,使握手消息不能抵达对方,也可能是对方故意不按规矩来,故意延迟或不发送握手确认消息。
假设 B 通过某 TCP 端口提供服务,B 在收到 A 的 SYN 消息时,积极的反馈了 SYN-ACK 消息,使连接进入半开状态,因为 B 不确定自己发给 A 的 SYN-ACK 消息或 A 反馈的 ACK 消息是否会丢在半路,所以会给每个待完成的半开连接都设一个Timer,如果超过时间还没有收到 A 的 ACK 消息,则重新发送一次 SYN-ACK 消息给A,直到重试超过一定次数时才会放弃。
B 为帮助 A 能顺利连接,需要分配内核资源维护半开连接,那么当 B 面临海量的连接 A 时,如上图所示,SYN Flood 攻击就形成了。攻击方 A 可以控制肉鸡向 B 发送大量 SYN 消息但不响应 ACK 消息,或者干脆伪造 SYN 消息中的 Source IP,使 B 反馈的 SYN-ACK 消息石沉大海,导致 B 被大量注定不能完成的半开连接占据,直到资源耗尽,停止响应正常的连接请求。 3 UDP FloodingUDP 洪泛是也是一种拒绝服务攻击,将大量的用户数据报协议(UDP)数据包发送到目标服务器,目的是压倒该设备的处理和响应能力。防火墙保护目标服务器也可能因 UDP 泛滥而耗尽,从而导致对合法流量的拒绝服务。
同样的,举个例子。Sum 和 Mike 两个人签合同。Sum 首先用 SHA 算法计算合同的摘要,然后用自己私钥将摘要加密,得到数字签名。Sum 将合同原文、签名,以及公钥三者都交给 Mike
如果 Sum 想要证明合同是 Mike 的,那么就要使用 Mike 的公钥,将这个签名解密得到摘要x,然后Mike 计算原文的sha摘要Y,随后对比x和y,如果两者相等,就认为数据没有被篡改
在这样的过程中,Mike 是不能更改 Sum 的合同,因为要修改合同不仅仅要修改原文还要修改摘要,修改摘要需要提供Mike 的私钥,私钥即 Sum 独有的密码,公钥即 Sum 公布给他人使用的密码
总之,公钥加密的数据只能私钥可以解密。私钥加密的数据只有公钥可以解密,这就是非对称加密
所以需要 Sum 过的话做过的事儿需要足够的信誉,这就引入了第三方机构和证书机制。
证书之所以会有信用,是因为证书的签发方拥有信用。所以如果 Sum 想让 Mike 承认自己的公钥,Sum 不会直接将公钥给 Mike ,而是提供由第三方机构,含有公钥的证书。如果 Mike 也信任这个机构,法律都认可,那ik,信任关系成立
如上图所示,Sum 将自己的申请提交给机构,产生证书的原文。机构用自己的私钥签名 Sum 的申请原文(先根据原文内容计算摘要,再用私钥加密),得到带有签名信息的证书。Mike 拿到带签名信息的证书,通过第三方机构的公钥进行解密,获得 Sum 证书的摘要、证书的原文。有了 Sum 证书的摘要和原文,Mike 就可以进行验签。验签通过,Mike 就可以确认 Sum 的证书的确是第三方机构签发的。
用上面这样一个机制,合同的双方都无法否认合同。这个解决方案的核心在于需要第三方信用服务机构提供信用背书。这里产生了一个最基础的信任链,如果第三方机构的信任崩溃,比如被黑客攻破,那整条信任链条也就断裂了
为了让这个信任条更加稳固,就需要环环相扣,打造更长的信任链,避免单点信任风险
上图中,由信誉最好的根证书机构提供根证书,然后根证书机构去签发二级机构的证书;二级机构去签发三级机构的证书;最后有由三级机构去签发 Sum 证书。
如果要验证 Sum 证书的合法性,就需要用三级机构证书中的公钥去解密 Sum 证书的数字签名。
如果要验证三级机构证书的合法性,就需要用二级机构的证书去解密三级机构证书的数字签名。
如果要验证二级结构证书的合法性,就需要用根证书去解密。
以上,就构成了一个相对长一些的信任链。如果其中一方想要作弊是非常困难的,除非链条中的所有机构同时联合起来,进行欺诈。