云安全(云安全数据中心、WAF、DDOS)

安全

安全威胁

可用性

安全威胁：大规模分布式拒绝服务攻击(DDoS)、僵尸网络(Botnet)

影响：网站业务不可用
完整性

安全威胁：网站入侵、服务器口令暴力破解

影响：网站页面被篡改和植入后门
保密性

安全威胁：网站后门、数据库非法访问(拖库)

影响：用户帐户信息和敏感数据泄露

CSA发布12大云计算安全威胁：

近几年的安全事件：

事件一：1·21中国互联网DNS大劫难(几乎每一次上网都需要DNS)
2014年1月21日下午3点10分左右，国内很多.Cn域名解析出现异常，超过85%的用户遭遇了DNS故障，引发网速变慢和打不开网站的情况，持续数小时。
事件二：某旅游公司漏洞事件(上旅游网，银行卡信息泄露了)
2014年3月22日，某旅游公司被爆“安全支付日志可遍历下载导致大量用户银行卡信息泄露（包含持卡人姓名身份证、银行卡号、卡CW码、6位卡Bin)“的漏洞。
事件三：某开源软件包心脏出血漏洞(网银、电商、金融、保险)
2014年4月爆出了Heartbleed漏洞，该漏洞是近年来影响范围最广的高危漏洞，涉及各大网银、门户网站等。该漏洞可被用于窃取服务器敏感信息，实时抓取用户的账号密码。

安全体系

安骑士

阿里云安骑士是一款经受百万级主机稳定性考验的主机安全加固产品，支持自动化实时入侵威胁检测、病毒查杀、实时监控进程可疑行为、网站后门，主机异常事件，敏感文件篡改、异常网络连接，异常账号、漏洞智能修复、基线一键检查、网页防篡改等功能，是构建主机安全防线的统一管理平台。

现在已经下线，升级为了云安全中心。云安全中心在安骑士现有功能的基础上，还支持全方位的主机防护、威胁检测与处理、日志分析等功能。

云安全数据中心

云安全中心构建了涵盖网络层、主机层、应用层的安全纵深防护体系，包括网络入侵防护、主机入侵防护、Web应用防护、Web漏洞检测、木马检测等完整的安全防护。安全纵深防护体系利用大数据分析技术，为各个层面的防护系统提供更精确的算法和规则支持。

网络层

在云环境的网络边界，通过流量镜像的方式对出入云平台的所有网络流量进行逐包检测分析。
主机层

实时检测主机资产，及时发现异常进程、异常端口、异常网络连接行为，并定期扫描主机漏洞及配置风险项，全面防护主机资产。
应用层

通过扫描Web漏洞、检测Web攻击、分析应用层访问记录，在保障应用安全的基础上，将应用层发现的信息上报至数据分析集群。

功能：

（1）安全预防

漏洞扫描与修复：主流系统、软件漏洞扫描，并支持漏洞─键修复。
云平台配置检查：基于云平台安全实践，联动云产品能力形成安全闭环。
基线检查：基于阿里云最佳配置核查清单，降低配置不当引起的风险。

（2）主动防御

基于系统内核分析技术实现防勒索、防病毒、防篡改。

防勒索、防病毒：实时拦截已知勒索病毒、挖矿、蠕虫、DDoS等七类病毒
防篡改：防止网站被植入涉恐涉政、暗链、后门等，保障网页正常
应用白名单：防止未经授权的应用异常启动，影响业务正常运行

（3）威胁检测

250+威胁检测模型：提供全链路的威胁检测能力，让黑客无处遁形。
告警自动化分析关联：自动关联告警、识别低危异常形成的入侵，提升运营效率。
安全态势：安全大屏知己、知彼、知威胁多维度展现网络安全态势。

（4）容器安全

镜像漏洞扫描：支持容器镜像的深度漏洞扫描，提供漏洞修复方案。
容器威胁检测：容器运行时刻及容器K8s威胁检测。
容器防火墙：为容器环境提供访问控制策略的智能学习、告警、拦截的—体化网络防火墙服务。

