蚂蚁网-多维人生，三实而立！

TCP确认机制异常案例

作者：易隐者 发布于：2012-12-8 15:06 Saturday 分类：案例讨论

缘起
        一个好友通过Sina微博转发了一个兄弟的问题给我，其问题如下：
“AB机器tcp，A发送100字节给B，B返回数据但是其ACK=1，这期间A均正确ACK B的所有序列号，B置FIN位，A发 FIN+ACK 给B，此后B返回的ACK=2，那么此时A是应该重传之前的99字节，还是直接重传之前的FIN+ACK包给B？”。

       通过这样的描述我认为这在实际环境中应该不会存在，结果这个兄弟告诉我是在实际环境中发生的，并将交互的报文传一份给我。

       好奇之余，对这个报文进行了仔细的分析，接下来跟我一起来看一下整个分析的过程。

分析产生这个交互的原因

       选取其中一个TCP会话，查看其具体的报文交互情况，如下图所示： 

       这个报文交互的情况截图结合下面的TCP交互流图一起，看起来更清晰一些：

        通过交互报文的解码，我们可以清晰的看到，服务器192.168.104.229已经对客户端发送的get请求作出了应用层的响应，如下图所示：

       其响应为：HTTP/1.0 403 Forbdden
       但是其ACK号却为1，接收并处理了客户端的应用请求报文，但却并未对其进行确认，这充分证明服务器192.168.114.229的TCP确认机制出现了异常！

       我们再来一起看看客户端主动发送FIN报文之后的交互情况：
 
       客户端在发送FIN报文之后，服务器的ACK号变为2，这对于客户端来说，这是对其应用字段的确认，这说明服务器端仅收到客户端1字节的应用字段，因此客户端将剩下的303字节的应用字段放在FIN报文中一起发给服务器端，而服务器在收到这个报文后，回应客户端的ACK号变为3，客户端接着将剩下的302字节的应用字段放在FIN报文中再次重传给服务器端，如此反复。
       至此，我们已经能够意识到，服务器端的ACK确认并不是针对客户端的应用字段的，而是针对客户端的FIN报文的，服务器的确认机制出现了异常，服务器不再确认客户端的应用字段，而只确认客户端的SYN报文和FIN报文。

分析结论

       此问题产生的原因为：服务器的TCP确认机制出现异常，其只确认SYN报文和FIN报文而不对应用数据进行确认。

       另外，我们还留意到一个有意思的现象：正常情况下，端系统一般都会在发送的数据段获得对端确认之后，才会主动发送FIN报文，释放TCP连接，如果在多次重传之后仍未得到对端的确认，通常会向对端发送RST报文，异常释放TCP连接，但是此处可能为了提高交互的效率，客户端与服务器在发送的数据段未收到对端的确认报文就主动发送FIN报文释放TCP连接。

阅读全文>>

标签: TCP SYN FIN ACK TCP确认机制

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

【转】上网认证页面无法打开案例

作者：易隐者 发布于：2012-11-25 10:40 Sunday 分类：案例讨论

【说在之前】：

1，该案例的确属于疑难故障范畴，若不是通过抓包方式，站在数据包交互的角度进行分析是无法定位、解决该故障的，因此，该案例具有学习参考价值；

2，案例的分析用到了关联分析法和对比分析法，思路非常清晰，但整个文档在图文编辑和措词这块还可以做进一步的加强，考虑到原文的完整性，我不对该文档做任何修改；

3，难能可贵的是作者在找到故障原因并解决故障之后，没有像大部分人那样将这个故障束之高阁， 而是将自己的分析思路、过程整理成文档，分享给大家，另外，发现其中难以解释的、存在疑问的地方，供大家一起讨论，这正是我一直倡导的“自我总结、无私分享、共同探讨、共同进步”的学习方式；

