弘协网络 | F5技术交流

博文精选 |系统安全高可用总结

2021-08-27 10:00:30

F5小安

PHPWord

文章速览:

 

行业:互联网

 

关键字:系统安全、高可用、攻击、防护、防御手段、防火墙

 

摘要:系统安全高可用总结

 

阅读时长:12分钟

 

 

以下文章来源于InfoQ!作者:Mars

 

 

安全架构:web 攻击与防护


XSS 攻击





XSS 攻击防御手段


消毒:XSS 一般是在请求中嵌入恶意脚本达到攻击目的,这些脚本是一般用户输入中不使用的,如果进行过滤和消毒处理,即对某个 HTML 危险字符转义,如“>”转义为”&gt”、”<”转义为”&lt”等,就可以防止大部分攻击。为避免对不必要内容错误转义,如” 3<5”中的”<”,需要进行文本匹配后再转义,如:”<img src=”这样的上下文中才转义。实际上,消毒是所有网站最必备的 XSS 攻击防御手段。


SQL 注入攻击




获取数据库表结构信息的手段


l  开源:使用开源软件搭建,网站数据结构公开,攻击者可以直接获得。


l  错误回显:如果开启错误回显,攻击者恶意构造非法参数,服务器异常信息会输出到浏览器端,为攻击者猜测数据库表结构提供便利。


l  盲注:攻击者根据页面变化情况判断 SQL 语句执行情况,据此猜测数据库结构情况,此攻击难度较大。


注入攻击防御手段


消毒:通过正则匹配过滤掉数据中可能注入的 SQL。


SQL 预编译参数绑定:绑定参数是最好防 SQL 注入方式。


 

CSRF 攻击




CSRF 攻击防御手段


表单 token:CSRF 是一个伪造用户请求的操作,需要构造用户请求所有参数。表单 token 就是阻止攻击者获得所有请求参数的可能,在调单中增加一个随机数 token,每次 token 都不同,请求提交后检查 token 的值是否正确以确定请求提交者是否合法。


验证码:简单有效,请求提交时,需要用户输入验证码,以避免在用户不知情的情况下被攻击者伪造请求。但输入验证码是一个糟糕的用户体验,所以必要的时候才使用,如支付交易等关键页面。


Referer check:HTTP 请求头的 referer 域中记录着请求来源,可通过检查请求来源,验证是否合法。但该方法有一定局限性,referer 也不一定总能得到。


其他需关注的攻击和漏洞


Error Code:也称错误回显,许多 web 服务器默认是打开异常信息输出的,即服务器端未处理的异常堆栈信息会直接输出到客户端浏览器,这种虽然对调试和错误报告有好处,但同时给黑客造成可乘之机,通过故意制造非法输入,使系统运行出错,获得异常信息,从而寻找系统漏洞进行攻击。


防御方式也很简单,通过配置 web 服务器参数,跳转 500 页面到专门错误页。


HTML 注释:程序开发人员为了调试方便会在 PHP、JSP 等页面程序中使用 HTML 注释语法进行程序注释,这些 HTML 注释会显示在客户端浏览器,给黑客造成攻击便利。程序最终发布前需要进行代码 review 或自动扫描,避免 HTML 注释漏洞。


文件上传:如果上传文件是可执行的程序,并通过该程序获得服务端命令执行能力,那么攻击者几乎可以在服务器上为所欲为,并以此为跳板攻击集群其他机器。最有效的防御手段设置文件上传白名单,只允许上传可靠文件类型。此外还可以修改文件名、使用专门的存储等手段,保护服务器免受上传文件攻击。


路径遍历:攻击者在请求的 url 中使用相对路径,遍历系统未开放的目录和文件。防御方法是将 js、css 等资源文件独立服务器、独立域名,其他文件不使用静态 url 访问,动态参数不包括文件路径信息。


开源 web 应用防火墙 ModSecurity