（5）调查响应

基于攻击链自动化回溯攻击源头和原因,快速响应决策

自动化攻击溯源︰自动溯源攻击源和原因，帮用户了解入侵威胁，快速响应
日志分析&审计：提供日志审计、分析能力，提供攻击追溯、合规的平台

WAF(Web应用防火墙)

介绍

Web应用防火墙(Web Application Firewall,简称WAF)是一款网站必备的安全产品。和传统防火墙的区别是，它是工作在应用层的防火墙，主要对web请求/响应进行防护。

传统Web应用防火墙用户的痛点：

用不上：无法应用复杂业务误报机率大
无专人后续运维：产品升级慢、流程复杂不能及时防护最新漏洞
紧急问题响应慢：不能第一时间定位问题原因、影响业务

应用场景：

网站变卡、打不开：恶意海量肉鸡访问网站资源被耗尽
网站数据被恶意爬取、短信流量被滥刷：数据接口被刷，如:短信流量滥刷、用户数据信息被恶意爬取
账号数据、资金损失：官网充值、商品交易、恶意免费/低价成交、盗取用户账户数据
获取服务器管理员权限篡改网站数据、页面：利用最新Oday漏洞、命令执行注入、获取服务器管理权限、获取数据、篡改页面等各种危害

攻击步骤和功能介绍

一个攻击者的目标由大到小，往往是这样：

全网
网络上某一主机
某一主机的数据库
某一主机WEB系统的管理员
某一主机WEB系统其它用户

假设一个WEB网络大致如下：

WEB服务器与浏览器之间已经用传统防火墙防护起来，也就是说，对http://www.a.com进行端口扫描之类的攻击行为已经没用了。攻击者可以通过下面步骤来得到这个网络的信息：

（1）通过OPTIONS,TRACE方法来探测里面的拓扑。如果webserver支持并允许这两个方法，通过检查响应包的Via或Max-forwards字段，可以得到各个节点的域名。

（2）通过检查响应包的Server字段或X-Powered-By字段来确定各个节点的http服务器软件版本和脚本语言解释器版本。同时由第一步得到的域名，也可以到相应域名注册网站（如站长之家）上查找IP。而且有时候，由于网络管理员的疏忽，通向其它节点的路径并没有禁止端口扫描，那样通过端口扫描，可以得到系统信息，如操作系统类型，版本，开启了什么服务。然后在CVE上查询相应版本漏洞和exploit-db上下载相应的payload来攻击，获取主机的控制权。

（3）如果第二步不奏效，也可以通过HTTP的OPTIONS方法来获取网站支持的方法，比如允许DELETE方法，或者PUT方法，那么攻击者可以上传一个脚本获取整个站点的源代码和数据库数据甚至获取整个站点所有主机的权限，或者把认证的脚本给删除。

（4）如果第三步也不奏效，攻击者可能就会扫描所有网页，看是否存在文件路径遍历，文件包含注入，API注入，命令注入之类的漏洞，来获取整个站点的系统信息甚至获取webshell。

（5）如果第四步也不奏效，继续扫描所有页面，看是否有sql注入的漏洞，看能否获取站点的数据库数据或是否可通过数据库执行系统命令，获取主机权限。

（6）如果第五步也不奏效，只能看有没有XSS，url注入等漏洞，能否骗到其它合法用户的权限。或者看能否上传恶意文件。

再思考多一点，如果攻击者并没有打算攻陷a.com或从它偷取数据，而是频繁向a.com发送消耗大量资源的请求，比如请求会使用大量数据库查询的接口，或上传大量文件，导致正常服务无法响应。这种方式叫做CC攻击（ChallengeCollapsar）。

