不可不知的网络攻击

如今网络应用已深入我们生活的方方面面,小到一次支付,大到发射一枚导弹,网络安全直接关系着一个公司甚至国家的稳定。在安全面前,任何承诺都没有意义。 本文罗列了从 链路层传输层 常见的几种网络攻击方式,并对它们的攻击原理展开简要的分析。

ARP 攻击

ARP(Address Resolution Protocol) 是一种地址解析协议,目的是在局域网中,获取已知 IP 地址对应的目标 MAC 物理网卡地址。 ARP 协议工作在 7 层网络模型的第二层: 数据链路层 。这里要多解释一下,我们熟悉的 IP 地址其实是一种虚拟的网络地址,IP 地址工作在 网络层 , 但在 链路层, 数据帧是通过 MAC 地址 (设备物理地址) 进行传输的。所以在真正开始通信前,需要先将目标 IP 地址转换为 MAC 地址。

举个例子,你转学来到一个新的班级,准备把作业交给班里的数学课代表,但你不知谁是数学课代表,怎么办呢?你只需大吼一声,“谁是数学课代表” 并确保这句话被每个人听见,这样你的目标自然会来联系你。

ARP 也是如此,它需要向网络内所有终端广播询问消息,并等待结果,这种请求与回执均是以广播的方式进行的,所以给了攻击者以可乘之机。

首先说说 ARP 欺骗,ARP 欺骗常见的可分为 网关型欺骗主机型欺骗 ,不过原理都一样。一种劫持网关 另一种劫持到某台主机的数据。

流程如下:

假设当 PC1 要访问 PC4 192.168.2.101 ,本地 IP 为 192.168.1.101 子网掩码 255.255.255.0 网关 192.168.1.1 经过判断目标不是本网段 IP ,需将请求发送至网关。此时就需要向 192.168.1.x 这个网段中广播 ARP 获取网关 IP 对应的 MAC 地址。但此时和网关身处同网段的 PC2 和 PC3 也可以收到这条 ARP 消息,若此时 PC2 冒称自己为网关,且抢先一步做出应答,则以后 PC1 经过网关的信息均会被 PC2 劫持。

还有一种 ARP 攻击会导致部分或全部终端网络瘫痪,他利用了交换机每当收到新的 ARP 请求时都会刷新请求发起者信息的功能, PC2 不断的发送 ARP 请求,导致交换器疲于应对建立新的 IP -> MAC 映射关系,导致崩溃。这种攻击可以是针对全网也可以是只针对某台终端,只要在请求中修改对应的 IP 与 MAC 地址就行。

由于 ARP 协议工作在链路层,是一种非常底层的协议,原则上目前没有什么方法可以完全杜绝 ARP 攻击,这种攻击主要是针对局域网,在各高校尤其是软件学院是重灾区(\捂脸) 但通过合理的配置可以提高网络的 “抵抗力”。

ARP 攻击的防御:

  1. 限制交换机 ARP 映射表的最大学习空间,防止缓存溢出。
  2. 指定交换机 ARP 映射表更新阈值,只处理超出阈值的映射,避免频繁更新。
  3. 只记录交换机自己发出的映射,不记录终端主动请求的映射
  4. 必杀!在交换机做静态映射,定死 ARP 表,让 IP 和 MAC 永久性关联,此招效果拔群,但就是网管会有点忙。

    DHCP 攻击

    DHCP (Dynamic Host Configuration Protocol) 动态主机配置协议,它的作用是为每一台新接入网络的终端分配 IP 地址,当然如果在上面用过必杀的话 DHCP 也就没意义了。

    一次 DHCP 请求简单来说是这样的:首先终端发出 DHCP 广播,为什么是广播呢?因为在网络中可能有多台 DHCP 服务器有,当 DHCP 服务器收到请求报文后,会给请求者一个回执,此时就确定了哪一个 DHCP 服务器来完成这次分配任务,然后 终端再次广播 IP 请求报文(广播为的是让另外的 DHCP 服务器知道此 IP 已经用过了),服务器收到后,在发送确认消息 ack。

    基于 DHCP 的攻击有很多种,常见的 2 种是 地址耗尽攻击仿冒者攻击

    地址耗尽攻击顾名思义,攻击者要达到的效果是将 DHCP 服务器中可用的 IP 池消耗完,怎么做呢?其实很简单 终端不断的假冒 MAC 地址发送 DHCP 申请,直至 IP 消耗殆尽。仿冒者攻击与 ARP 欺骗类似,由于 DHCP 是一次广播,所有终端是都可以接受到的。所以可能会有攻击者冒名顶替 DHCP 服务器。

