node SSR服务怎么预防和处理DDos攻击
发布时间：2023-08-02 11:00:46 所属栏目：教程 来源：转载
导读： 本篇内容主要讲解“node SSR服务怎么防范和处理DDos攻击”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“node SSR服务
|
本篇内容主要讲解“node SSR服务怎么防范和处理DDos攻击”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“node SSR服务怎么防范和处理DDos攻击”吧! DDos攻击是什么？ 举一个常见的例子，我们的网站，比作一家银行，正常情况下，银行最多可以同时处理100个人的业务，正常你直接走进银行，取个号，就能被服务了 突然有个流氓组织想收保护费，银行不肯给，于是流氓派出3000个人甚至3万个人同时去取号。过了号继续取号。结果就是导致服务器处理不过来，大量正常客户一直在等待 这就是 DDOS 攻击，它在短时间内发起大量请求，耗尽服务器的资源，无法响应正常的访问，造成网站实质下线。 DDOS 不是一种攻击，而是一大类攻击的总称。它有几十种类型，新的攻击方法还在不断发明出来。网站运行的各个环节，都可以是攻击目标。只要把一个环节攻破，使得整个流程跑不起来，就达到了瘫痪服务的目的。 其中，比较常见的一种攻击是 cc 攻击。CC攻击就是针对网页来攻击的，CC攻击本身是正常请求，网站动态页面的正常请求也会和数据库进行交互的，当这种"正常请求"达到一种程度的时候，服务器就会响应不过来，从而崩溃。 如何防范？ 先了解一个请求打进来到我们服务之间的路径 业务服务集群作为服务链路的底层和核心资产，完备的上层防护是非常重要的 将恶意流量拦截在外层后，业务集群就不用频繁运维（扩缩容，限流等），降低运维成本 业务集群也无需额外准备过多的资源应该攻击流量，节约成本 具备很好的通用性，容易移植到其他服务，带来稳定性收益 防范的手段也按这个顺序介绍 接入CDN层 nginx限流 接入WAF防火墙 其他防护层 提高源站的处理能力。 针对SSR服务，有2个建议 让ssr服务只处理根HTML的返回，其他的所有资源都要放到CDN上去 当攻击来临时，临时把SSR的降级到CSR 1. 接入CDN层 CDN层会在最外层，方便紧急时刻，开启CDN缓存，或开启CDN付费项目来保护内部其他服务的安全。举个例： 比如百万，千万级别或更大的瞬时流量打进来，有可能把负载均衡层给打挂了，这样会影响整个公司的业务，就不仅仅是被攻击的那个服务了 CDN的防护能力有：CDN缓存，Robot检测，ip信誉库，构建自定义防护规则集（结合历史的攻击特征和业务形态） 等 （按付费等级开启） 另外提一嘴（个人观点），CDN厂商在全球有数不清的服务器，大的CDN厂商几乎能低于一切攻击，而且还会按保护等级收费（保护费）。我个人觉得，一些攻击很可能就是CDN厂商勾结黑产做的，相当于流氓收保护费，不交保护费，就砸店（攻击），让你知道痛了，然后乖乖买CDN保护服务。而且能发动千万级别以上的QPS，除了CDN厂商（本身就有超多服务器），普通人应该很难 2. nginx限流 3. 接入WAF防火墙 这两个放在一块讲吧，也是偏向于运维层面，是公司级别的基建，具体的接入方式 和 具体配置 公司之间各有差异。也就不展开讲了 nginx限流是什么？ 可以自行搜索 总结一下WAF层，会通过预置丰富的信誉库，对恶意扫描器、IP、网马等威胁进行检测和拦截 全面的攻击防护：支持SQL注入、XSS跨站脚本、文件包含、目录遍历、敏感文件访问、命令\代码注入、网页木马上传、第三方漏洞攻击等威胁检测和拦截。 人机识别 接口限速，WAF可以根据IP或cookie设置灵活的限速策略 基于丰富的字段和逻辑条件组合，精准控制 支持丰富的字段条件：基于IP、URL、Referer、User-Agent、Params等HTTP常见参数和字段的条件组合。 支持多种条件逻辑：支持包含、不包含、等于、不等于、前缀等于、前缀不等于等逻辑条件，设置阻断或放行策略。 4. 其他防护层 不同的公司，对应不同的业务及自身的特点，可能还会有其他的防护层，比如针对单实例还有过载保护（判断当前服务状况是否过载，然后根据流量的优先级会动态的丢弃掉一些低优先级的请求，尽可能保证服务的正常运转） 此处还有很多种防护层，有兴趣可以额外再去了解 5. 提高源站的处理能力 打铁还需自身硬 这个很好理解，提高服务的处理能力，自然能承接更多的流量 针对SSR服务，有以下几个建议 建议一：让ssr服务只处理根HTML的返回，其他的所有资源都要放到CDN上去 对于ssr服务，这里给一个很重要的建议 让ssr服务只处理根HTML的返回，其他的所有资源都要放到CDN上去 这里直接以juejin举例子就很好理解了，我们可以从下图看到，juejin本身也是SSR服务，源站只处理了根HTML，其他所有资源（js，css，图片，字体等）都是放在CDN上的。 这样做的目的也是为了提高源站的处理能力，让CDN承担了很多压力 建议二：当攻击来临时，临时把SSR的降级到CSR SSR渲染时，是比较耗费CPU计算的（需要编译和解析生成HTML），所以ssr服务的QPS能力都不高。面对攻击时很容易被打挂 解决办法：临时把SSR的降级到CSR 怎么做SSR的降级？ 降级为CSR（客户端渲染），这样就不用再服务端生成复杂的HTML了，只需返回简单的HTML。CSR 就是单页应用，举个最简的例子就是 ui组件库，下图也可以看到，这个HTML十分简单，是静态的，返回这个静态的HTML不用怎么消耗服务端资源 并且还可以将根HTML文件，缓存在内存中，这样可以让服务端的处理能力提升几十甚至上百倍 6. 其他 例如可能还有弹性扩缩容能力，这个只能抵御小流量攻击 被攻击后如何紧急处理？ 都已经被攻击，服务开始很缓慢了，甚至直接被打挂了，这时候做代码层的优化已经来不及了，只能做一些运维层的配置 1. 扩容 只能应对小流量的攻击 2. 升级防护策略 这个有点涉及商业秘密... 不太敢写，有兴趣的朋友可以自行搜索，或问一下公司运维 反正有一点，是我猜的。一般乖乖给CDN交钱后，后面可能就没攻击进来了，即使有，也可能只是些小流量，且好防护的攻击 3. 开启CDN缓存 ssr服务，如果平常访问的时候，没有开启CDN缓存的话，被攻击时，可以临时打开CDN缓存。 （编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
推荐文章
站长推荐