4，针对该案例后面的疑问，我就我的理解作出相关解答，供大家参考。

     针对第一个疑问：AC在此处工作在透明模式下，正常情况下其对报文的干预和处理根本不需要经过路由，也就是说，AC在做HTTP重定向的时候，根本不需要根据路由表，将这个HTTP重定向报文转发给PIX防火墙，而应该直接构造相应HTTP重定向报文发往核心交换机，因此，此处出现这样的问题，我个人认为如果AC是按照路由方式处理的话，其应该有相应的转发表，转发表中会有下一跳、转发接口等相关信息，而出现此案例中的问题，说明AC的转发表出现了异常，可能是其上联口和下联口是属于同一网段，而AC转发表未对其进行区分导致的；

     针对第二个疑问：这里需要明确，AC的管理口和业务口是否是完全独立的，如果是，那么所谓的两条默认路由是完全分开的，没有任何问题，如果不是，那么根据不同的系统处理方式，负载均衡（根据报文或其他）或者选择其中一条都是有可能的，多年前我曾写过一篇《供电局调度所前置机故障解决说明》的文档，就是两条默认路由导致异常的案例，过段时间我把这个案例共享到我的博客供大家参考。

5，该案例作者肖鉴为我以前推出《合肥网络分析技术团队招募学徒》的第一个学员。他不远千里从福建专程请假几十天跟随我学习相关知识，当我第一眼看到他时，我就被他的这种对技术执着追求的行为所感动，他基础不错，学习踏实认真，我个人认为我真正给他的帮助不在于具体技术的成长和进步，而在于影响他对技术的自信、清晰的职业发展方向规划以及行事的风格，在他身上我能看到我以前的影子，他现在深信服的总代，刚获得深信服深信服华南区技术大比武冠军，看到他的成长，我的内心是无比的欣慰。

【原文全文】

1. 网络环境

        故障网络环境如下图所示： 

说明：
1． 出口防火墙工作在路由模式做NAT代理内网上网，E1口IP地址192.168.247.1/24。
2． 上网行为管理工作的网桥模式下，为其网桥IP地址配置192.168.247.3/24、网关IP地址为192.168.247.1用于设备管理，下联三层交换机IP地址为192.168.247.2/24。由于，前置PIX防火墙为阻止192.168.247.0/24网段上网，所以为了上网行为管理能够更新内置规则库，上网行为管理口下联三层核心交换机为其配置IP地址192.168.20.250网关IP地址192.168.20.1。
3．上网行为管理对内网部分网段实行认证上网。

2. 故障现象

       内网无须进行认证PC机访问互联网正常，需进行认证网段PC机上网在正常情况必须得先进行认证输入用户名和密码后方可访问互联网，故障表现为认证网段PC机无法正常跳转至认证界面输入用户名和密码。如下图所示： 

3. 故障分析

3.1 常规分析

       在PC上访问网络时无法跳出登陆界页时，我们手动输入http://192.168.247.3认证登陆页面是正常，如下图所示，并且，输入完认证用户名和密码后可以正常访问互联网。说明网络中并不存在路由问题。那么是否可能是设备本身处理机制出现问题呢？还是，PC机与上网行为管理设备通信出现了其它的异常导致PC机无法正常弹出认证页面？。 

阅读全文>>

标签: 交换机 团队 疑难故障 TCP 网络分析 负载均衡 抓包 深信服 上网行为管理 HTTP重定向 AC 路由表 转发表

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

【转】中科院《个人隐私泄露风险的技术研究报告V1.0》的部分内容

作者：易隐者 发布于：2012-11-23 9:43 Friday 分类：案例讨论

【说在之前】：

1，早上看到新浪新闻《中科院报告：360产品存在三大隐私安全问题 》，其中引用了中科院保密技术攻防重点实验室研究撰写的《个人隐私泄露风险的技术研究报告》的部分内容，通过分析可见任何应用产品，若非自行开发，均可能在后台执行各种非法的或非授权的操作，而这种隐形的操作行为很可能会给最终用户带来各种威胁；

2，这些后台的隐形行为不易为用户所察觉，但是利用网分析技术可以对这些隐形行为进行数据包级别的深入分析；

3，该报告分析的主要方式是通过网络分析的技术手段实现对360浏览器网络行为的分析，使用的工具看截图应该是wireshark，此报告作为利用网络分析技术对应用进行分析评估的一个案例，值得大家参考学习。

【原文链接】：http://tech.sina.com.cn/i/2012-11-23/08517825584.shtml

【原文】：

　　前言

　　随着国内外个人隐私泄露事件的频繁发生和对个人隐私保护的重视，人们越来越关注日常工作生活中计算机软件、移动终端以及高技术带来的个人隐私问题。中国科学院信息工程研究所保密技术攻防重点实验室对当前常用软件和终端产品的用户隐私保护情况进行了初步调查，通过实验研究发现了一些有关隐私保护存在的风险。本文主要从常用软件、网络服务、移动终端以及声光电磁等四个方面介绍了实验室的研究结果和发现。文中内容注重实例研究和数据再现，希望引起有关部门对个人隐私相关问题的关注。

