欢迎关注:1，欢迎关注本博客，你可点击右手边的【QQ邮件订阅】订阅本博客！2，本博客推出江湖救急计划，主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析，如有需要，请在江湖救急计划页面给我留言！

利用Python实现DGA检测

作者：飞鸟 发布于：2017-11-15 21:33 Wednesday 分类：网络安全

    前段时间爆发的利用永恒之蓝进行勒索及xshell等事件，各大厂家都站在不同的角度分析了相应的事件及程序，对于对逆向不了解看着的确很吃力。上段时间看到宫总及袁哥都在讲DNS对于分析这种攻击的可行性。

点击查看原图

点击查看原图

永恒之蓝和xshell事件有如下的特征：

1.  永恒之蓝中黑客预留了一个没有注册的域名，用于防护事件不受控制时，启用该域名可以抑制事件的扩大。

2. ...

阅读全文>>

标签: DNS Python DGA xshell 永恒之蓝

评论(0) 引用(0) 浏览(5291)

见缝插针-DNS泛解析是怎么被黑客玩坏的

作者：飞鸟 发布于：2017-5-5 12:10 Friday 分类：网络安全

  网络创立之初，所有的访问都是通过IP地址来实现的，因web等协议与应用的兴起，有了域名，再通过IP去访问一方面不太容易记，另一方面因负载、CDN等方面的原因，单纯使用IP地址访问会带来一些问题。因此域名产生了，通过域名访问，中间设备只认识IP，因此最终还是解析到相应的IP地址去访问。这个用来解析的协议称作DNS，主要功能为将域名解析到相应的IP地址。

   ...

阅读全文>>

标签: wireshark DNS 安全分析 泛解析 域名泛解析 DNS泛解析 黑产

评论(3) 引用(0) 浏览(6558)

某公司业务系统经ISA防火墙访问正常而经硬件防火墙访问慢故障分析解决案例

作者：易隐者 发布于：2013-1-25 10:10 Friday 分类：案例讨论

1 故障环境

      这个故障产生的环境较为简单，我们在不影响故障分析的前提下，简化分析网络环境，其故障发生的拓扑结构大致如下所示：

1.1 网络拓扑

       故障发生的拓扑结构如下所示：
 点击查看原图

1，业务服务器的IP为16.66.252.249/24，网关为16.66.252.254；

2，测试客户端的IP为16.66.180.167/24，网关为16.66.180.1；

3，防火墙与服务器相连的接口地址为16.66.252.254，防火墙与测试客户端相连接口的地址为16.66.180.1；

4，防火墙工作在纯路由模式下；

1.2 业务访问流程

1，业务服务器的业务端口为TCP 211；

2，测试客户端将数据报文经过硬件防火墙转发至业务服务器端，业务系统根据测试客户端的相关请求，返回业务应用数据报文经硬件防火墙转发给测试客户端；

2 故障现象

       经过与用户的交流和现场的测试，确定故障现象主要表现为以下几点：

1，客户端经过ISA访问业务服务器，测试连接速度非常快；

2，将ISA换成天融信硬件防火墙，硬件防火墙工作在纯路由模式下，测试发现客户端连接业务服务器的大概需要消耗20秒左右的延时；

3，用户反馈，测试过使用cisco的ASA和H3C的硬件防火墙，均有不同程度的较大的连接延时；

3 故障分析

3.1 分析过程

3.1.1 确认是否是硬件防火墙产生的延时

       经过ISA防火墙，业务系统连接测试一切正常，速度很快，但是经过硬件防火墙（TOPSEC/CISCO/H3C）之后，就产生了较大的延时，那么看起来似乎是硬件防火墙产生的延时，我们先从这个角度入手，在测试客户端与业务服务器端同时抓包做对比分析，用于确认是否是硬件防火墙产生的转发延时。