CC攻击（ChallengeCollapsar）：CC攻击其实属于DDoS攻击的一种，这种攻击普遍都是流量不是很高，但是破坏性非常大，直接导致系统服务挂了无法正常服务。频繁向a.com发送消耗大量资源的请求，比如请求会使用大量数据库查询的接口，或上传大量文件，导致正常服务无法响应。主要针对网页攻击。

从性能角度来看，由于HTTP是应用层的协议，每次WAF都要解析它，会造成很大性能损耗。而对于某些经常发恶意请求的IP或进行CC攻击的IP，如果能够在网络层就把它们拦截了，对WAF性能是有很大的提升。所以WAF还必须具备IP黑名单的能力。

有黑名单就有白名单，对于某些资源，如图像，影音，css，js文件，WAF对它们应用规则，只会浪费计算资源和降低服务的响应速度，所以，需要把一些资源URL放在白名单里。

关于IP黑名单，再从安全运维角度来看，如果是IP黑名单是通过手工输入，那么，当攻击者使用IP池攻击，可能会导致IP黑名单的防护攻击失效。那么，如果WAF是支持动态黑名单，就可以很好解决这个问题。如果是由WAF本身产生黑名单，会对WAF性能有很大影响，所以WAF需要能够对接实时计算平台，由实时计算平台产生黑名单回馈给WAF。那么WAF就必须支持与实时计算平台对接的能力。

总体来说，WAF功能有如下：

禁止HTTP协议的非安全方法
伪装Web服务的特征
防止API和命令注入
防止路径遍历和文件包含注入，对敏感的系统路径进行保护
防止sql注入
防止XSS攻击
防止网页挂马
防护CC攻击
文件上传的防护
动态IP黑名单
白名单
与实时计算平台对接

WAF部署模式

WAF也是防火墙，那么它应该是部署在哪里呢？在部署上，它和传统防火墙有什么区别呢？

传统防火墙处理的消息格式大多是格式化，基本上内容都是固定或者索引方式。
而WAF处理的消息是文本，是非格式化消息，都是可变的。在处理这两种不同的消息格式，在性能上的消耗相差非常大。之前测试过，不使用正则，处理http内容匹配比格式化要慢上5-20倍，如果用上正则还可能再慢上20倍。

因此，如果WAF像传统防火墙那样，放置在网络入口，那么，对于DDOS攻击来说，它是很容易沦陷的。

所以WAF一般是部署在防火墙（特别是高防DDOS设备）后面，基本架构如下图：

由于性能差异这么大，所以WAF和防火墙之间还会部署负载均衡设备。

那么，WAF和web服务之间部署还会有什么方式？WAF毕竟也是防火墙，而且它又有web服务的处理能力。所以它有下面四种部署方式：

（1）作为WEB服务器的模块

好处是，由于和WEB服务器结合紧密，对恶意请求的拦截准确率是最高，而且完全可以用ModSecurity或naxis。缺点是，过于分散，不好管理和部署。

（2）作为一台反向代理服务器(主要)。好处是，部署方便简单，集中管理。缺点是，对恶意请求的误判率会上升。

（3）作为一台路由器。好处是，部署方便简单，集中管理。缺点是，也有单点问题，需要双机，同时由于作为一个路由器，需要在用户态上实现协议栈（TCP/IP），维护路由信息，不占用域名，对性能要求更高；且对https支持难度高。因此整体实现难度很高。

（4）作为一台交换机。好处是，部署方便简单，集中管理，不占域名，也不占用IP，也就是说，对攻击者来说，它完全是透明的。缺点是，也有单点问题，需要双机，作为一个交换机，也需要在用户态实现协议栈（链路，TCP/IP），维护转发表，也由于同时防护多个站点，对性能要求高；且对https支持难度高。

在实际应用中，第一种模式基本只是学习者使用，一般用开源的ModSecurity或Naxis较多。第三，第四种模式过于复杂，而且出问题会导致整个子网出问题，也基本没见到使用。第二种模式，基本主流的WAF产品都是采用这种模式。

WAF工作模式