Modsecurity 是一开源 web 应用防火墙,探测攻击并保护 web 应用程序,既可以嵌入到 web 应用服务器中,也可以作为独立的应用程序启动。


网站安全漏洞扫描


扫描工具是根据内置规则,模拟黑客攻击行为,用于发现网站安全漏洞的工具。


安全架构:加密与解密


信息加密技术及密钥安全管理


信息加密技术分为三类:


l  单向散列加密:加密后的密文,不可还原明文。


l  对称加密:加密、解密使用相同密钥,通过解密算法可以算出明文。


l  非对称加密:加密密钥和解密密钥不同。例如:1. HTTPS 技术,使用公钥加密,私钥解密;2. 区块链技术使用私钥加密,公钥解密,正确解出密文,证明交易有效。

 


安全架构:反垃圾与风控


反垃圾邮件


对已分类的邮件,通过分类算法训练出一个分类模型,通过分类算法识别是否垃圾邮件。


贝叶斯分类算法


贝叶斯算法解决概率论中一个典型问题:1 号箱放红色球和白色球各 20 个,2 号箱放有白色球 10 个,红色球 30 个,现随机挑选个箱子,取出一个球的颜色是红色的,请问这个球来自 1 号箱的概率是多少?


贝叶斯公式:



布隆过滤器黑名单


利用比特位,可以使用 2G 存储空间,存储 2G 个数据。有可能会错判,但不会漏判。


风控系统


电子商务系统,大致分为以下几种:


l  账户风险


l  买家风险


l  卖家风险


l  交易风险


规则引擎


当交易某些指标达到一定条件,会被认为具有高风险欺诈行为,如:


l  用户来自欺诈高发地区;


l  交易金额超过阈值;


l  和上次交易地址距离差距很大;


l  登录地和收货地不符;


l  用户第一次交易;


机器学习


规则引擎虽然技术简单,但随着规则逐渐增加,出现规则冲突,难以维护等情况。规则越多,性能越差。大型互联网,倾向使用机器学习模型进行风控。


高可用:可用性度量


可用性指标


网站年度可用性指标=(1-网站不可用时间/年度总时间)*100%


网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点


对可用性的定性描述,两个 9 是基本可用;3 个 9 是较高可用;4 个 9 是具有自动恢复能力的高可用;5 个 9 是极高可用,年度停机小于 5 分钟。


故障处理流程及考核





引起故障的原因


l  硬件故障


l  软件 bug


l  系统发布


l  并发压力


l  网络攻击


l  外部灾害


高可用:提升系统可用性的架构方案


解耦


l  高内聚、低耦合的组件设计原则


l  面向对象基本设计原则


l  面向对象设计模式


l  领域驱动设计建模


隔离


l  业务与子系统隔离


l  微服务与中台架构


l  生产者与消费者隔离


l  虚拟机与容器隔离


异步


l  多线程编程


l  响应式编程


l  异步通信网络编程


l  事件驱动异步架构


备份


l  集群设计


l  数据库复制


l  CAP 原理


Failover(失效转移)


l  数据库主主失效转移


l  负载均衡失效转移


幂等


服务重复调用时不可避免的,必须 保证服务重复调用和调用一次产生的结果相同,即服务具有幂等性。


事务补偿


l  传统事务 ACID


l  分布式事务 BASE


基本可用(Basic Availabilty),软状态(soft-state)、最终一致性(Eventual-consistency)


通过执行业务逻辑逆操作,使事务回滚到事务前状态。


重试


远程服务由于线程阻塞、垃圾回收或者网络抖动,而无法及时返回响应,调用者可以通过重试的方式修复单次调用的故障。


上游调用者超时时间要大于下游调用者超时时间之和。


熔断


当某个服务出现故障,响应延迟或失败率增加,继续调用这个服务会导致调用者请求阻塞,资源消耗增加,进而出现服务级联失效,这种情况使用断路器阻断对故障服务的调用。


断路器三种状态:关闭、打开、半打开


限流