1，我们分别在服务器、客户端上安装科来网络分析系统，并开启捕获界面；
2，在测试客户端上做应用连接测试，当测试客户端弹出连接成功窗口后，分别停止客户端与服务器端的捕包界面；
3，我们通过科来网络分析系统的“TCP会话”视图分析客户端上的测试连接建立的TCP会话过程，如下图所示：
点击查看原图 
       客户端的这个数据交互过程充分说明了，在测试连接的过程中，产生了17秒左右的延时。
4，通过科来网络分析系统的“TCP会话”视图分析服务器端的应用连接建立的TCP会话交互情况，如下图所示：
 点击查看原图
       上图清晰的反应了服务器端的应用层响应是在延迟了16.34秒后才发出了；
5，对比分析客户端与服务器端的数据交互过程，我们可以得出以下两点结论：
经过硬件防火墙，应用连接的建立花费了17秒左右的时间；

这个延时不是硬件防火墙产生的，而是业务系统应用产生的。

3.1.2 分析经过ISA防火墙时的业务交互情况

       既然这个延时是业务应用本身产生的，跟硬件防火墙完全无关，那么为什么经过ISA访问的时候，连接测试一切正常呢？

       我们还是在业务服务器上捕获客户端与服务器测试应用连接建立交互的数据报文，分析一下经过ISA访问业务系统时的数据交互情况，如下图所示：
 点击查看原图
其连接正常响应时的数据交互情况大致如下所述：
1，客户端与服务器通过TCP三次握手建立连接；
2，连接建立成功后，客户端立即向服务器端发送了应用层连接请求报文，该报文长度为150字节；
3，服务器在收到这个应用请求之后，在0.006645秒内，响应了客户端的应用层连接请求，这个报文长度为74字节，应用层字段长度为16字节；
4，客户端响应了服务器端的应用层响应报文，向服务器端发送应用层字段长度为16字节的报文确认；

5，应用测试连接成功，客户端主动通过TCP四次握手过程，正常释放TCP连接；

       上述过程清晰的展示了客户端在经过ISA访问服务器时，应用连接建立的时间是非常短的，速度非常快。

3.1.3 分析经过硬件防火墙时的业务交互情况

       在确认了经过ISA防火墙的业务系统网络交互行为之后，我们再来分析一下经过硬件防火墙时，业务系统的网络交互行为是怎么样的。
1，我们首先在服务器端开启科来网络分析系统捕获服务器交互的所有数据报文；
2，在测试客户端上做业务应用连接测试，当测试客户端弹出连接成功窗口后，停止服务器端的捕包界面；
3，我们通过科来网络分析系统的“数据包”视图，查看这个过程中业务服务器的数据交互情况，具体如下图所示：
 点击查看原图
  点击查看原图
       交互过程说明：
服务器端在接收到客户端的应用层请求报文后，没有立即向客户端发送带有应用层数据的连接响应报文，而是先向DNS反向解析客户端地址对应的域名；
由于防火墙无法访问互联网，因此，硬件防火墙返回ICMP目的网络不可达差错报文；
服务器端在尝试4次DNS反向解析失败后，发送NBNS名字解析报文；

NBNS解析成功后，服务器端才向客户端发送应用层连接请求响应数据报文；

 4，通过上图的数据交互情况分析，我们可以得出以下两点结论：

服务器端在收到客户端的应用连接建立请求报文后，没有立即发送应用响应报文，而是首先做反向名字解析，解析不成功，再做NBNS解析；

17秒的延时，就是服务器4次DNS反向解析失败产生的。

3.2 分析结论

       通过上面一系列的分析，我们可以确定，导致该故障产生的核心原因是业务系统程序的处理机制异常导致的。

4 故障解决

       我们知道了经过硬件防火墙访问业务系统变慢的原因是因为业务服务器在接收到客户端的应用请求时，需要针对客户端的IP地址做一个反向名字解析，那么我们可以通过在业务服务器的hosts列表中添加客户端的IP对应的主机名，以此来避开服务器的反向DNS名字解析过程，从而解决了业务系统慢的问题。此方法已经现场测试验证有效。

阅读全文>>

标签: 疑难故障 防火墙 DNS ISA

