取消
显示结果 
搜索替代 
您的意思是: 
cancel
2407
查看次数
0
有帮助
2
评论
julianchen
Spotlight
Spotlight

周末女神跟我说她已经备好了购物车也把该付的定金付了。这是几个意思?是不是暗示我该发挥安信人员的角色,为她的双十一购物保驾护航了?我似乎get到了什么,马上开始研究,写下了如下的技术要点。

兵法曰:故知战之地,知战之日,则可千里而会战。

有个电商平台运维的朋友曾坦言:每到十月底,一想到各种爆款、爆买、爆单、爆仓就有些肉疼,生怕哪个环节出了故障,被卖家们齐声指责:“原来你是这样的电商平台”。那么如何才能沉着应对流量的井喷、处理海量的订单、保障整个网站系统的安全和稳定呢?让我来给您慢慢拨开这个“洋葱”看看吧。

本人认为安全稳定无非是两个方面:网站系统的平稳运行和攻击发生时的应对。我们先来看看:网站系统平稳运行,它主要依赖于如下方面的综合支撑:

· 稳定的机房物理环境和完备的基础设施保障。无论是自建的还是外包出去的,大家都可以参考类似于GB50174《数据中心设计规范》之类的要求进行自查或要求外包中心提供出详检报告。另外,对于一些要求高且实力雄厚的土豪可自行脑补同城一主三从的模式。

· 齐备的网络防护硬件设备和统一且细粒度的网络监控平台。特别是分布式网络环境中,全链路的网络状态监控与分析可以有助于及时发现问题点和瓶颈点,提升问题的定位效率。适当的时候,可以通过人工干预等方式灵活进行网络资源调配。还记得纠正前些时的1021日,美国东部大面积网络瘫痪事件吗?一天之内,美国主要域名服务器供应商Dyn遭到了三波DDoS的网络攻击,什么FacebooktwitterspotifyCNN都登录不上去了。简单反思一下,这说明如果你有一个配置好了异地的备用DNS服务器是多么的重要啊!当然,如果您想了解更多网络方面的加固经验,请出门左转,参考一下本网站每周连载的《廉环话--漫谈信息安全设计与治理》,那里有很多实际经验方面的小贴士。

· 大促当天,各种数据势必会雪崩式的猛增,因此硬件方面的扩容、升级,是越早准备越好。当然也要有合理的预估,尽量避免仅仅为了应对这次单次峰值的批量机器采购现象的发生。特别是在存储方面,在云平台服务盛行的今天,可以通过自我容量的现状评估,提前购买和签订云资源的弹性扩容协议。

· 在我们技术中人看来,双十一大促就是一个时间紧、任务急、要求高的IT项目。所以诸如:问题管理、变更管理、发布管理、配置管理等日常项目的管控是统统可以适用的。值得特别注意的是,任何对平台硬件配置和软件程序上的修改都要事先做两轮以上的测试而且是压力测试。具体方法可以借鉴日志收集式的线下压力测试与流量导出式的线上压力测试相结合来实施。正如华为总裁任正非最近说道的“自己做的狗食要自己先吃”那样,通过接近于真实场景的压力测试,很多细节问题会自行暴露出来的。

· 人员支持方面,如果不想让您和您的团队当天有种感觉身体背掏空的感觉的话,请务必分配好专人专岗通过监控软件去获取数据量,并掌握趋势曲线,以及必要的时候采取的人工干预限流、链路切换等措施都。整个团队中一起,通过brainstorm或是参考他山之石等方式,提前申请好必要的资源,比如说事先准备一个warroom等。

· 结合平时的BCPDRP制定当天的应急预案,多用“ifthen, else if then”这样的程序化模式和言简意赅的流程图的表现方式,不要忽略了call tree的定义。当出现事故的时候,人员的应变能力和判断能力可能会现场受限,因此需要人手一份的严格按步骤执行,井然有序的提前先做几次沙盘演习,并查缺补漏排除盲点。

· 在程序代码开发方面,一般做法都是前端只做展示,不进行逻辑处理。因此页面上的一次链接点击,在后端可能会产生几十次的RPC调用,Web、服务化、缓存、消息队列、DB…因此任何一个环节出了故障都可能导致剁手党们用脚投票,从而转投它商。有过开发经验的小伙伴都知道在开发高并发系统时,可用“三宝”来保护系统,即:缓存、限流和降级。一般顺序是:先有缓存这个常态机制,后有限流来应对高并发和瞬间流量对系统的强大冲击,与此同时,按需降级来实现网站的有损服务而不是不提供服务哦。

o 缓存:可以利用浏览器的缓存、CDN缓存、服务端应用的本地缓存、缓存服务器集群的一致性哈希以及服务端分布式缓存的多级缓存化机制来提高缓存的命中率,并减少带宽消耗。