在高并发场景下,如果系统访问量超过系统承载能力,可通过限流进行保护。如果超过系统最大处理能力,就会丢弃一部分用户请求,保证大部分用户能够访问系统。


限流几种算法:


l  计数器算法(固定窗口、滑动窗口)


l  令牌桶算法


l  漏桶算法


自适应限流


实时自动评估 QPS。


业务流量的不确定性与技术方案的自适应性天生一对。





降级


非核心功能关闭,减少系统压力。


异地多活


如果数据中心城市遭遇地震,机房遭遇火灾或停电等不可控的因素,一般采用异地多活多机房架构策略,异地多活难点是数据一致


高可用:架构运维方案


自动化测试


目前大部分网站采用 web 自动化测试技术,使用自动测试工具或脚本完成测试。比较流行的 selenium 运行在浏览器中,模拟用户操作进行测试,可以同时完成 web 功能测试和浏览器兼容测试。


自动化部署


开发人员开发完功能后,提交代码到 git 仓库,自动测试部署。


持续部署三步走


l  持续集成:允许工程师随时向公共分支提交代码,并立即进行自定化测试。


l  持续交付:除了跑单元测试及软件包,持续交付机制会将软件部署到各种测试环境中。


l  持续部署:代码在没有人工干预的情况下被测试、构建、部署并推送到生产环境。


预发布验证


预发布机器是一种特殊用途服务器,和生产服务器的区别是没有配置在负载均衡服务器上,外部用户无法访问。


代码版本控制


主干开发、分支发布


代码修改都在主干上进行,需要发布时,从主干上拉一个分支发布,该分支即成为一个发布版本,如果该版本发现 bug,继续在该分支上修改发布,并将修改合并回主干,直到下次主干发布。


分支开发、主干发布


任何修改都不得在主干上直接进行,需要开发一个新功能或修复一个 bug 时,从主干拉一个分支进行开发,开发完成测试通过后,合并会主干,然后进行主干发布,主干上代码永远是最新发布的版本。


自动化发布




灰度发布


将服务器集群分成若干部分,每天发布一小部分,期间如果发现问题,就只需要回滚已发布的一部分服务器即可。


灰度发布不只保障系统高可用,还保障系统业务的持续发展。


网站运行监控


尽早发现问题,为问题发现提供数据查询。


用户行为日志收集


日志收集手段有 2 种:


l  服务端日志收集


l  客户端浏览器日志收集


报警


       监控管理系统可以配置报警阈值和值守人员,报警方式包括:邮件、手机短信、手机语音,及时在夜间也能及时通知,迅速响应。


自动控制


l  自动失效转移


l  自动扩容


l  自动限流


监控系统监控架构




高可用故障案例分析


故障 1


故障现象:


应用服务器集群发布后不久就出现多台服务器相继报警,硬盘可用空间低于警戒值,并且很快有服务器宕机。登录到线上服务器,发现 log 文件夹里的文件迅速增加,不断消耗磁盘空间。


原因分析


应用开发人员将日志 log 输出的 level 全局配置为 debug。这样一次简单的 web 请求就会产生大量的 log 文件输出,在高并发用户请求下,很快消耗完不多的磁盘空间。


故障 2


故障现象


某应用发布后,数据库 load 居高不下,远远超过正常水平,持续报警。


原因分析


检查发现,某条 SQL 引起的,但是这条 SQL 是一条简单的有索引的数据查询,不应该引起报警。继续检查,发现这条 SQL 执行频率很高,被首页调用,所以频繁执行。


经验教训


l  首页不应该访问数据库,需要从缓存服务或搜索引擎服务器获取。


l  首页最好是静态的。


故障 3


故障现象


某应用服务器不定时的因为响应超时而报警,但很快又超时解除,恢复正常,如此反复。


原因分析


某个单例对象多个方法使用了 synchronize 关键字,由于 this 对象只有一个,即使执行不同方法,所有的并发请求也都要排队获取这唯一一把锁。所有用户线程都要等待,每次执行都需要较长时间排队执行。


