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