由于WAF一般和业务系统是串联的，并且还是部署在业务系统前面。如果采用反向代理部署模式，假设WAF出现故障，那么会导致单个或者多个站点不可用。这意味着WAF的功能必须是随时可以关闭的。一个WAF往往需要同时防护多个站点，如果把整个WAF关闭，是会导致整体业务群都失去保护。所以，WAF的工作模式必须有对站点随时关闭的模式。

当WAF有新功能或者有新策略发布，是不可以立马把新功能或新策略对现有站点进行防护，需要一段时间来进行观察，看功能是否可用或策略的命中率，漏判率和误判率。如果贸然上线的话，很容易背锅走人的。所以，WAF的工作模式必须有监听模式。

不用说，WAF工作模式当然要有防护模式。这是WAF存在的意义。

那么，这些工作模式如何设计呢？

先从关闭模式看起，对某个站点使用关闭模式，到这个站点的流量就感受不到WAF的存在。一般的做法，是解绑域名，再到web服务上绑定该域名。

这种做法优缺点如下：

优点
- 由于web服务和WAF完全分享，WAF的故障不会影响到web服务。
- 少了WAF这个中间节点，web服务的响应速度不受影响。
缺点
- 解绑和重绑，涉及到接入备案过程，流程较长，生效时间较长。
- 原先隐藏在内网的web服务集群对公网开放，除了web应用本身的攻击面，还增加了主机层面的攻击面，增大了整体网络的攻击面。

关闭模式也有一种快速生效的实现方式。这种实现方式和监听，防护两种模式的实现很统一。

这种方式的优缺点如下：

优点
- 不需要进行域名解绑和重绑，生效时间快
- 不会增加整体网络的攻击面
缺点
- 流量还是要经过WAF，对web服务响应速度还是影响
- 流量要经过WAF，所以WAF的故障也会影响到web服务

由于一个IP可以对应多个域名，一个域名也可以对应多个IP，对针对每个域名来配置工作模式，WAF必须要获取到http请求的URL或头部的host字段。WAF解析完http/https，拿到了请求的域名，再根据域名的配置，决定是否送去过规则还是直接传递给web服务。所以，WAF的http/https模块解析要和规则引擎模块分开。

所以，WAF的关闭模式如下图：

同样，WAF的监听模式是既过规则，也会直接传递给web服务，大致如下图：

最后，WAF的防护模式是直接过规则，不会直接传递给web服务，大致如下图：

规则引擎原理

WAF无非就是拦截有害请求和伪装响应，出于性能考虑，拦截有害请求又分为两个层面，由网络层拦截和由应用层拦截，且任何请求应该先在网络层过滤再到应用层过滤。也就是说，规则引擎分为两块，对请求过滤和对响应过滤，而对请求过滤分为两大步，网络层过滤和应用层过滤。

原理图大致如下：

（1）请求部分

网络层
- 白名单：很多时候部署在WAF后面的应用，需要测试接口对非法输入的处理，但又不想关闭对该站点的监控，为了防止WAF对测试活动的影响，对来源IP和目标IP设置白名单，绕过WAF的拦截。从性能角度来考虑，白名单过滤功能是不可能放在其它过滤功能后面，那么它应该是规则引擎在网络层过滤的第一步。
- 黑名单：同样，对于已知有害的来源IP，是越早拦截越好，出于性能考虑，黑名单拦截功能应该在网络层，那么它应该紧跟在白名单后面。
应用层
- https拆解：随着https越来越普及，WAF需要对https请求和响应进行检测和过滤，所以，WAF必须支持使用证书对https内容进行拆解。
- http方法防护：不少http方法是有安全风险的，如果webserver的配置有问题，如果不在这一步拦截掉，而url白名单的来源IP又可能被攻击，那么就可以存在站点沦陷的风险。一般是拦截除了HEAD，GET，POST之外的方法
- url白名单：由于某些接口（如请求某些静态资源）并不会存在漏洞，没必要对这些url进行规则过滤，或者防护站点某些url接口有所更新，需要特定的来源IP进行测试。应当存在url和来源IP对应的白名单
- url黑名单：同样由于某些接口的实现可能会涉及大量运算，可能需要对该url访问进行次数限制，需要存在一个url和次数的黑名单。
- http请求解码：http请求很多时候对头部和内容的数据往往会进行编码，如url编码，html编码，js编码，十六制编码，base64编码，主要是为了传输一些二进制数据，或攻击者用于绕过各种防护设备。只有对数据进行解码，才能够知道它真实的payload。所以需要对http请求进行解码。
- http请求头部过规则：GET，HEAD方法的参数都是紧跟URL，这个阶段就可以进行过滤，而且先对请求头部过滤，也是基于性能考虑。毕竟请求url参数和头部都是key-value方式，解析相对比内容要快。
- http请求内容过规则：POST方法的参数基本都是放在请求内容里。