DHCP 攻击的防御:

针对地址耗尽攻击,可以限制交换机某个端口在一段时间内分配 IP 的峰值,避免某台终端使用一个端口大量申请 IP 的情况。

针对仿冒者攻击,可以在交换机层面指定静态的 DHCP 服务器,这样,即使有攻击者仿冒,经过网络设备的过滤,错误信息会被过滤掉。

ICMP 攻击

ICMP(Internet Control Message Protocol)控制报文协议,他是 IP 协议的一个子协议,工作在网络层 (TCP、UDP 等工作在传输层) 我们最常用的 Ping 命令就是使用 ICMP 协议,所以也成为 死亡之 Ping

此协议设计的初衷是为了检测网络,但如果稍加改造就可以变成一种攻击行为:

ping -l 65500 -t  192.168.1.1

-l size:发送 size 指定大小的到目标主机的数据包。

在默认的情况下 ping 发送的数据包大小为32 字节,最大值 65500 字节。当一次发送的数据包大于或等于 65500 字节时,将可能导致接收方计算机宕机。所以微软限制了这一数值。这个 -l 参数配合 -t 参数后危害非常强大。

ICMP 攻击的防御:

ICMP 洪水攻击可以说是最野蛮最没技术含量的一种,就是依仗巨大的网络流量,硬生生将网络设备 CPU 拖垮。

1.对于某种有特殊特征的 ICMP 攻击请求,可以干脆将其关闭之。 2.启用 Ping 快回功能,Ping 请求不再将数据包全额上传 CPU ,但具体实现要看硬件设备支持情况。 3.限制网络设备 CPU 对 ICMP 报文的处理优先级。

TCP/UDP 攻击系列:

TCP (Transmission Control Protocol)传输控制协议,是一种常用的传输层协议,针对他的攻击也是最常见的。 TCP 是可靠的传输层的协议,但由于其下层 IP 协议仅仅对数据做 最大努力交付(best effort) 并不保证数据的完整性,所以实现 TCP 需要在终端双方都建立会话,成本较高,很多攻击都是利用了这一特质。

为保证信道的利用率,TCP 采用一种叫 “窗口滑动” 的技术来提高数据的传输的效率,对于这种技术,这里不做详细的解释,简单来讲可以理解为对 TCP 中每一个数据包进行编号,在窗口内的所有数据包是可以一次性全部发出去,这里不考虑时序,发送后的数据仍然留在缓冲区中,直到对方确认一段编号连续的数据段,这时释放那段数据,窗口右移。

系列之 会话洪水:

在 TCP 建立会话的 3 次握手中,攻击者可以发出大量的用篡改后 IP 来做伪装的 TCP 握手请求,这些 IP 都是不存在的,这样,在应用层,就会出现大量处在半开等待(SYN_RECV) 状态的会话,直至资源耗尽。

由于这种攻击与正常的会话请求完全一样,是无法从特征上予以过滤的,目前可以做到防范手段主要有两种

1.缩短半开连接的持续时间,在网络高峰期慎用,高峰期网络随时可能拥塞,数值调整不当会造成正常的连接无法建立,乃至丢失。 2.增大半开连接队列大小,打电话给老板再上几条内存吧。