o 限流:可以限制瞬时并发数、限制总的并发数(比如数据库连接池、线程池)、限制时间窗口内(如每秒)的平均速率、限制远程接口调用速率、限制消息队列的消费速率等。另外还可以根据网络总连接数和流量、服务器CPU或内存的负载等方面来进行限流。

o 降级:可以根据系统日志里规定的级别,如一般、警告、错误、严重错误等来定义,自动或人工的相关设置,实现对页面、读操作、写操作的降级。毕竟是双十一的抢购当天,很多用户实际上都已经把货品放入了购物车,所以在真实情况下一般不会再去花时间浏览商品的详情页上的推荐内容甚至是评价之类的信息,所以完全可以把商品详情内容以及评价暂时不予加载和展示给买家,所以这对购物流程是不会产生明显影响的。

针对不同种类的限流和降级,页面显示也可有所不同。可以是将买家导流到排队页面、等一会重试的排队页面;也可以直接告知买家没货了;亦或为“活动太火爆了,稍后重试”的错误页面。总之,丢卒保车总要好过全军覆没。

常言道:上医治未病,我们再来看看攻击发生时的应对,这里主要着眼的是网站程序代码的方面。

· 入境检测

o 对输入的网站请求进行实时分析(包括各个特征字段,post-process分析等)。

o 检测在用户填写并提交到网站上的信息内容里是否包含恶意的链接(挂马)。

o 打开HTTP审计日志并分门别类写到不同的文件中。

o 只记录有意义的请求,也就是说可以适当忽略如图片文件之类,被攻击的危险性相对较低且没有参数的请求。另外,在日志中应屏蔽掉如登录密码、信用卡等敏感数据,并集中到中央日志服务器上,以免被非法获取。

· 分析请求

o 对请求体里的类型(Content-Type)进行勘察,识别出畸形请求体(特别是XML类型)。

o 别请求是否进行过多次编码,甚至是为了增加伪装性的畸形编码。

o 检测是否有异常的浏览器请求头部(如hostuser-agentaccept)信息和顺序(比如不同浏览器的host位置不同)。

o 检测是否有多余的参数,丢失的参数,重复的参数名,异常的参数长度和参数字符集等。

o 借用现成的或是构建自己的黑名单(RBL)来识别恶意IP地址。

· 请君入瓮

o 添加蜜罐端口,来检测是否有可疑的流量。

o 在页面上添加假的HTML注释、假的表单隐藏字段、以及假的cookie,这样既可误导攻击者也可在这些数据被修改时联动报警。

o 针对网络爬虫,添加虚假的robot.txtDisallow条目,以诱惑访问disallow的目录,并记录以便分析。如果有时间和经历的话,甚至可以制作一些假的认证机制和页面。

· 出境检查

o 对输出的页面数据添加额外的哈希值,以避免被中间人篡改。

o 检测异常的响应头部。比如:网站响应的网页面上频繁出现HTTP 4XX5XX的错误,则可能是攻击者通过发来的有问题请求或处理来对网站进行扫描和侦查。另外,攻击者通过操纵Apache.htaccess文件,以HTTP 3XX的响应,把请求重定向到恶意网站。

o 检测响应头部和响应体是否信息泄露,这一点技术上有必要,但实际上对于双十一请求量大的时候就要做好检测的优化了,不然会影响响应速度。另外,这种检测多适用于文本内容,而对于MIME类型的二进制格式也可能会有误报或漏报。

o 检测页面标题是否被变更,页面大小是否有偏差。因为当Web页面被篡改时,最终的页面可能比正常小得多;而当攻击者成功进行了SQL注入攻击并对数据进行大量拉取时,页面则又会大很多。所以可以设置上限和下限的阈值。当然,此检测也可能会误报,比如有商品的详情页面随着评论的迅速增加而递增。还是上述观点:双十一当天应该不会出现该情况,因为大家抢购还来不及何谈评论?

o 检测动态内容是否被变更,主要监控页面上javascriptiframeimage以及超级链接的标签数量。

o 检测是否存在源代码的泄露,比如:用户在网址后面添加入?-s之类特殊字符,是否会反馈网页的源代码?

o 检测网址返回的错误信息提示里所包含的网址结构等信息。

最后提醒一点的是:万一真的出了故障,信息公开方面要及时。在这个迅速传播发酵的时代,如果你还想遮遮掩掩的话,那就基本上可以狗带了。

评论
13nash
Level 8
Level 8
安全阵营,攻坚战大象
one-time
Level 13
Level 13
翻出了去年双十一大神写的帖子,不过时,顶起~
入门指南

使用上面的搜索栏输入关键字、短语或问题,搜索问题的答案。

我们希望您在这里的旅程尽可能顺利,因此这里有一些链接可以帮助您快速熟悉思科社区:









快捷链接