（2）响应部分

响应头部过规则：响应头部有不少字段会泄露背后服务的关键信息，如server会泄露webserver软件及版本，x-powered-by会泄露cgi语言和版本（PHP，Python,Perl,Ruby之类），Via和Max-Forward会泄露WebServer的拓扑。为了避免攻击者利用这些信息攻击，需要对响应头部某些字段进行屏蔽或伪装。
响应内容过规则：这一部分也叫做软补丁功能。为什么呢？如果webserver的应用服务抛异常了，并把异常信息显示在页面，这是一种常见的信息泄露。如果需要研发团队来修改和测试，运维团队对该服务进行打补丁上线，整个过程可能持续几周，存在很大的风险窗口。如果在WAF上，对这些信息进行伪装或屏蔽，就可以极大降低安全风险。更加不用那些会泄露用户信息，金融信息等服务。

WAF动作

WAF每条规则都会配置动作，对命中规则的请求进行对应的处理。

每个WAF产品对动作定义不大一样。

（1）ModSecurity定义了allow, block, deny, drop, pass, pause, proxy, redirect

allow: 命中了某条规则后，不需要对请求/响应应用其它规则，直接让请求通过。这个可以用于白名单。
block: 并不是一个真正的动作，它的行为取决于配置的默认动作，如果默认动作更新，使用block的规则行为也随即改变。在安全响应方面，它可用于批量进行规则作为更新。
deny: 中断规则处理，拦截请求/响应。在客户端的角度来说，这个动作会返回4xx或5xx的状态码（取决于规则定义status)，但并没有中断当前的连接
drop: 对当前tcp连接进行关闭操作，它和deny的不同是：deny之后，客户端仍然可以提交请求，但使用drop后，客户端只有重新连接才可以访问。这个动作可以节省后端服务的连接数
pass: 命中某条规则继续匹配下一条规则。可用于对请求进行精细地过滤，但会对响应速度有较大影响。
pause: 命中某条规则，对当前事务暂停指定的毫秒。一般用于防止登录爆破。如果遭受DDOS攻击，会恶化整个web服务的响应速度
proxy: 把命中规则的请求转发到另外一个web服务去。这个功能类似反向代理。由于它对客户端完全来说，完全是无感知，可以用它导向请求到蜜罐系统。这个动作是一个非常优秀的动作。
redirect: 当规则被命中，它会返回一个重定向，指示浏览器访问另外一个url。它和proxy的区别是，它对客户端是感知。可用于配置新上线接口或屏蔽某些有问题的接口。

（2）Naxsi定义了accept, block, drop

accept: 对应ModSecurity的allow，一旦命中立马放行
block: 对应ModSecurity的deny
drop: 对应ModSecurity的drop

（3）华为云WAF定义了allow, deny, redirect

accept: 对应ModSecurity的allow，一旦命中立马放行
deny: 对应ModSecurity的deny, 默认返回418
redirect: 对应Modsecurity的redirect

（4）openrestyl lua WAF定义了allow, deny，drop， redirect