　　本文得到了北京大学互联网安全技术北京市重点实验室的帮助。

　　1 终端常用软件与用户隐私保护

　　1.1网络浏览器

　　许多网络浏览器为了增强用户体验、提供个性化服务、发展定向广告业务等目的，通常会在后台收集用户的网页浏览记录等个人信息上传到服务器。然而许多收集用户个人信息的行为是在用户不知情的情况下进行的，或者所收集的信息超出了软件《安装许可协议》中进行了明确规定的范围。

　　实验室以360安全浏览器当前最新版本5.0为例，对浏览器的用户隐私泄露问题进行了分析和研究，网络浏览器中的隐私泄露威胁存在于以下几个方面：

　　1)预留后门，植入代码：一些浏览器在使用过程中会在用户不知情的情况下在后台执行《安装许可协议》规定内容之外的功能，360安全浏览器在运行过程中约每5分钟与服务端进行一次通信，并下载一个文件，如下图所示，下载的文件为se.360.cn/cloud/cset18.ini，但是从数据流可以看出该文件实际上是一个PE文件，文件头中标识的产品名称为DataDll。

　　将该文件从数据流中提取出来得到一个dll文件，查看该文件的属性，得到其文件说明为“360安全浏览器 安全网银”。

　　从该文件中提取到一段Base64编码的文本信息：

W3N0XQ0KY291bnQ9Mg0KW3N0MV0NCmlkPTENCnVybD1odHRwOi8vd3d3LmJhaWR1LmNvbS9zZWFyY2gvc

mVzc2FmZS5odG1sKg0KW3N0Ml0NCmlkPTINCnVybD1odHRwOi8vdmVyaWZ5LmJhaWR1LmNvbS92Y29kZT8q

DQpbdHJheW1zZ10NCnN0YXRpY3NpZD0zMQ0KY291bnQgPSAxDQp1cmwxPWh0dHA6Ly93d3cuYmFpZHUuY2

9tL3NlYXJjaC9yZXNzYWZlLmh0bWwqDQpbbWFpbl0NCmhrcmVzMj0xDQpjYmM9MQ0KW2NiY10NCnVybGNvdW

50PTENCnVybDE9aHR0cDovL3d3dy5iYWlkdS5jb20vc2VhcmNoL3Jlc3NhZmUuaHRtbCoNCmNiY2NvdW50PTINC

mMxPUJBSURVSUQNCmMyPUJEVVNT

　　经过解码后的内容为：

　　[st]

　　count=2

　　[st1]

　　id=1

　　url=http://www.baidu.com/search/ressafe.html*

　　[st2]

　　id=2

　　url=http://verify.baidu.com/vcode?*

　　[traymsg]

　　staticsid=31

　　count = 1

　　url1=http://www.baidu.com/search/ressafe.html*

　　[main]

　　hkres2=1

　　cbc=1

　　[cbc]

　　urlcount=1

　　url1=http://www.baidu.com/search/ressafe.html*

　　cbccount=2

　　c1=BAIDUID

　　c2=BDUSS

　　由此可推测该DLL文件的功能与网银无任何关系，而是跟搜索引擎百度相关可能是为了躲避Referer字段的检查。这种行为虽然不涉及用户隐私，但是具有欺骗性。

　　此外，360安全浏览器还会在用户不知情的情况下定期从服务端下载和执行一个名为“ExtSmartWiz.dll”的动态链接库。如果该动态链接库被植入恶意功能或者不法分子利用域名劫持等方法对浏览器下载的“ExtSmartWiz.dll”文件进行恶意篡改，将会给用户安全带来严重危害。

　　2)收集用户浏览记录：很多浏览器会将用户所打开的页面地址上传到服务器，以分析用户的个人爱好或者统计网站的受欢迎度，从而在浏览器首页更好地为用户推荐个性化内容。这种行为也侵犯了用户的隐私数据。下图为当用户使用360安全浏览器5.0访问网页的时候，每打开一个网页之后都会向360的特定服务器发送一个POST请求，内容包含加密过的url信息。

