端系统对RST报文的过滤
作者：易隐者 发布于：2012-10-8 17:00 Monday 分类：网络分析
前段时间在分析网上一个兄弟传给我的报文时，发现了几个有意思的现象，我觉得值得分析讨论，我们首先来看一个服务器与客户端交互的会话：
在这个交互的过程中，我们可以看到一个比较奇怪的现象，那就是客户端10.16.137.56在收到来自服务器的FIN报文之后，紧接着向服务器端发送RST报文，但是服务器给其回应了一个ICMP主机管理性禁止差错报文，并且不断尝试向服务器发送FIN报文。
我们来看一下服务器给客户端回应的ICMP主机管理性禁止差错报文的解码：
Type 3，Code 10——主机管理性禁止差错，其封装的原始报文报头信息显示，该ICMP差错报文正是由客户端发往服务器端的RST报文引起的。下图为客户端发往服务器端的RST报文解码：
另外，我们注意到，服务器发送给客户端的ICMP差错报文的TTL值为48，而服务器端发送给客户端的FIN报文报头中的TTL值也是48，如下图所示：
这从侧面说明这个ICMP差错报文的确是服务器端系统发送的，而不是中间设备发出的。
那么为什么服务器端系统会过滤掉客户端的RST报文呢？
想想TCP会话劫持和TCP RST攻击，大家就能够体会，服务器管理员为什么这么做了。
TCP会话劫持的实施者经常会扮演对端的身份分别向客户端或服务器端发送RST报文，以达到干扰客户端与服务器端正常交互的目的。有些服务器的管理员可能遇到过这种TCP会话劫持的攻击，因此在服务器端系统上利用相关工具设置了过滤RST报文的策略，当服务器收到RST报文时，直接忽略掉，因此服务器端系统的传输层并不会收到这个RST报文。
其交互过程大致如下图所示：
过滤RST报文可能带来的影响
服务器传输层无法收到客户端的RST 报文，只能在多次尝试重传FIN报文直至超时，然后主动向客户端发送RST报文。如此带来的影响就是执行过滤策略的端系统无法正常处理来自于TCP连接对端的异常释放行为（RST），这将导致端系统的TCP连接释放需要更长的时间，在有大量对端通过RST报文异常释放TCP连接的场景下，可能会对性能产生一定的影响。
标签: TCP RST icmp差错 会话劫持 TTL FIN type 3 code 10 端系统
ACK flood攻击的影响
作者：易隐者 发布于：2012-10-8 10:14 Monday 分类：网络安全
我们在分析ACK flood攻击对端系统和中间系统的影响之前，首先需要了解端系统和中间系统一般情况下是如何处理其收到的ACK报文。
端系统对ACK flood报文的处理
端系统在收到一个ACK报文时，如果目的端口未开放，那么端系统会直接向源IP发送RST报文，其交互过程大致如下图所示：
如果端系统的相关端口是对外开放的，那么其在收到ACK报文时，首先会检查这个ACK报文是否属于TCP连接表中的一个已有连接（这个过程会对端系统主机CPU资源造成一定的消耗），如果是的话，则正常处理，如果不属于任何一个已有连接，那么端系统会向源IP发送RST报文，交互过程如下图所示：
根据上面两个过程的分析，我们可推论ACK flood攻击对端系统性能的影响并不会非常大，至少跟SYN flood（端系统需要给每个SYN报文分配相应连接表空间，会消耗端系统内存资源）攻击相比，其攻击效果似乎难上台面。
中间系统对ACK flood报文的处理
路由器和防火墙的工作机制决定了路由器和防火墙在处理ACK报文的时候是完全不同的，我们分别将路由器与防火墙对ACK flood攻击的处理过程做简单描述。
路由器是网络层的设备，其主要功能是选路和转发，其选路的依据大部分都是基于网络层信息（目的IP、源IP等），因此路由器在处理ACK报文的时候，其并不关心它是不是ACK报文，它主要关心其目的地址，需要根据其目的地址来进行选路，如果ACK flood攻击的目的主机都是固定的，那么路由器其实只需要在收到第一个ACK flood攻击报文时，调用CPU资源实现选路和转发，后续的ACK flood攻击报文由于目的主机是固定的，其甚至不需要调用CPU资源，直接使用快速转发表即可实现对ACK flood报文的转发，路由器对ACK报文的处理过程大致如下：
防火墙对ACK报文的处理主要跟连接状态表有关，防火墙在收到ACK报文时，首先检查该ACK报文是否属于连接状态表中的已有连接，如果是，防火墙转发该ACK报文，如果未命中任何一个已有连接，防火墙会将该ACK报文丢弃，如下图所示：
ACK Flood攻击对系统的影响
由此来看，ACK flood攻击对端系统与中间系统的影响相对于其他攻击来说都不是非常明显，至于网上有相关资料讲其需要配合SYN flood攻击产生较好的攻击效果，原因为针对防护SYN flood攻击的一种技术 ——SYN cookie技术。
当某些启用SYN cookie技术进行SYN flood攻击防护的中间设备（专业抗DOS设备、防火墙、IPS、负载均衡、路由器等），在收到ACK报文时，需要计算cookie值，这个过程会消耗一部分中间设备的CPU资源，如果大量的ACK报文过来的话，很可能很快就会导致设备资源耗尽，达到拒绝服务的效果。
关于SYN cookie的工作机制，我在互联网上找到一篇文章，文章链接为：
http://blog.csdn.net/force_eagle/article/details/5348946，作者：droplet，现全文引用至此：
“
Cookie如何计算？
cookie = MD5(srcip,dstip,sport,dport)
端口是否需要考虑哪？没有端口的话，可以少一点计算。
Syn-cookie是无状态的，在Gateway上，不会保存任何与connection相关的东西，所以不会占用gateway的资源，缺点就是需要计算cookie，CPU占用会高一点。
如果不考虑端口的话，cookie是不是可以cache哪，如果cache了，就有查找的开销，并不一定比MD5的hash快多少。
在Syn-cookie之前，先要检查一下srcip是不是spoofing的，这里需要做一个反向的路由查找，看看是不是从错误的接口进来的，也可以确认一下源地址是否可达。
是不是也应该做一个源端口的检查哪？如果是0~1024的端口，就默认是非法的，因为这些端口在操作系统里面，一般是保留的，不会分配给应用程序。
Syn attack是否有signatue? 不同的syn flood工具，生成的工具包，应该有一定的模式，如果能够找到这个signature，就可以通过signature来直接drop这个syn，不用再做syn-cookie的检查了。
Syn-cookie会strip掉client和server的tcp option，对client，可疑在cookie里面带上tcp option，但是对server来说，就比较难办一点。strip掉tcp option，对connection的性能有影响。
对syn-flood的防范，目前还是threshold based，因为不能区分正常包和攻击包，但是如果能够定义攻击的signature，就可以做signature based的防范，这样可以更有效一点。”
在这里有个疑问，启用SYN cookie技术的中间设备在收到SYN报文的时候会建立cookie序列，在收到ACK报文的时候会计算cookie是否合法，那么是不是任何一个ACK报文都计算cookie值呢？从全文的描述来看，应该是在收到三次握手的最后一个ACK报文时才进行计算。
如果是对所有ACK报文都进行cookie值计算，这个中间设备对SYN cookie技术的实现是不是非常不科学呢？如果仅针对三次握手时的第三个ACK报文进行cookie值计算，那么中间设备应该直接丢弃随机伪造的ACK flood攻击报文。如果是丢弃随机伪造的ACK flood报文，那么对中间设备资源的消耗也是有限的。
需要申明的是，以上仅为我个人站在技术原理的角度作出的推论，实际环境下没有亲见ACK flood攻击带来的影响。欢迎各位兄弟姐妹一起做进一步的探讨。
标签: TCP RST 防火墙 ACK flood SYN flood 连接表 SYN cookie ACK报文 连接状态表
某业务系统由于连接数限制导致间歇性访问慢故障分析案例
作者：易隐者 发布于：2012-9-26 18:05 Wednesday 分类：网络分析
【说在之前】：
1，该案例为端系统设置连接数限制导致的应用间歇性缓慢故障，在实际工作环境下，我们更容易遇到的是中间系统对连接数限制导致的一些范访问异常，令人头疼的是，并不是所有开启连接数限制功能的中间系统在丢包后都会向源主机发送ICMP差错报文，这会给大家分析定位带来难度，大家在实际工作中需要留意；
2，该案例涉及到的知识点主要为“ICMP主机管理性禁止差错报文”和“连接数限制”，关于ICMP主机管理性禁止差错报文，大家可参考本博客《ICMP通讯管理性过滤禁止差错报文（type 3，code 13）》一文，虽然“type 3，code 10”与“type3，code 13”有些差异，但是差别不大，可以借鉴；关于连接数相关知识点，大家可参考本博客《连接数相关知识》一文；
【我的案例】：
1 故障环境
网络拓扑：
说明：
1，内部办公机器都是192.168.1.0/24段的，内部办公主机通过防火墙做NAT，转换为X.X.X.138访问互联网；
2，内部办公服务器的地址为192.168.1.191，其通过防火墙映射为公网地址X.X.X.139对外提供6888端口的web服务。
业务访问流程：
内部办公机器都是通过NAT后的公网地址X.X.X.138访问办公服务器的公网地址X.X.X.139。其流程如下图所示：
2 故障现象
故障现象主要表现为：
1，部分内网办公主机经常出现打开主页慢、登录慢或者某些页面不显示的情况，如下图所示：
打开主页时的长时间等待页面截图
登录时长时间等待页面截图
2，这些故障现象间歇性出现，有时多刷新几次页面后，打开的速度会恢复正常。
3，外网用户访问业务系统一直正常，该故障已经持续数月。
3 故障分析
通过故障现象，我们可以看出，这是比较典型的部分系统出现问题的案例，由于其不具备全体的故障特征，又是间歇性的发生，因此，此类故障按照常规的分析方法很难找到真正的故障原因，我们还是先在客户端抓取一下故障时交互的数据包，站在数据包的角度来分析一下可能的原因。
1，找一台出现故障的主机192.168.1.167，捕获其打开主页面缓慢时的数据包。
2，查看缓慢时的数据交互情况，如下图所示：
我们通过delta tima值可以看到，这个交互的过程存在较大的延时，并且我们发现，在交互的过程中存在数个“ICMP主机通讯管理性禁止”的差错报文，这些报文都是X.X.X.139发给故障主机192.168.1.167的。
3，我们双击其中一个ICMP主机通讯管理性禁止报文，查看其封装的被过滤的原报文相关信息，如下图所示：
我们发现，被X.X.X.139管理性过滤掉的报文是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文。
4，我们再结合上下数据包交互的情况，我们可以发现，这个ICMP主机通讯管理性禁止报文的前一个报文正是192.168.1.167以源端口4075发往X.X.X.139的6888端口的TCP SYN请求报文，如下图所示：
这充分说明当故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求时，被服务器管理性过滤禁止了。
5，那么服务器为什么会管理性禁止故障主机192.168.1.167的4075端口向服务器的6888端口尝试TCP连接请求报文呢？难道服务器上设有针对源端口为4075的禁止访问策略吗？服务器显然没有做这种针对源端口过滤的必要，另外，我们还发现除了故障主机以源端口4075访问服务器的SYN报文被管理性禁止外，还有其他源端口的SYN请求报文被服务器管理性禁止，如下图所示：
这里被服务器禁止的报文的源端口有4078、4083、4086等。
另外，通过上图中的“delta time”值，我们也可以发现正是这些报文导致了故障主机在建立新的TCP连接之前花费了数秒的连接建立尝试时间（SYN重传时间，大家可参考本博客《TCP重传》一文），从而导致了页面打开缓慢的现象出现。
6，这个现象具有明显的针对TCP的随机性的过滤特性，因此，我们很容易就可以联想到是否是服务器在TCP传输层存在某些检测过滤机制？而在传输层最为常见的就是TCP连接数限制了。
一般而言，在服务器上实现针对单IP访问服务器的TCP连接数进行限制是一件简单的事情，一个独立的IP只允许与服务器建立少量的TCP连接，这对于那些对外提供服务的服务器来说是一种较为常见的防护措施，在正常情况下，单个客户端与服务器的正常交互所需要的TCP连接数并不是很多，而限制的数值一般都会高于正常的需求，但是在有些情况（如经过NAT或代理后对业务的访问）下，这将导致问题的产生。
7， 上述推理非常合理，我们通过检查服务器的相关设置，验证了我们的分析和推论结果。
8， 分析结论：
这个故障是由于业务服务器端设置了针对单IP访问连接数限制功能，而内部办公网主机都是通过防火墙NAT地址转换后对业务服务器进行访问，这直接导致在业务访问高峰时，出口NAT IP地址访问业务服务器的连接数超出限制，业务服务器对后续的TCP连接建立请求发出ICMP差错报文，等一些TCP连接释放后，才允许新建TCP连接，这导致访问业务系统非常缓慢。并且这种特性决定了故障现象表现为间歇性发生。
4 故障解决
通过修改服务器Apach对单一IP地址的连接数的限制后，故障得到解决。
标签: 疑难故障 TCP icmp差错 SYN 连接数 NAT 地址转换 业务慢 连接数限制 ICMP主机管理性禁止差错报文 Type 3 Code 13 type 3 code 10
连接数相关知识
作者：易隐者 发布于：2012-9-19 19:58 Wednesday 分类：网络分析
连接数是网络中非常重要的一个概念，在我们学习工作的过程中会经常遇到。下面将针对连接数相关的一些知识点做一些描述。
“连接数”是什么
不同产品对“连接数”的理解有一些差别，但是主流认为网络中交互双方的五元组信息决定了一个连接。所谓五元组信息是指源地址、源端口、目的地址、目的端口以及协议类型。连接数就是网络连接的数目。基本上TCP/UDP应用根据五元组信息都可以很好的对应于一个连接，但是对于ICMP协议，不同的产品会有一些不同的处理，考虑到ICMP报文在实际工作环境下非常少，相对于TCP、UDP应用的连接数基本上可以忽略，因此不针对此做深入的描述。
并发连接数
并发连接数是指同时在连接表中的连接数目。端系统和中间系统在处理这些连接时都会设置一个连接超时时间，在超时时间溢出之前，系统会为这些连接分配相应的存储资源。而我们熟知的Syn flood DOS攻击正是利用这个特性来达到攻击效果的。一般而言，并发连接数是衡量一个中间系统性能的指标之一。
每秒新建连接数
每秒新建连接数是一般是指中间设备在单位时间内（1秒内）所能建立连接的数量，这个参数的大小直接影响中间系统在单位时间内所能建立的最大连接数量，其也是衡量中间系统性能的一个重要指标。
连接数限制
连接数限制主要是指端系统或中间系统基于安全（防攻击）、管理（流量控制）等方面的需要而对某些IP的网络连接数量限制在某一范围内的策略。如windows系统中的连接数限制，防火墙路由器等中间系统上的“连接数限制”功能等。
端系统中的主机防火墙（如linux下的iptables）、操作系统本身、应用程序（Apche、IIS、数据库等）等都可能针对连接数进行限制，而现在常见的中间设备（防火墙、路由器等）基本上都支持连接数限制的功能，大家可以根据实际环境中的设备自行查阅相关手册的连接数有关功能的设置。
我们随便找个路由器上连接数限制功能设置的截图看看：
我们再来看看IIS连接数限制功能设置的截图：
连接数限制对网络的影响
连接数限制策略实施之后，当被限制连接数的IP超出限制的范围，其后续的网络连接将会被端系统或中间系统过滤丢弃，这将导致这些IP在进行网络交互时速度变慢、丢包等情况发生。因此，连接数限制是管理策略性导致网络交互异常的原因之一。
另外值得注意的是，在实际环境下，虽然端系统或中间系统可能会由于连接数限制功能丢弃部分报文，但是并不是所有设备在丢弃这些报文之后会向源主机发送ICMP差错通告报文，这给我们分析定位带来了一些难度。
标签: TCP 五元组 ICMP 连接数 连接数限制 并发连接数 每秒新建连接数
传输层的响应时间（系统层响应时间/服务器响应时间）
作者：易隐者 发布于：2012-9-12 21:30 Wednesday 分类：网络分析
基于TCP的业务应用在交互业务数据之前必须先建立TCP的连接，而系统在接受到TCP连接的请求报文(SYN报文)时，系统将直接对其进行响应而不需要经过应用程序的处理，因此，我们分析传输层的响应时间的意义就在于该时间值可以间接地反映出服务器端的系统性能。如果服务器系统本身性能不足，就很可能导致该时间值较高。我们在分析业务应用慢的时候，要界定清楚是服务器端本身的性能问题导致的还是应用程序本身的处理性能不足导致的。
传输层的响应时间主要是指在建立TCP连接的三次握手过程中，服务器端响应客户端SYN数据包的间隔时间，如下图所示：
-
QQ邮箱订阅
-
搜索
日历
最新日志
链接
分类
最新碎语
- 如果一个人想要做一件真正忠于自己内心的事情，那么往往只能一个人独自去做"——理查德·耶茨
2019-06-25 21:34
- 日后我们知道，真正的人生道路是由内心决定的。不论我们的道路看上去如此曲折、如此荒谬地背离我们的愿望，它终归还是把我们引到我们看不见的目的地。（茨威格《昨日世界》）
2019-03-16 21:27
- 如果你渴望得到某样东西，你得让它自由，如果它回到你身边，它就是属于你的，如果它不会回来，你就从未拥有过它。——大仲马《基督山伯爵》
2018-10-09 22:07
- 人生有两大悲剧：一个是没有得到你心爱的东西；另一个是得到了你心爱的东西。人生有两大快乐：一个是没有得到你心爱的东西，于是可以寻求和创造；另一个是得到了你心爱的东西，于是可以去品味和体验。——弗洛伊德
2018-09-25 18:06
- 一个人越有思想，发现有个性的人就越多。普通人是看不出人与人之间的差别的——布莱兹·帕斯卡尔
2018-08-30 18:44
存档
- 2020年11月(2)
- 2018年1月(1)
- 2017年12月(1)
- 2017年11月(6)
- 2017年6月(1)
- 2017年5月(1)
- 2017年4月(1)
- 2017年3月(1)
- 2016年11月(1)
- 2016年4月(1)
- 2015年7月(2)
- 2015年6月(1)
- 2015年5月(5)
- 2014年12月(1)
- 2014年11月(1)
- 2014年10月(1)
- 2014年8月(1)
- 2014年7月(1)
- 2014年6月(1)
- 2014年5月(1)
- 2014年4月(3)
- 2014年2月(2)
- 2014年1月(2)
- 2013年12月(1)
- 2013年11月(1)
- 2013年10月(2)
- 2013年9月(1)
- 2013年8月(1)
- 2013年7月(3)
- 2013年6月(2)
- 2013年5月(1)
- 2013年4月(3)
- 2013年3月(1)
- 2013年2月(2)
- 2013年1月(2)
- 2012年12月(11)
- 2012年11月(12)
- 2012年10月(12)
- 2012年9月(26)
- 2012年8月(29)
- 2012年7月(18)
- 2012年6月(2)
- 2012年5月(25)
- 2012年4月(16)
- 2012年3月(13)
- 2012年2月(6)
标签
blogger
