- 论坛徽章:
- 9
|
本帖最后由 wlmqgzm 于 2015-10-24 14:38 编辑
回复 53# cokeboL
好吧, 先说一个真实的事情, 时间久了, 原文可能有出入, 靠记忆转写.
"TCP/IP校验不足"造成的"黑客入侵"事件
美国某著名的金融交易公司发生的虚假的 "非法入侵案", 某交易网络中断三天, 交易缓慢, 损失巨大.
某公司的网络, 号称是全世界最安全的网络, 5级防火墙, 清一色的全世界最好的设备, IBM, CISCO....., 其中IBM是那种号称双计算双校验, 永不出错系列的超级计算机,
不说内存硬盘之类的, 即使是CPU核心, 也是每一步计算至少2个CPU同步计算, 计算结果同步硬件对比, 出错自动同步重做, 永不出错, 全部是硬件级的校验.
机房是那种安全级别最高的, 层层有授权, 平常基本没有人能够进入核心, 号称永不停机.
某天, 突然一级告警, 某个方向的交易数据提示, 检测到"非法的篡改的交易数据", 不是一条两条, 是铺天盖地的信息. "黑客攻击???" 这是首先的反应......
很快各地纷纷告警, 交易被冻住了, 失去响应. 毕竟是超级大公司, 各类专家云集, 连续三天, 动用了所有可能动用的手段, 没有找到原因, 暗藏的黑手, 无影无踪........
老板已经通知了有关政府部门, 并且得到了强力支持, 全国专家云集, 一定要找到黑手, 不达目的, 绝不罢休, 三天没有抓住这个黑客,
后来其实很快已经有专家意识到, 问题可能出在内部, 但是,在没有证据的情况下, 谁都不敢乱说.
BOSS也坚持即使是内部原因, 也一定要找到, 绝不能轻易重启动服务器, 否则, 内部的炸弹不直到什么时候还会爆发.
第三天, 救火英雄出现了, 后来成为公司技术主管, 他找到了原因: TCP/IP校验不足的问题.
1) 为了保证可靠和高性能, 数据格式是定长的, 代码非常简洁易懂, 所有的数据全部有多组校验, 发现多组校验码不正确, 即可判断"交易数据"被篡改, 多个交易记录不一致, 触发一级告警.
2) 某台服务器是最后一道防火墙, 数据在这里做最后检查,确认后, 进入交易核心, 信息在进入核心前还有多次校验多次加密, 都没有用. 因为最后一道防火墙把这些包装在外面的校验层都去掉了.
3) 由于某种原因, 交易流的近一半是经过2)某个socket连接进核心的, 某socket单条连接上的流量惊人. 后来, 这条连接上的交易都失败了.该socket的流量将经过CISCO对称网络, 抵达核心层. 单CISCO路由器下线不影响服务.
4) 某台CISCO路由器(机房内)在某种情况下, 一个bit出现错误, 该bit位刚好是要转发的IP包的长度字节中的一位, 并且刚好是最低位. 路由器的内存无校验, 无法纠正此错误.
某数据包进入路由器, 和出路由器的一个数据包, 少了一个字节. 一个数据包的一个字节丢失的错误是造成整个事件的根本原因.
5) TCP/IP的校验码是16位的, 有6.5万分之一, 不能检测错误状态. 对于此单字节丢失, 恰好, 未能给予检测出.
6) 数据格式定长, 因此, 从这个数据包以后, 来自于某链路的全部交易数据都被系统认为是"非法的篡改的交易数据".
后来,系统的交易日志, 确认, 将所有日志数据向后移动一个字节, 并从上个日志补上最后一个字节, 就都正确了.
总之, 这个人也是牛人, 发现了所有的问题, 并且解释了所有的前因后果, 所以, 后来被提升为主管.
讲这个故事, 就是要说明一下, TCP/IP层与应用层之间, 为什么要加一层, 校验层, 这个校验层很有讲究的.
这个故事里, 该公司也有校验的, 还有几组校验, 算法各不相同, 还有私有算法的.
另外, 也有人说, 我们公司每天交易上亿,从未出过错误, 我相信TCP/IP.
其实吧, 在同一个HUB上, 不经过路由器的话, 不加校验也没有问题, 因为, TCP/IP的底层, 以太网接口层, 校验码的长度远超TCP/IP层, 也够用了.
|
|