　　3)收集浏览器地址栏输入信息：当用户在浏览器地址栏中输入网址的时候，很多浏览器为了帮助用户自动补全网址，会把用户所输入的内容上传到服务器来。下图为当用户在360安全浏览器5.0的地址栏中输入“10.105.240.57”时，浏览器会将该地址发送到sug.so.360.cn，并且发送时附带的Cookie中会带有具有用户唯一性标志的guid值，这可能会导致特定用户的地址栏输入以及浏览记录被跟踪和泄漏。

　　下图所示为当用户在360安全浏览器5.0的地址栏中输入“weibo.com”的过程中，每输入一个字符，浏览器就会向sug.so.360.cn发送当前浏览器地址栏中的内容(即“w”、“we”、“wei”、“weib”、“weibo”、“weibo。”、“weibo.c”、“weibo.co”、“weibo.com”)。

图1-5

阅读全文>>

标签: wireshark 网络分析 解码 安全 业务 网络行为 应用分析 应用评估

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

两台soho级小路由之间的“正义”之战

作者：易隐者 发布于：2012-10-16 9:49 Tuesday 分类：案例讨论

       某用户反应访问互联网经常出现缓慢的情况，向我们发出支援请求。小鲍在现场抓包发现，内部存在两个MAC地址，每秒共发送6万多个免费ARP（IP地址为192.168.1.1）报文，如下图所示： 

       后经MAC地址分析并通告交换机MAC表，找到这两个MAC的设备为两个小路由器，用户说明因其部分办公室接入点不够，将小路由器当小交换机给信息点不够的办公室使用。

       小鲍经现场测试发现奇怪的现象：

1， 当关闭其中一台路由之后，另一台小路由器发免费ARP报文的频率变为每秒1000多个；
2， 当两台小路由器全部开启接入办公网时，其发送免费ARP报文的频率迅速攀升至每秒30000多个；

       每秒1000多个免费ARP报文的发包频率在一般的以太网内应该影响不大，终端使用者至少不会感觉到明显的速度变慢情况。那么问题来了：

       为什么一台在线没什么问题而两台同时在线发包频率就会出现这种质的变化呢？

        接下来我们一起来分析一下。

       小路由发送免费ARP报文的目的就是防止内部存在伪造默认网关地址192.168.1.1的免费ARP报文实施ARP欺骗的主机，其1秒发送1000多个免费ARP报文可以保证路由下所有的主机ARP表中网关地址（192.168.1.1）的MAC对应关系维持正确。因为大部分的ARP欺骗的发包频率并不需要非常快。

       但是当小路由器检测到（收到）来自于其他MAC的免费ARP（192.168.1.1）报文后，其认为是内部主机在实施ARP欺骗行为，因此逐步提高了其发免费ARP报文的频率，而这个动作会在两个小路由上同步进行，由此导致的后果就是，在其性能可承受的范围内，双方不断的增加其发送免费ARP报文的频率。其交互过程示意图大致如下：

       通俗点来说，这好比双方都是身怀大招必杀绝技的高手，他们拥有同一个坚定的信念：除恶扬善，拯救人民大众与水火之中，但是他们都误以为对方是恶，双方实力相近，大招必杀全开，拼死一搏的结果就是：他们一起毁了整个战场，人民大众皆因他们的大招必杀技而死。

       网上搜索了一下一般soho级小路由器的硬件架构和配置，发现大部分是ARM9处理器，2M-8M的内存，CPU主频一般也就几百兆赫兹，真没想到这种小路由设备能够具有如此巨大的发包频率潜力。

       我们不可小觑任何一台看似普通的设备，当其抽疯的时候，足以致命。

阅读全文>>

标签: 免费ARP ARP欺骗 发包频率 soho路由

评论(1) 引用(0) 浏览(11040)

【转】某加密机经天融信防火墙后应用异常故障案例

作者：易隐者 发布于：2012-9-24 14:10 Monday 分类：案例讨论

【写在前面】：

1，该案例是一个特殊应用、特殊环境下的疑难故障案例，给我们的启示是在故障现场，我们需要充分了解清楚跟故障有关的应用特性，比如此案例中的加密机的工作机制；

2，该案例涉及到以下知识点：IP报头校验和、IP分片（请参考本博《IP分片》一文）、防火墙对分片报文的处理等；

3，此案例在整理文档时，应该简化了很多的分析测试过程，我按照我的理解做一些梳理：