accept: 对应ModSecurity的allow，一旦命中立马放行
deny: 对应ModSecurity的deny，默认返回403
drop: 对应ModSecurity的drop
redirect: 对应Modsecurity的redirect

其中华为云WAF和openresty lua WAF，在实现pass动作，都是通过规则组来实现。

对于动作配置方面，有这样的建议：

在功能开发方面，drop最好能够先返回一个状态码再停止掉整个连接，drop, deny状态码尽量可以通过规则配置。
在配置规则时，对于drop, deny的状态码，每条规则或规则组都返回不同的状态码。

这样做的好处是：

有效隐藏WAF的特征，让攻击者无法确认是否有WAF存在
当出现规则误拦截时，可以根据返回码快速定位是哪条规则误拦截。这是从无数次背锅感悟出来的血的教训

WAF规则

首先，WAF规则的定义是什么？

从前面的内容可以看到，基本上，WAF处理http分为四个阶段：请求头部，请求内容，响应头部，响应内容。那么WAF规则就是，定义在某个阶段WAF对符合某种条件的http请求执行指定动作的条例。

根据这个，WAF规则必须要包含这些元素：过滤条件，阶段，动作。由于http消息在传输过程中会对数据进行某种编码，所以，WAF规则往往也需要定义解码器。同时为了审计作用，WAF规则往往定义id，是否对结果记录，以及字段抽取，命中规则的严重级别所以，一条WAF规则往往包含：id, 解码器，过滤条件，阶段，动作和日志格式，严重级别。

以一条ModSecurity规则为例：

SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\bsys\.user_catalog\b" \ "phase:2,rev:'2.1.3',capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,t:replaceComments,t:compressWhiteSpace,ctl:auditLogParts=+E, \ block,msg:'Blind SQL Injection Attack',id:'959517',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1', \ tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score}, \ setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"

翻译成XML：