评论(7) 引用(0) 浏览(11490)

iPhone与Multicast DNS

作者：易隐者 发布于：2012-9-21 20:58 Friday 分类：案例讨论

        前两天看到CSNA论坛上有一个求助帖，原帖连接为：http://www.csna.cn/network-analyst-49133-1-1.html，故障现象大致为：网络经常出现断网情况，抓包发现断网时有大量的DNS包，楼主认为是IPHONE或IPAD在连接公司无线网络时出现的数据包。

       我下载了其数据包文件，并选其中的一个数据包文件进行了大致的分析：
1， 在数据包视图中查看其发包频率，如下图： 

点击查看原图

在1秒的时间内 发送了15542个IPv6的多播报文，这种发包频率，足以影响相关无线路由、交换机等设备的处理性能，而接收方对多播报文的处理流程决定了过多的多播报文对网络和主机的影响，大家可参考本人个人博客中《基于UDP组播实施分片攻击的可能性》一文。

2，我们查看其详细解码： 

点击查看原图

IPV6封装UDP 5353端口的DNS请求行为，经网络搜索相关信息，确认为Multicast DNS（组播DNS）报文；

       经查阅相关资料，苹果系列产品在本地局域网内缺少DNS服务器的环境下，使用Multicast DNS，实现名字和IP地址的解析，每个主机都知道自己的名字，并且会自动响应来自多播报文中针对该名字的请求。 使用Multicast DNS的设备大致工作过程如下：

1，在“.local.”子域下，挑选所需的名字；
2，使用Multicast DNS进行名字查询，看是否有主机已经使用了这个名字；
3，如果收到来自与其他主机的名字解析响应，则在“.local.”子域下重新选择一个名字，直至确认本地局域网内无其他设备使用该名字为止。

       大家可参考苹果支持主页中关于“Multicast DNS”的相关页面：http://support.apple.com/kb/TA20999?viewlocale=en_US；

       这些都明确说明这个报文是iPhone发出的Multicast DNS报文，但是异常之处在于设备发包的频率太快了，而楼主反馈说，“不是每次连接都出现这个问题，只是偶尔会出现”，这也从侧面说明这个异常行为应该是属于iPhone本身跟“Multicast DNS”有关的进程异常导致的，可能是iPhone的BUG亦未可知。

       我在搜索相关信息的时候，竟然找到了一篇跟MAC OS相关的DNS异常问题的帖子，应该属于相关内容了，感兴趣的可以自行查看下面连接：http://blog.sina.com.cn/s/blog_539a3a320100q5dq.html

阅读全文>>

标签: 交换机 分片 解码 故障 UDP 多播 DNS iPhone Multicast DNS 多播DNS 组播DNS IPv6

评论(0) 引用(0) 浏览(18754)

第三方延时

作者：易隐者 发布于：2012-9-14 16:46 Friday 分类：网络分析

       在实际的网络应用中，有一些应用需要第三方服务器的配合或者从第三方服务器调用相关的数据，在这种业务应用交互的过程中，就存在端系统与第三方服务器交互的延时，这种延时我们称之为第三方延时。以我们最常见的互联网WEB访问过程为例，在访问真正的web应用之前，首先要向第三方的DNS服务器请求解析域名，这个解析的过程可能产生较大的延时，从而导致我们打开web页面很慢。下图为一个访问互联网域名的数据交互流图： 

点击查看原图

访问互联网域名的交互数据流图(wireshark)

       在上面的图示中，我们可以看到，客户端与第三方DNS服务器交互花费了0.046秒的时间，也就是产生了0.046秒的第三方延时。

       除了DNS解析之外，实际环境中，还有很多应用可能需要跟第三方服务存在关联，比如某些业务交互前的认证、业务数据通过数据库的存取等。需要结合具体的应用数据交互流量做具体的分析，在此不做进一步的介绍。

阅读全文>>

标签: 延时 第三方延时 DNS 认证延时 数据库延时 应用性能

评论(0) 引用(0) 浏览(15341)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1