系列之 RST 攻击:

这种攻击不是发生在会话的建立期间,而是结束期间,他的攻击策略是这样的:

终端 A 与 服务器 B 已经建立的 TCP 连接,这时,坏蛋 C 伪造 A ,给 B 发了一个中断 TCP 的信号。这时候 B 可能会觉得 A 好奇怪呀,都已经说 bye bye 了怎么还在滔滔不绝?

这种信陵君窃符救赵的故事发生是有一个前提条件的,就是可以拿得到 “符”。

众所周知,一个 TCP 会话,也就是编程时使用的 socket 是由 目标 IP源 IP目标端口源端口 这 4 个信息组成的元组。其中 目标 IP源 IP目标端口 都比较容易获得,唯独 源端口 似乎很难获取。

很难并不意味着不可能,客户端的端口一般都在 3w 以上,16 位的端口号最大也就 65535 个端口,更何况如果攻击者和被害者同处一室(在一个网段)更可以使用端口扫描等黑客工具直接获取到 源端口

还有一个门槛就是如果伪造的 TCP 包不在滑动窗口内,是会被无视的,不过这也不难,因为 IP 头 + TCP 头一共也就 40 字节,这个数据报的队列是可以预估的,常言道,大力出奇迹,暴力破解可以解决。

虽然有点小困难,但效果是非常舒适的。

系列之 泪滴(teardrop)攻击:

泪滴攻击也成为分片报文洪水,会造成终端的缓冲区溢出, CPU 资源耗尽。其实此类攻击不仅对 TCP 有效,对 UDP 同样有效,因为它攻击的是网络层,其利用的原理是,当 TCP/UDP 要发送一个大的报文时,为了提高信道的利用率,通常会将其拆分为多个小的 IP 数据报,但不管是拆分还是合并,都需要耗费 CPU 资源,这就给了攻击者以可乘之机。

泪滴攻击大体分为两种,一种是发送大量的小报文,一般来讲 IP 数据报头部 20 个字节,可容纳 65515 字节,如果攻击者故意将其拆分为极小体积数量极多的分片,这种数据报都是恶意的。

还有一种就更缺德的,攻击者故意不发送一个大报文中的最后一个小分片,造成终端一直在等待,这样缓冲区中前面接受到的数据会一直保存在缓冲区中。也称 Rose 攻击。 这种故意扣留分片的方式也可以用在 IGMP 协议上, 称为 fawx 攻击。

泪滴(teardrop) 攻击的防御:

一般来说,正常的网络中出现大量分包的情况是比较小的。如果出现,大概率是被攻击了,这时需要对分片进行限速,避免将 CPU 资源耗尽。

系列之 Land 攻击:

Land 攻击也是利用了 TCP 建立会话需要三次握手这一特质进行的,而且相比一般性洪水攻击来说,它具有 “药量小” 、 “见效快" 等优质特点。

服药过程如下:

首先攻击者构造一个很特别的 TCP 会话请求 SYN , 在这个报文中,目标地址与源地址是一样的,端口也一样。这样,当目标终端接收到这个报文后,会向自己发回一个回执确认请求 SYN + ACK ,收到后,有的终端比较傻,会以为这个是另一个会话请求报文,进而创建一个空连接,然后继续向自己发送确认请求,如此循环直至油尽灯枯。

land 攻击的防御:

这种攻击对付早期的操作系统是很有效的,现在不行了,现在的操作系统可以轻易分辨出这种恶意循环。但在某些老式的网络设备上,还是有一些生存空间的。

DNS 劫持:

2010 年 1 月 12 日上午 7 点钟,baidu 公司曾遭到黑客攻击,导致网页长时间无法正常访问。其主要用的方式就是 DNS 劫持。

