| Profil de Leo爬行的蜗牛PhotosBlogListes |  Outils  Aide |
我在港湾这半年（人物篇）我在港湾这半年（人物篇） 来港湾半年，认识了好多人。 Caowei 一面的主考官，技术很强 Gaoxin和peigang ：POWER测试组，测试风格：破坏性，极大压力。擅长于各种乱搞破坏行动，本拉登行动中国区负责^_^ 我在港湾这半年（技术篇）我在港湾这半年（技术篇） 真的是HOW TIME FLIES。时间过得听快的，眨眼间半年是一晃而过，似乎前几天我还在做三个月的总结，而现在我在写半年的总结了。 在这里，解决的是网络路由问题，因此和我在学校接触的网络开发很不一样，学校里学会的是上层网络的开发应用，在这里关注的是网络底层的维护。事实上，大半年的开发维护中，我使用上层网络的时间几乎为0。我已经大半年没有用过SOCKET了，报文对我而言只是一块内存了。 工作汇报 来自XX的异常报告，发现某时间系统发生主备倒换，由于用户没有及时发现问题，现场遭到破坏，技术支援部的同事们只好从系统的FLASH中读取到最近一次的异常信息记录。
根据异常中的指令位置和堆栈记录，大致推断是SNMP模块重复释放指针，导致主控板异常重启，主备倒换。 在缺失现场的情况下，只能尽量从代码走读中发现问题了，同时尽量在实验室复现问题。但广域网上报文繁多，环境复杂，无法模拟，一时间是头绪全无啊。最为庆幸的是SNMP模块下两个任务SNMP和SNMPTRAP代码流程简单。 通过代码走读整理，发现整个处理流程并不存在问题，偶尔有的几个代码错误（内存泄漏）并不足以引起主机异常，因而怀疑的重点转移到非法指针篡改，怀疑的对象扩展到ISIS，BGP,MPLS路由协议（这些协议在现场配置中存在）。而此时，我复现了异常重启的情况，虽与现场有所区别，但不失为一个切入点。而在第二天对测试手段的改进中，发现实际上不需要要这些协议也同样产生异常。 怀疑的重点定位在SNMP和SNMPTrap上，而单个SNMP在大量报文攻击的情况下依然运行良好，这说明SNMPTRAP才是问题所在，虽然异常表现在SNMP处理中，但可能现场仅仅是一个结果表项。 对SNMPTrap的分析发现主要的问题在与SINKS链表的使用，同时对SOCKET的使用也同样存在问题（我们没有系统底层机制对于SOCKET的保护的说明文档）。 再次对内存进行跟踪，发现在0x43的标识不能说明重复释放，环境模拟显示在最后异常之前，内存竟然已经被非法复写多次，而最后一次异常是问题积累引起的爆发。 总结复现问题得到的五个异常点，大致都和sinks链存在关系，相同的都是0x300地址访问错误。从怀疑重复释放到怀疑地址篡改，进入对系统的内存管理和SOCKET保护的质疑，一步一步走进问题所在。但由于最后还是没有复现和现场一样的问题，因而还是无法保证最后解决问题，时间紧迫，只好提交规避方案。周日开始验证规避方案，经过大量来自外部的SNMP报文48小时的攻击（相当于几年内现场的SNMP报文量）和内部TRAP报文发送对sinks的振荡测试，验证通过。 现在总结经验如下， 1对出现问题的原因进行部分分解，要对每个原因用到极端来试图复现。例如本例中，当初发现出问题可能由于发TRAP包发现时，就应该疯狂使用shell执行函数发送trap包。 2．不放过任何信息 对各种异常信息要分析到再也不能获取到信息后才放弃。 3．增加检测函数 对内存写越界的问题，增加检测函数，不失为一种比较好的方法。对于这种问题，首先要根据可以获得的信息，判断到底那块内存区域被写乱了，该块区域是否可以确定。然后在任务切换里或者被怀疑的程序段里增加检测函数。 4．复现问题是定位问题的关键 以前定位问题时，往往思考的是如何定位问题，忽略了思考如何复现问题。 5．坚定的信念 一筹莫展时仍需要思考。 2005年春节前最后一个网上问题单顺利结束，历时10天。希望大家都能过个好年。 14/01/2006 算命
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