经验教训


l  使用锁要谨慎,特别注意有锁的方法长时间 IO 操作时。


l  针对不同场景,使用不同锁对象,而不是所有方法上都简单加上 synchronize。


 

故障 4


故障现象


无新功能发布,用户并发请求也没突然增加,但是数据库服务器突然 load 飙升,并很快失去响应,DBA 将数据库切换的备机,Load 也很快飙升,失去响应,最终引发网站瘫痪。


原因分析


缓存服务器在网站集群中地位一直比较低,服务器配置和管理配置级别都比其他服务器要低一些。由于人们认为缓存是改善性能手段,丢失一些也没什么问题,结果由于误操作关闭了缓存服务器的全部服务,导致网站瘫痪。


经验教训


l  缓存不仅仅改善性能,而是网站不可或缺部分,对缓存重视级别要提高。


 

故障 5


故障现象


服务发布后,立刻崩溃。


原因分析


Web 应用程序使用 Apache+JBoss 模式, 用户请求通过 Apache 转发给 Jboss,再发布时,Apache 和 Jboss 同时启动,由于 Jboss 启动时需要加载很多应用并初始化,花费时间较长,结果 Jboss 还未启动,Apache 就开始接收请求,大量阻塞在 Jboss 进程中,最终导致 Jboss 崩溃。


经验教训


l  应用启动时,一定要先查看依赖服务是否可正常提供服务。


 

故障 6


故障现象


某应用主要功能是管理用户图片,接部分用户投诉,上传图片非常慢,有时等待半天结果浏览器显示服务器超时。


原因分析


图片需要使用存储,检查服务器发现,大部分文件只有几百 k,而有几个文件非常大,有数百兆,读写一次大文件需要 10 多秒,磁盘基本都被这个文件操作独占,导致其他用户操作缓慢。


经验教训


l  图片应该都是小文件,应该使用专用服务器进行存储,不能和大文件存储共享。


 

故障 7


故障现象


监控发现,某个应用突然变慢,内网网络访问。


原因分析


生产环境进行性能压力测试,占据了大部分交换机带宽。


经验教训


l  访问线上生产环境要规范。


l  数据库中数据更正,要走正常数据订正流程。


 

故障 8


故障现象


应用发布后,数据库 load 负载飙升,超过警戒值,回滚发布后报警消除。


原因分析


发布应用后,数据库大量读操作,检查发现,由于测试需要,特意注释读缓存的代码,最终导致注释代码上线前未修改,直接提交到代码库。


经验教训


l  代码提交时要用 diff 命令比较,确保没有提交不该提交的代码。


l  加强 code review,代码在正式提交前至少被一个工程师 code review,并承担因代码引起的故障责任。


故障 9


故障现象


新功能发布后,少量用户投诉功能不可用,一点就出错。


原因分析


分析发现,这些用户都是第一次使用,程序根据历史记录构造一个对象,如果该对象为 null,就会导致 nullPointException。


经验教训


l  程序在处理一个输入的对象时,如果不明确该对象是否为空,必须空指针判断。


l  程序在调用其他方法时,输入对象尽量保证不是 null,必要时构造空对象。


 

 

以上是针对系统安全高可用的分享,希望对大家有帮助!

 

 

 

阅读原文

 

声明:本文章版权归原作者及原出处所有 。凡本社区注明“来源:XXX或转自:XXX”的作品均转载自其它媒体,转载目的在于传递分享更多知识,内容为作者个人观点,仅供参考,并不代表本社区赞同其观点和对其真实性负责。本社区转载的文章,我们已经尽可能的对作者和来源进行了注明,若因故疏忽,造成漏注,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本社区拥有对此声明的最终解释权。

 

 

 

你还不能错过:

 

发布评论 加入社群

发布评论

相关文章

Login

手机号
验证码
© 2019 F5 Networks, Inc. 版权所有。京ICP备16013763号-1