（1），IP报头校验和只跟IP报头有关，跟IP封装的数据无关，因此，如果原文中的描述的“收到报文是否进行校验和检查”是指IP报头检验和的话，那么应该不会存在校验和错误而被防火墙丢弃的问题，如果是指TCP校验和或UDP检验和的话，那么，每个来自于加密机的报文其TCP或UDP校验和都是错误的（因为多了33字节），因此防火墙肯定会直接丢弃这个报文，根本不存在文档中描述的在防火墙转发接口抓到1460字节数据包的情况；

（2），防火墙不对收到的报文进行校验和计算，那么这个报文才会进入防火墙的内核处理流程，因为来自于加密机的报文是IP分片报文，因此防火墙会对此分片报文进行处理（选择直接转发分片报文还是重组后匹配策略再转发），如果防火墙直接转发，则没什么问题，如果是重组转发，这里就存在一个问题：防火墙能否完成这个报文的重组？因为IP分片的重组是根据IP报头中的相关信息来完成的，其中非常重要的一个参数就是分片偏离量，这个值决定了分片报文在原始报文中的位置，而在这个故障环境下，每个报文都被加密机在尾部添加了只有加密机能够识别的特征码，防火墙并不能识别，那么防火墙在重组这些报文的时候，如何处理正常分片报文跟前一分片报文尾部添加的33字节部分的重叠呢？这是值得思考的。如是覆盖33字节的尾部识别码，则到达对端加密机后，加密机会丢弃这个报文，并不是因为文中所说的“认为加密数据被篡改”，而是由于被覆盖了数个识别码导致接收端加密机无法正常识别加密报文（篡改的识别是通过校验和得到的，接收方根据报头信息可以计算出校验和，也就是说只要报头信息没错，校验和就不会错，而防火墙在重组完毕后转发前肯定会重新计算转发报文的报头校验和）。

4，各位读者兄弟根据自己的理解，自由参考我上面的分析和下面的案例原文，欢迎探讨和交流。

【原文全文】：

一、拓扑 

二、环境描述

       该拓扑使用的VPN链路是某公司的产品，该VPN在做加密处理时，TCP头和IP头都不做加密，只对数据区做加密，通过在加密机的抓包，发现加密机把所有MTU大于1300的数据包做了分片处理，并且在所有包的末尾加入自己的N字节加密识别码，这样从加密机发出的数据包MTU值最大1333，对于大于1333的报文（如1460）的数据包加密机都是分2个包进行传送，在没接防火墙时一切正常，接入防火墙后导致访问不正常；
       拓扑中客户端172.16.1.22在访问服务器172.16.1.33时，服务器回应的MTU值1460数据包被服务器端加密机拆成2个包（第一个包1300），并在每个包的末尾加入33位，而防火墙在接收时将两个包合并转发，具体表现为防火墙接收口（接服务器端加密机）收到的报文数据长度是1333，而转发口（接客户端加密机）转发的报文数据长度是1460，这样客户端加密机就认为加密数据被篡改，导致VPN加密通讯错误；

三、分析过程与解决方式

1、 由于加密机的特殊性，所以加密封包后的数据在通过防火墙时，会被认为是错误报文，
解决方法：将防火墙“选项设置”---“安全设备系统参数”---“系统参数开关”下的“收到报文进行是否效验和检查”选项取消，如下图所示 

2、 加密机对大于1300的数据包做分片处理，到防火墙时，发现数据是分片包，防火墙又给重组后转发，导致对端加密机认为数据被篡改，不再对该数据包做解密处理；
解决方法：启用防火墙中的分片处理，将经过防火墙的数据都不做分片重组处理；
3、 以上两点设置好后，TCP报文可以正常通讯，但UDP报文（如视频报文）由于数据量大的缘故在通过防火墙时，经常丢包；
解决方法：研发根据该问题给了一个特殊的补丁，专门解决UDP报文处理的，只要打上该补丁即可；

四、总结

1、 将防火墙“选项设置”---“安全设备系统参数”---“系统参数开关”下的“收到报文进行是否效验和检查”选项取消；
2、 启用防火墙中的分片功能，将经过防火墙的数据都不做分片重组处理；
3、 打上专用的补丁；

阅读全文>>

标签: ip分片 天融信 分片 防火墙 重组 校验和 IP报头检验和

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