说到 DNS (Domain Name Service) 其功能是将域名换回为真实 IP ,但 DNS 劫持并不一定是黑客行为,比如国内某通公司的宽带,如果你访问一个不存在的域名,可能会被跳转到一个广告页面... ...

先来说说局域网的 DNS 劫持,在局域网中,尤其是一些大型公司的内网,一般有自己的 DNS 服务器,这种情况虽然符合 “劫持” 这一特性,却并不能算是恶意劫持。但不包括以下这种情况:

1.通过 ARP 伪造虚假 DNS 服务器:

DNS 查询一般是基于 UDP 的,因为报文较小,但也有基于 TCP 的特殊情况这里不做讨论 ,无论是 TCP 还是 UDP , DNS 服务器都使用 IP 地址在各终端标定。既然使用了 IP 在局域网里就逃不过 ARP 欺骗,只要攻击者抢先在 DNS 服务器 发送消息之前,先发送一条伪造的 MAC 确认消息,那被攻击者就会认为攻击者是它的 DNS 服务器了。

一个避免的方法是将局域网内的 DNS 服务器 IP 做成 静态 ARP 映射。

2.通过网络设备进行 DNS 劫持:

局域网中,终端使用网络一般会经过多层 NAT 映射,每一层转发都需要路由器完成,但局域网中的路由设备抗攻击强度远远不及主干网,甚至有些路由器自身就有固件漏洞,或者密码比较简单等问题,攻击者也可以从路由设备开刀,一旦攻破,就可以控制任何报文的转发,当然也可以劫持 DNS 。

在广域网中,同样存在 DNS 被劫持的风险,一般分为以下两种:

1.第三方代理劫持 DNS 服务器:

在这种情况下,代理服务器承接了终端的所有网络报文,当然也包括 DNS 查询。使用代理服务器并不会使你加入任何新的网络,它仅是对网络报文进行转发,所以终端无法甄别这个过程是否被篡改过, 通常使用值得信赖的 VPN 可以避免这种情况。

2. 来自 ISP 的 DNS 劫持:

DNS 是一个庞大服务,是全球性的,目前根节点只有 937 个 (截止到 2018 年 9 月 4 日),但大部分分布在美洲、欧洲等地。亚洲如果直接使用 DNS 根节点会有非常长的延迟,所以各大 ISP 服务商都会分担 DNS 查询的工作,并将查询到的结果进行一段时间的缓存,保证当地 DNS 查询的速度。

但又如何保证这些 “备份数据” 的准确性呢?对于 ISP 来说,提供健壮的网络服务是其本职工作,但偶尔也有开小差的时候,针对 DNS 服务器的攻击主要有两种:

首先是 DNS 洪水攻击,它和上面提到的其他洪水攻击原理差不多,通过操作互联网上的大量 “肉机”(已经被黑客控制的终端) 伪造大量 DNS 查询请求直至 DNS 服务器资源耗尽,这种攻击针对 ISP 的某一层子 DNS 节点很有效。(因为 DNS 根服务器吞吐量非常大,很难对其造成影响,先找弱鸡下手)

还有一种是 DNS 反弹式攻击,它主要攻击 DNS 子节点到根节点之间的网络。首先攻击者操作 “肉机” 伪造大量不存在的多级域如(a.b.c.d.e.f.baidu.com),这会导致子 DNS 节点不断的向根节点发出查询,直至它们之间的网络被占满。

DNS 攻击的防御:

DNS 主要是服务端的防范,作为终端用户而言,能做出的努力有限。

  1. 检查本地 hosts 文件。
  2. 不要使用来历不明的 DNS 服务器地址,如果内网没有 DNS 服务器的话,建议使用中国联通的 114.114.114.114 和 google 的 8.8.8.8
  3. 如果你是网管,不要在开着路由器管理 Web 界面的浏览器在去浏览其他网站,当心被 csrf !

最后 May The World Peace

留言:

称呼:*

邮件:

网站:

内容: