金融软件故障案例

案例背景

某农商总行生产前置机无法从人行生产服务器下载更新数据(约1M)，而开发前置机却能从开发服务器上正常下载数据，开发和生产前置交换机访问服务器的路径基本一致。

总行前置机访问人行服务器的数据走向为：前置机经过总行网络，访问到分行网络，然后由分行网络转发到人行网络，最后访问人行服务器。根据故障现象，选择在分行到总行的核心交换机出口部署科来网络回溯分析系统进行捕包分析。

案例分析

(一)故障通讯分析

对生产前置机下载更新数据的TCP会话进行解码分析，发现前置机发起请求数据包后，生产服务器马上响应了3个数据包，其中第一个携带60字节应用数据，第二、三个为1448字节，而客户端只是对第一个数据包进行了确认。

当服务器发出携带1030字节的第四个响应包后，前置机依然是对第一个数据包进行重复确认。根据TCP的重传机制，可以肯定当前置机收到第四个响应数据包时，并没有收到第二个1448字节的数据包，因此服务器对此数据包进行了重传，但经过多次重传客户端依然没有收到此包。

从对故障会话的数据包交互过程来看，前置机无法收到服务器的第二个响应数据包，导致无法完整更新数据。前置机却能收到第一个和第四个响应包，从数据包大小来看，这两个包携带的应用层数据较小，而第二个包携带的应用层数据为1448字节。从会话的TCP三次握手数据包来看，生产前置机和服务器协商的MSS值为1460字节，加上数据包头，数据包的总长度为1500字节。

由于从数据捕获点到前置机之间没有防火墙，不会对包进行过滤，因此怀疑是中间设备的MTU值较小，导致大包数据无法正常传输。

(二)开发前置机通讯分析

对开发前置机正常通讯数据进行分析，从三次握手过程看到开发前置机和服务器所协商的MSS值为1380字节。而后续的数据传输过程中，数据包的载荷数据都只有1368字节，但是这些数据却能够正常的发送到开发前置机。因此结合前面对生产前置机的故障会话分析，可以肯定中间某个设备的MTU值较小，导致数据包无法分片被丢弃，从而影响生产前置机的正常数据下载。

(三)恢复正常后的会话数据分析

根据所定位的故障原因，再修改生产前置机的MTU值为1300字节后，数据通讯恢复正常，能够正常的下载更新数据包。

案例分析结论

总行网络中某台网络设备的MTU值设置较小，导致大包数据无法正常传输，从而影响更新数据包的下载。

案例：登陆公司公用电脑不小心“中招”

近期，李先生正因为自己的网银被盗而无比烦躁。

事情是这样的，2014年8月5日下午2点左右，正在上班的李先生收到一条来自网银的短消息，称其通过网银快捷支付功能消费了1500元。李先生本以为是诈骗短信，未曾理会，结果到晚上又收到了同样号码的一条短信，这次消费金额是1300元。

李先生登陆自己的网上银行，不看不知道，一看吓了一跳，除了今天的2800元已经确实被盗刷了出去，之前还有不少零星100、200元的消费，5天之内，共计损失人民币6000余元。

李先生随即致电银行，而银行则表示这几笔网上消费均为即时到帐，交易已经成立，无法追回，但是可以帮助李先生追踪消费商家等信息，并且建议李先生马上报警。

不久后，经过银行和警方的配合，以及李先生自己的回忆，终于查出了李先生被盗的原因：李先生在7月底手机临时欠费，而当时正在等客户回电，于是使用公司的笔记本电脑登陆被盗的网银账户，为自己应急充值了100元话费。

而这台电脑为公司公用，且没有杀毒软件，早已潜藏了专门盗取网银的木马，李先生的账户就这样“中招”了。

而这位犯罪分子竟然是个“内贼”，就来自李先生的公司。他盗取了李先生的网银密码后，一开始不敢大额消费，后来发现多次小额消费竟然都没被发现，才大胆盗刷。好在李先生绑定了银行的大额支出短信提醒功能，否则还不知道要被盗刷多少钱。

分析：密码最好常修改短信提醒需开通

案例中的李先生就犯了一系列致命的错误，导致了网银被盗：他使用了公用电脑登录网银，又没有经常修改密码的习惯，且对自己的账户不是很关心，因此直到银行短信提醒，才发觉自己的网银被盗了。

不过李先生有一个做得对的地方，就是他开通了支付短信提醒功能。这个功能大多数银行和支付平台都具备，一定不能嫌麻烦不去开通。这可以让你第一时间得知自己的账户消费信息。

网络账户的安全是网购时代最受人们关注的话题之一。在网络账户安全保障措施不断升级的同时，网络犯罪的手段也越来越刁钻。或许是利用高科技手段钻着百密一疏的空子，或许是打温情牌或恐吓诈骗，最终目的就是要刷走你手中那张小小卡片上的余额。万一你的网银账户绑定着你的信用卡，甚至是大额信用卡，那就更加危险了。

如果把网银比作一个保险箱，那么它的安全性再高，一旦你丢失了钥匙，就没有办法保障安全了。网银的钥匙就是账户和密码，因此一定要保护好自己的账户密码。一旦网银密码被盗，那么你的网银账户就好像没了门的保险箱，自然不再防盗。

6月28日上午，工行某直属一级分行信息科技部员工陆续收到内部通报邮件。该通报就6·23事件的情况及原因作了基本描述，但对事件影响范围、内部处理能力判断均语焉不详。

通报称，“6月23日上午，数据中心(上海)监控发现主机CPU利用率升高，经分析判断与6月23日凌晨实施的主机DB2数据库软件升级版本有关(从V9升级到V10)，在紧急回退升级系统软件版本后系统运行恢复正常。”同时，工行总行信息科技部将该事件直接原因归为IBM公司提供的软件产品存在缺陷，并称这点“经IBM公司正式确认”。

6月23日上午，全国多地中国工商银行柜台、ATM、网银业务出现故障，持续近1个小时。作为服务2。92亿个人客户及400多万公司客户的全国金融服务巨头，工行此次故障波及北京、上海、广州、武汉、哈尔滨等多个大中型城市。

当日，工行将该事故对外模糊描述为：“中国工商银行部分地区因计算机系统升级原因造成柜面和电子渠道业务办理缓慢。”这也是迄今为止工行就6·23事件向用户发布的唯一公开解释。

IBM公开官方资料显示，工行与IBM的合作始于1997年，至今16年之久。针对通报中提及的“经IBM公司正式确认”，记者联系多位IBM相关负责人，但均未得到回应。

工行IT运维能力遭质疑

这份内部通报由一位不愿透露姓名的工行在职员工提供。该员工表示，自己并不太满意这份解释：“对灾难备份只字未提，有意将管理问题规避为技术问题。”

通报也提及了一些管理问题，但表述颇为模糊，通报称，“(数据中心上海)没有按照‘第一时间恢复生产’的要求采取果断措施及时进行回退，并且回退过程不坚决，耗时较长。”

银行的灾难备份系统，是指银行对本地数据中心的数据、业务系统、软硬件等资源进行同城或异地备份，以确保发生某些不可预测的灾难后，重要信息系统的数据安全的一种预防措施。

据中国银行业监督管理委员会(以下简称“银监会”)发布的《银行业金融机构信息系统风险管理指引》，银行业金融机构应制定信息系统应急预案，并定期演练、评审和修订；全国性数据中心要实现异地灾备。

日前，国内最大的灾难备份服务商万国数据CEO黄伟在接受福布斯中文网采访时表示，“银行的IT系统永远面临信息安全的挑战，但悲哀的是，银行在IT系统和灾难备份中不计成本，但遇到这样的大面积的安全问题依然无法在短时间内恢复系统。”他认为，长久以来国内银行的IT系统运作是在给这样的事件埋下伏笔，他最后指出，“在国内银行，IT系统的搭建更像是给上级和银监会看的‘政绩工程’。”

2008年，现任银监会副主席郭利根曾就多起国内银行信息科技风险事件发表讲话。他说，工行等国有银行是国内在IT技术和风险管控上都比较先进的银行，它们的问题频发，“充分暴露出我国银行业信息系统的脆弱性。”

他指出，基础建设滞后、软硬件及核心技术受制于人和系统管理粗放是当时银行业信息科技建设存在的主要问题，“特别是在业务连续性规划、业务恢复机制、风险化解和转移措施、技术恢复方案等方面，存在明显的‘短板’。”

整整五年过去，工行623事件证明了这些问题仍旧没有得到有效解决。