WireShark 的过滤规则
伯克利包过滤(BPF)(应用在 wireshark 的捕获过滤器上)
** 伯克利包过滤中的限定符有下面的三种:**
Type: 这种限定符表示指代的对象, 例如 IP 地址, 子网或者端口等. 常见的有 host(用来表示主机名和 IP 地址),net(用来表示子网),port(用来表示端口). 如果没有指定的话, 默认为 host
Dir: 这种限定符表示数据包传输的方向, 常见的有 src(源地址)和 dst(目的地址). 如果没有指定的话, 默认为 "src or dst". 例如 "192168.1" 就表示无论源地址或者目的地址为 192.168.1.1
的都使得这个语句为真.
Proto: 这种限定符表示与数据包匹配的协议类型, 常见的就是 ether,ip,tcp,arp 这些协议.
** 下面给出了一些常见的原语实例:**
host 192.168.1.1 当数据包的目标地址或者源地址为 192.168.1.1 时, 过滤语句为真
dst host 192.168.1.1 当数据包的目标地址为 192.168.1.1 时, 过滤语句为真.
src host 192.168.1.1 当数据包的源地址为 192.168.1.1 时, 过滤语句为真
ether host 11:22:33:44:55:56 当数据包的以太网源地址或者目的地址为 11:22:3:44:55:66 时, 过滤语句为真.
ether dst 11:22:33:44:55:66 当数据包的以太网目的地址为 11:22:33:44:55:66 过滤语句为真.
ether src 11:22:33:44:55:66 当数据包的以太网源地址为 11:22:33:44:55:66 滤语句为真.
dst net192.168.1.0/24 当数据包的 IP4/6 的目的地址的网络号为 192.168.1.0/24 时, 过滤语句为真
src net192.168.1.0/24 当数据包的 IPv4/6 的源地址的网络号为 192.168.1.0/24 时, 过滤语句为真.
net 192.168.1.0/24 当数据包的 IPv4/6 的源地址或目的地址的网络号为 192.168.1.0/24 时, 过滤语句为真
dst port 8080 当数据包是 tcp 或者 udp 数据包且目的端口号为 8080 时, 过滤语句为真.
src port 8080 当数据包是 tcp 或者 udp 数据包且源端口号为 8080 时, 过滤语句为真.
port 8080 当数据包的源端口或者目的端口为 8080 时, 过滤命令为真. 所有的 port 前面都可以加上关键字 tcp 或者 udp
** 伯克利包过滤也支持到位的操作.** 具体的语法为 proto[expr: size], 这里面的 proto 指代协议, expr 表示相对给出协议层的字节偏移量, size 表示要操作的字节数. 其中 sie 的值是可选的, 可以是 124 中的一个, 默认值为 1
地址 192.168.1.1 转换为 16 进制为 "0xc0a80101", 最后就可以写成: ip[12:4]=0xc0a80101
WireShark 中的捕获过滤器
Wireshark 中提供了两种不同的过滤器: 捕获过滤器和显示过滤器. 其中捕获过滤器是在 WireShark 捕获过程的同时进行工作的, 这意味着如果你使用了捕获过滤器, 那么 WireShark 就不会捕获不符合规则的数据包. 而显示过滤器则不同, 它是在 Wire Shark 捕获的过程后进行工作的, 这表示即使你使用了显示过滤器, Wire Shark 仍然会捕获不符合规则的数据包, 但是并不会将它们显示在数据包面板上.
捕获过滤器的配置必须要在使用 WireShark 进行捕获数据包之前进行, 配置过程的步骤如下所示:
首先依次选择菜单栏上的 "捕获"->"选项" 按钮.
在 "所选择接口的捕获过滤器" 后面的文本框中填写字符串形式的过滤器.
捕获过滤器遵循了伯克利包过滤的语法, 所以我可以使用上一节中介绍的各种命令来完成各种过滤任务. 例如下面给出了一些常见的过滤器:
tcp dst port 80, 只保留目标端口为 80 的 TCP 数据包
ip src host 192.168.1.1, 只保留源地址为 192.168.1.1 的数据包
src portrange 2000-2500, 只保留源端口在 2000-2500 之间的 UDP 和 TCP 数据包
not icmp, 保留除了 icmp 以外的数据包
WireShark 中的显示过滤器
WireShark 的显示过滤器与捕获过滤器有两点明显的不同, 一是显示过滤器可以在 WireShark 捕获数据之后再使用, 二是显示过滤器的语法与捕获过滤器语法并不相同. 在 WireShark 中有多种创建显示过滤器的方法.
使用过滤器输入框创建显示过滤器
使用过滤器表达式创建显示过滤器
我也可以使用 WireShark 过滤器输入框右侧的 "表达式" 按钮, 单击这个按钮之后就可以查看到 WireShark 过滤器表达式对话窗口.
在数据包细节面板中创建显示过滤器
在数据包详细列表处的中某一行单击, 例如我在 Source:116.211.186.209 这一行单击鼠标右键的话, 就会弹出一个菜单, 这个菜单中选中 "作为过滤器应用" 会弹出一个新的菜单.
使用 WireShark 分析链路层攻击
据统计, 目前网络安全的问题有 80% 来自于 "内部网络", 很多黑客也将攻击目标从单纯的计算机转到了网络结构和网络设计上来. 因为链路层是内部网络通信最为重要的协议, 而交换机正是这一层的典型设备, 所以我以交换机为例. 但是相比起其他网络设备来说, 交换机的防护揩施往往也是最差的, 因此也经常成为黑客攻击的目标
Mac 地址欺骗攻击
每个数据包 都包含了 源 Mac 地址(发送者的 Mac 地址) , 目标 Mac 地址(对方的 Mac 地址)
交换机是通过 cam 表里 Mac 地址和交换机端口的对应关系来传递网络数据的
如果我改变 Mac 地址和交换机端口的对应关系 那么就能达到我的目的了
Mac 地址泛洪攻击
简单而言, Mac 地址泛洪攻击就是黑客利用软件在短时间内向交换机发送大量的数据包, 导致交换机的 cam 表空间已满, 这个时候如果交换机再收到数据包就不再进行转发了, 而是退化成集线器, 进行广播, 导致网络资源缓慢甚至网络瘫痪.
Mac 地址泛洪攻击的主要特征为: 网速十分缓慢或网络瘫痪, 但是检查硬件设施没有问题.
接下来我通过 wireshark 查看数据包来分析一下 Mac 地址泛洪攻击:
打开数据包后, 我发现了大量的来历不明的数据包, 然后通过 wireshark 的统计功能我发现, 这个数据包内大量的都是单纯的 ip 数据包, 而我知道, 一个正常的网络通信中, 最多的应该是 TCP 或 UDP 数据包, 这就说明这些数据包存在问题, 很有可能是伪造的数据包. 我继续往下看.
我通过 wireshark 的会话功能发现, 这些来历不明的 ip 数据包的大小完全一致, 并且交换机的通讯不再进行转发, 而变成了广播. 这个时候我基本可以断定, 交换机遭受了 Mac 地址泛洪攻击, 而那些来历不明的数据包应该是使用同一个软件伪造而来的.
特点: 大量来历不明的数据包, 数据包大小都一样, 交换机不再进行转发而变成广播.
STP 操纵攻击
广播风暴攻击
使用 Wireshark 分析中间人攻击(MITM)
中间人攻击的相关理论
中间人攻击的目标并不是交换机, 而是终端设备(例如计算机, 手机等). 在每一台终端设备中都有一个 ARP 缓存表, 这个表中保存了一些 P 地址和 Mac 地址之间的对应关系.
通常应用程序只能通过 P 地址进行通信, 但是在内部网络中使用的交换机却不能识别 P 地址. 因此每一台终端设备在发送应用程序产生的数据包时, 必须在它里面添加上一个 Mac 地址. 而这个 Mac 地址是哪里来的呢?
ARP 协议的相关理论
数据包在局域网内部是无法使用 P 地址进行通信的, 因为局域网中的连接设备只能识别 Mac(硬件). 但是应用程序发出的数据包中往往只包含了目标的 P 地址, 此时就需要由 ARP 程序来找到数据包目的 P 地址对应的 Mac 地址.
在每一台计算机中都存在有一个 ARP 缓存表, 这个表动态地保存了一些地址和 Mac 地址的对应关系. 当计算机接收到一个数据包之后, 就会通过 ARP 程序在这个表中查找包中 P 地址所对应的表项, 然后根据这个表项在数据包中再添加 Mac 地址
如果没有在缓存表中找到对应的表项, ARP 程序就会在局域网中进行广播, 询问网络中是否存在这样一个 P 地址. 如果局域网中有计算机使用了这个 P 地址, 那么它就会回应一个包含了自己 Mac 地址的信息, 这样计算机就可以将这个信息添加到自己的 ARP 缓存中, 并将这个数据包填写好目的 Mac 地址发送输出.
使用 Wireshark 的专家系统分析中间人攻击
首先我对正常的本机进行抓包, 分析 ARP 协议. 我发现正常的 arp 协议只需要两条数据, 一条为 "请求", 一条为 "应答".(Opcode 为 1 则为请求, 为 2 则为应答)
在我知道了正常的 arp 协议的工作模式后, 我查看事先准备好的经过中间人攻击后的数据包, 进行分析.
我发现数据包充斥大量的 arp 协议数据, 但是我知道, 一个正常的数据包存在最多的应为 tcp 和 udp 协议的数据, 这个时候, 我基本可以得出结论, 终端遭受了中间人攻击, 或者是计算机感染了 arp 病毒, 或为有攻击者在进行 arp 扫描, 在实际工作环境中, 如果我的用户名密码遭遇泄露的情况, 就基本可以断定为遭受了中间人攻击.
然而这些只是我根据实际经验得出的结论, 人脑当然没有计算机转得快, 在我费尽心思像这些东西的时候, wireshark 的专家系统已经为我分析好了. wireshark 的专家系统在左下角的那个小点那里, 蓝色为会话, 黄色为警告, 红色为错误. 这里我看到了警告级别的专家系统判断. 点击小黄点, 进入专家系统, 查看警告的详细信息. 我发现同一个 ip 地址对应了两个硬件地址, 回到数据包中查看, 发现 192.168.169.2 的地址对应这同一个重复大量的 Mac 硬件地址, 我可以判断是使用软件进行了中间人攻击. 因为正常的 arp 工作只有一个请求和一个应答, 这里重复大量的 Mac 地址肯定是伪造的.
使用 WireShark 分析泪滴攻击
泪滴攻击的相关理论(TearDrop)
针对 P 协议的攻击方法, 主要有伪造 IP 地址和发送畸形数据包两种方式. 我在这一章中选择的泪滴攻击就属于发送畸形数据包这种方式, 它的设计思路巧妙地利用了 P 协议里面的缺陷, 因此成为了网络安全里面的一个经典案例.
这种攻击的实现原理是向目标主机发送异常的数据包碎片, 使得 IP 数据包碎片在重组的过程中有重合的部分, 从而导致目标系统无法对其进行重组, 进一步导致系统崩溃而停止服务的恶性攻击.
考虑到这种攻击是建立在 P 协议上, 我先来简单地了解一下 P 协议的几个重要内容, 包括 P 协议数据包的格式, 分片方式以及存活时间(TTL).
IP 分片
片偏移就是用来实现对数据包进行分片, 可是为什么数据包要分片呢, 把所有信息放在一个数据包中不是更方便? 这其实是和一个名为 MTU(最大传输单元)的值有关. 我知道数据包的最外面要添加一个以太网的帧头, 并包装成一个数据帧之后才能传输. 由于以太网传输电气方面的限制, 以太网帧的大小都有限制每个以太网帧最小也要 64Bytes4, 最大不能超过 1518bytes 去以太网帧的帧头(Mac 目的地址 MAC48bit=6Bytes+SMAC, 源 Mac 地址 48bit=6Bytes+type 域 2bytes)14Bytes 和帧尾 C 校验部分 4Bytes(这个部分有时候也被称作 FCS), 那么剩下承载上层协议的地方也就是 Data 域最大就只能有 1500Bytes, 这个值我就把它称之为 MTU. 这也就是我几乎所有设备的 MTU 值都为 1500 的原因
我分析一下这个数据包, 发现第八条和第九条数据的标识符是一样的, 这说明这两条数据是同一个数据包, 只是在传输过程中被拆开了. 然后我看一下第八条数据的分片, 发现第三位为 1, 这说明它是一个分片并且不是最后一个.(第四位表示相对于原始数据报的偏移, 单位为 8 字节)
泪滴攻击
泪滴 (teardrop) 攻击是基于数据分片传送进行的攻击手段. 在 P 报头中有一个偏移字段和一个分片标志(MF), 如果 MF 标志设置为 1, 则表明这个 P 包是一个大 P 包的片断, 其中偏移字段指出了这个片断在整个 P 包中的位置. 例如, 对一个 4200 Bytes 的 ip 包进行分片(MTU 为 1480), 则 3 个片断中偏移字段的值依次为: 01480,2960 这样接收端就可以根据这些信息成功的组装该 P 包. 而如果一个攻击者打破这种正常情况, 把偏移字段设置成不正确的值, 即可能出现重合或断开的情况, 就可能导致目标操作系统崩溃. 比如, 把上述偏移设置为 0,1000,2000
图中阴影部分的就是两个数据包有重合的地方, 目标设备在接收到这种分片之后就无法重新组合成一个数据包, 这就是所谓的泪滴攻击. 这种攻击方式在以前曾经给计算机用户带来了很大的困扰, 但是对如今的操作系统基本无效, 只是有时攻击者会将其与泛洪相结合来作为一种攻击手段.
使用 WireShark 分析 SYN Flooding 攻击
拒绝服务攻击的相关理论
服务器所面临的最大威胁当数拒绝服务攻击, 拒绝服务攻击其实是一类攻击的合称. 所有这种类型的攻击的目的都是相同的, 那就是要是使受攻击的服务器系统瘫痪或服务失效, 从而使合法用户无法得到相应的资源. 虽然服务器的功能多种多样, 但是这些差异都是表现在应用层, 无论它们使用的是什么应用程序, 但是最终都会使用到传输层的协议. 而传输层常用的协议只有 TCP 和 UDP 两种. 因此攻击者只需要研究这两个协议的缺陷, 就几乎可以实现对所有类型服务器的攻击.
目前已经出现了很多种类型的拒绝服务攻击方式, 我只挑选其中最为典型的两种 SYN flooding 攻击和 UDP flooding 攻击进行讲解. 其中 SYN flooding 攻击是针对 TCP 协议的, 它的主要目的是占用目标上所有可用的连接请求. 而 UDP flooding 攻击则是针对 UDP 协议的, 主要目的是耗尽目标所在网络的带宽
TCP 连接的建立方式
TCP 协议在进行通信之前需要先建立连接, 例如一个客户机和一个服务器之间在发送实际的数据之前, 会互相向对方发送控制数据包. 这个过程使得客户机和服务器都进入连接状态, 然后就可以进行数据交换了, 我称其为 3 次握手. 握手过程一旦完成, 客户机和服务器之间就建立好了一个连接, 因此我在描述 TCP 协议时会说这是一个面向连接的协议.
SYN Flooding 攻击
这种攻击最早出现于 1996 年, 当时大量的网站服务器都遭受到了这种 SYN flooding 攻击. 这种攻击利用了 TCP 连接的 3 次握手, 但是这个握手过程是建立在理想状态而在实际状态下当服务器收到了来自客户端发送的 SYN 请求之后, 会发出一个 SYN-ACK 回应, 是连接进入到了半开状态, 但是这个回应很有可能会因为网络问题无法达到客户端. 所以此时需要给这个半开的连接设置一个计时器, 如果计时完成了还没有收到客户端的 Ack 回应, 就会重新发送 SYN-ACK 消息, 直到超过一定次数之后才会释放连接. 服务器需要为每一个半开连接分配一定的系统资源, 所以当出现数量众多的半开连接时, 服务器就会因为资源耗尽, 进而停止对所有连接请求的响应.
使用 HPing3 发起攻击
这次我采用 Kali Linux2 中自带的 hping3 来进行一次拒绝服务攻击. 这是一款用于生成和解析 TCP/P 协议数据包的开源工具之前推出过 hping 和 hing2 两个版本, 目前最新的版本是 hping3. 利用这款工具我可以快速定制数据包的各个部分, hping3 也是一个命令式的工具, 其中的各种功能要依靠设置参数来实现. 启动 hping3 的方式就是在 Kali Linux2 hping2 中启动一个终端, 然后输入 hping3 即可:
- [email protected]: ~ hping3
- hping3>
好了, 现在我就利用刚刚介绍过的 hping3 参数来构造一次基于 TCP 协议的拒绝服务攻击. 在 Kali Linux2 中打开一个终端, 然后在终端中输入:
hping -q -n --rand-source3 -S-p 80 --flood 目标 IP
这时攻击就开始了, 在这个过程中你可以随时使用 Ctrl+C 组合键来结束这次攻击.
可以看到在短时间内生成了大量的数据包
使用 WireShark 的流量图功能分析
在 wireshark 的统计菜单中我可以找到流量图的功能, 如下图所示.
我查看一下刚刚抓取到的模拟 SYN Flooding 攻击的数据包的流量图, 发现大量的源地址都是只向目的地址发送了 SYN 请求, 而并没有做出应答, 这个时候我基本可以确定遭受了 SYN Flooding 攻击.
SYN Flooding 攻击的解决方案
丢弃第一个 SYN 数据包
反向探测
代理模式
使用 WireShark 分析 UDP Flooding 攻击
虽然与 TCP 一样位于传输层, UDP 协议却不需要建立连接就可以传输数据, 而且少了很多的控制机制, 因而传输速度高于 TCP 协议, 所以也得到了广泛的使用. 不过, UDP 协议也面临着一个和 TCP 协议一样的威胁, 那就是泛洪攻击. 不过不同于 TCP 协议占用服务器连接数的方式, UDP 协议因为不需要建立连接, 所以攻击者将目标转向了带宽, 他们构造大量体积巨大的 UDP 数据包并发往目标, 从而导致目标网络的瘫痪. 由于依赖 UDP 的应用层协议五花八门, 差异极大, 因此针对 UDP Flooding 的防护非常困难
UDP Flooding 的相关理论
UDP 是一个无连接的传输层协议, 所以在数据传输过程, 不需要建立连接和进行认证. 攻击者只需要向目标发送大量巨大的 UDP 数据包, 就会使目标所在的网络资源被耗尽. UDP Flooding 是一种传统的攻击方式, 近年来黑客经过精心设计, 又创造了新的攻击方法.
攻击者使用源 P 欺骗的方法向有漏洞的 UDP 服务器发送伪造请求, UDP 服务器不知道请求是伪造的, 于是礼貌地准备响应. 当成千上万的响应被传递给一个不知情的目标主机时, 这个攻击问题就会发生.
模拟 UDP Flooding 攻击
这次我采用 Kali Linux2 中自带的 Hping3 来进行一次拒绝服务攻击. 在第 12 章中我对这个工具的简单
用法进行了讲解. 现在我就利用刚刚介绍过的 ping3 参数来构造一次基于 UDP 协议的拒绝服务攻击, 在
Kali Linux2 中打开一个终端, 然后在终端中输入:
hping3 -q -n -a 10.0.0.1 --udp -s 53 -p 68 --flood 目标 lP -d 1000
现在攻击就开始了, 在这个过程中可以随时使用 trl+C 组合键来结束, 在攻击的同时我使用 Wireshark 捕获这个过程产生的数据包.
我发现有大量的由 1.1.1.1 发往 192.168.1.102 的数据包, 至此, 模拟 UDP Flooding 攻击完成. 接下来我使用 wireshark 对捕获到的数据包进行分析.
使用 WireShark 的绘图功能分析
现在我使用 Wireshark 中提供的绘图功能来直观地查看这些数据包对网络造成了什么影响. Wireshark 中提供的绘图功能可以用更直观的形式展示数据包的数量. 我利用菜单栏上的 "统计(statistics)"→"IO 图表( graph)" 选项来生成一个图表, 打开的 "IO 图表" 对话框.
通过 IO 图表我发现在 11-12 秒的时候, 开始出现 UDP 数据包, 并在之后的一秒内产生了大量的 UDP 数据包. 这样就导致网络设备没有能力处理其他流量, 最终导致网络瘫痪.
解决方案
基于目的 IP 地址的限流
基于目的安全区域的限流
基于会话的限流
除了这种简单粗暴的限流机制之外, 在华为公司编写的《华为防火墙技术漫谈》中还提到了另一种更有建设性的思路: 指纹学习.
指纹学习是通过分析 UDP 报文中的数据内容来判断它是否异常. 防火墙首先会对发往某个服务器的 UDP 报文进行统计, 当达到指定阈值时, 就会开始进行指纹学习. 如果这些报文携带的数据具有相同特征, 就会被学习成指纹. 后续的报文如果具有与此指纹相匹配的特征就会被当成攻击报文而丢弃.
使用 wireshark 分析缓冲区溢出漏洞
缓冲区溢出漏洞的相关理论
缓冲区溢岀是一种非常普遍, 非常危险的漏洞, 在各种操作系统, 应用软件中广泛存在. 利用缓冲区溢出进行攻击, 可以导致程序运行失败, 系统宕机, 重新启动等后果. 更为严重的是, 攻击者可以利用它执行非授权指令, 甚至可以取得系统特权, 进而执行各种操作. 考虑到目前大量的应用程序都使用了 B/S 结构, 这种结构正是使用 HTTP 协议进行通信的.
使用 wireshark 分析
在用户和服务器经过三次握手成功建立连接后, 我发现用户向服务器请求了一个特别大的数据包, 因为数据报太大了导致被截断分成了 4 个数据包分别请求. 而正常的数据包是不可能有这么长的长度的, 只有攻击者在进行缓冲区溢出攻击的时候才会有可能出现这种数据包.
接下来, 我打开这个数据包, 先查看一下这个缓冲区的大小是多少. 中间的这些字符都是用于缓冲区溢出攻击所用的大量无用字符, 一共 4061 个字符.
然后我就可以分析一下缓冲区溢出攻击的特征, 并将其特征写到入侵检测系统中, 经过查看, 我发现这个数据包的特征为:
请求方法为 GET 请求
中间的无用字符一共有 4061 个
最后以 HTTP /1.0 结尾
然后我继续向下分析, 发现服务器主动向客户端发送了请求并完成了三次握手建立连接的过程, 这当然是不正常的.
经过分析, 这种情况是由于服务器感染了 "反向木马", 才会导致服务器主动发起连接请求. 然后我追踪一下这个请求的 TCP 流, 发现了一个 PE 文件. 这样基本可以百分之百确定感染了木马.
使用 wireshark 分析 HTTPS
HTTPS (全称: Hyper Text Transfer Protocol over SecureSocket Layer), 是以安全为目标的 HTTP 通道, 在 HTTP 的基础上通过传输加密和 身份认证 保证了传输过程的安全性. HTTPS 在 HTTP 的基础下加入 SSL 层, HTTPS 的安全基础是 SSL, 因此加密的详细内容就需要 SSL. HTTPS 存在不同于 HTTP 的默认端口及一个加密 / 身份验证层(在 HTTP 与 TCP 之间). 这个系统提供了身份验证与加密通讯方法. 现在它被广泛用于互联网上安全敏感的通讯, 例如交易支付等方面.
当我抓取到 https 协议的数据包时, wireshark 中显示的是 TLS 协议, 是经过加密的, 然后我查看数据包也是一堆乱码, 什么也看不出来
然后我导入密钥, 将 TLS 进行解密, 就可以查看了
使用 wireshark 进行网络取证
使用 wireshark 分析 USB 通信
进行对 usb 抓包, 然后按下键盘查看数据包. 当我按下键盘时, usb 向电脑发送了一段 8 个字节的信息, 然后我查看 usb 标准进行对照, 可以很快地查看出我按下的是 "A" 键
在 wireshark 中添加新协议
- foo.lua
- local foo=Proto("foo","foo Protocol")
- Trans_ID=ProtoField.unit16("foo.ID","ID")
- Msg_Type=ProtoField.unit16("foo.Type","Type")
- Msg_Data=ProtoField.unit32("foo.Data","Data")
- foo.fields={Trans_ID,Msg_Type,Msg_Data}
- function foo.dissector(tvb,pinfo,tree)
- pinfo.cols.protocol="foo"
- local subtree=tree.add(foo,tvb(0))
- subtree.add(Trans_ID,tvb(0,2))
- subtree.add(Msg_Type,tvb(2,2))
- subtree.add(Msg_Data,tvb(4,4))
- end
- DissectorTable.get(""tcp.port):add(10005,foo)
来源: http://www.bubuko.com/infodetail-3474826.html