<rule><id>959517</id><version>2.1.3</version><description></description><severity>2</severity><phase>2</phase><decoder>none, urlDecodeUni,htmlEntityDecode,lowercase,replaceComments,compressWhiteSpace</decoder><condition><field>REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/*</field><operator>regex</operator><pattern>\bsys\.user_catalog\b</pattern></condition><action>block</action><tags></tags><log><format></format><varibles></varibles></log>
</rule>

规则之间的关系非常复杂，特别过滤条件是使用正则表达式的，往往是会有包含关系，如[0-9]+包含了[1-2]+。那么，假设规则a先加入WAF，后面又新增了条规则b，在语法上，b的过滤条件包含了a，而且在配置上，不小心放在a前面，那么，就会出现误判的情况。

误判和漏判，是很常见的问题。但在严重程度上，却是不一样。

漏判，可能会造成恶意请求绕过WAF，跑到业务后台，但在业务后台加上其它安全措施，却可以缓解威胁。误判，则是直接在WAF把正常请求给拦截掉，影响正常的业务。曾经某大厂重要业务部门上WAF，由于误判，导致正常交易只有50%成功，几上几下之后，WAF团队的人基本干掉了。

所以，在测试环境，WAF规则要越严格越好。但在生产环境，对有把握的规则才维持原样，其它规则尽量放宽松一些。

虽然WAF规则可以设置一个id用于追溯，这远远不够，因为无法追溯是由哪个消息触发，规则对消息处理的顺序是怎样。所以，一个稳妥的规则引擎，应当在http消息接收时，在头部增加一个消息id，当消息离开WAF前，删除掉这个消息id。通过这种方式，可以很好追溯到每条消息会触发哪些规则，触发结果是怎样。当出现误判情况下，也可以立马知道是哪些规则有问题，顺序是怎样，规则定义是否合理。

DDOS

介绍

DOS：Denial of Service，即拒绝服务，目的是耗尽网络带宽和服务器资源，使网络、主机不能提供服务，电子邮件服务器、DNS 服务器和机构都可能成为攻击目标。

DDOS：分布式拒绝服务(DDoS:Distributed Denial of Service)攻击指借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动DDoS攻击，从而成倍地提高拒绝服务攻击的威力。

类型

常见的DDoS攻击包括以下几类：

网络层攻击：比较典型的攻击类型是UDP反射攻击，例如：NTP Flood攻击，这类攻击主要利用大流量拥塞被攻击者的网络带宽，导致被攻击者的业务无法正常响应客户访问。
传输层攻击：比较典型的攻击类型包括SYN Flood攻击、连接数攻击等，这类攻击通过占用服务器的连接池资源从而达到拒绝服务的目的。
会话层攻击：比较典型的攻击类型是SSL连接攻击，这类攻击占用服务器的SSL会话资源从而达到拒绝服务的目的。
应用层攻击：比较典型的攻击类型包括DNS flood攻击、HTTP flood攻击(CC攻击)、游戏假人攻击等，这类攻击占用服务器的应用处理资源极大的消耗服务器处理性能从而达到拒绝服务的目的。

DDOS攻击应对策略

（1）定期检查服务器漏洞

定期检查服务器软件安全漏洞，是确保服务器安全的最基本措施。无论是操作系统（Windows或linux），还是网站常用应用软件（mysql、Apache、nginx、FTP等），服务器运维人员要特别关注这些软件的最新漏洞动态，出现高危漏洞要及时打补丁修补。

（2）隐藏服务器真实IP

通过CDN节点中转加速服务，可以有效的隐藏网站服务器的真实IP地址。CDN服务根据网站具体情况进行选择，对于普通的中小企业站点或个人站点可以先使用免费的CDN服务，比如百度云加速、七牛CDN等，待网站流量提升了，需求高了之后，再考虑付费的CDN服务。

其次，防止服务器对外传送信息泄漏IP地址，最常见的情况是，服务器不要使用发送邮件功能，因为邮件头会泄漏服务器的IP地址。如果非要发送邮件，可以通过第三方代理（例如sendcloud）发送，这样对外显示的IP是代理的IP地址。

（3）关闭不必要的服务或端口

这也是服务器运维人员最常用的做法。在服务器防火墙中，只开启使用的端口，比如网站web服务的80端口、数据库的3306端口、SSH服务的22端口等。关闭不必要的服务或端口，在路由器上过滤假IP。

（4）购买高防提高承受能力

该措施是通过购买高防的盾机，提高服务器的带宽等资源，来提升自身的承受攻击能力。一些知名IDC服务商都有相应的服务提供，比如阿里云、腾讯云等。但该方案成本预算较高，对于普通中小企业甚至个人站长并不合适，且不被攻击时造成服务器资源闲置，所以这里不过多阐述。

（5）限制SYN/ICMP流量

用户应在路由器上配置SYN/ICMP的最大流量来限制SYN/ICMP封包所能占有的最高频宽，这样，当出现大量的超过所限定的SYN/ICMP流量时，说明不是正常的网络访问，而是有黑客入侵。早期通过限制SYN/ICMP流量是最好的防范DOS的方法，虽然目前该方法对于DdoS效果不太明显了，不过仍然能够起到一定的作用。

（6）网站请求IP过滤

除了服务器之外，网站程序本身安全性能也需要提升。以小编自己的个人博客为例，使用cms做的。系统安全机制里的过滤功能，通过限制单位时间内的POST请求、404页面等访问操作，来过滤掉次数过多的异常行为。虽然这对DDOS攻击没有明显的改善效果，但也在一定程度上减轻小带宽的恶意攻击。

（7）提供余量带宽

通过服务器性能测试，评估正常业务环境下所能承受的带宽和请求数。在购买带宽时确保有一定的余量带宽，可以避免遭受攻击时带宽大于正常使用量而影响正常用户的情况。

（8）服务安全加固

对服务器上的操作系统、软件服务进行安全加固，减少可被攻击的点，增大攻击方的攻击成本：确保服务器的系统文件是最新的版本，并及时更新系统补丁。