服务器的安全防护，这个是保证服务器稳定运行必须做好的工作。

    对于安全防护来讲，我这里按照从源头到服务器内部的顺序，依次梳理出防护的措施。对于目前的服务器来讲，很多服务器是已经做了这里大部分的安全措施的，有一些措施可能还没有做。当然，鉴于本人水平有限，我这里列出的肯定没有完全覆盖，如果您有补充欢迎在文章底部留言。

    最源头自然是发起请求端的客户端，请求则是通过IP来定位服务器的。我们服务器的IP自然是公开的，而客户端的IP则是不确定的。我们如果通过分析和控制客户端的IP，也就将安全遏制在源头。

    然后就是要对端口进行控制。过了这两关，也就进入了服务器的内部逻辑了。我们就可以对应用场景进行分析控制，频率更要控制，其他的就更加细致了。

    最后就是安全措施，一般有三种：停止响应，节省性能；拉黑处理，以后只要是这个IP就不响应；对于不能大刀阔斧干的，就控制频率，延迟一段时间才能访问。

    下面是一个简要的清单，后续将逐个解释控制的原理和流程。再最后就是针对每一种控制，提出实现方案。

    需要说明的是，本系列文章分为原理阐述和代码实现。原理阐述部分在本站 C++技术网 更新，而代码实现则是因为使用python写的，所以会更新在 Python技术网。两边合起来是一个完整的系列文章。

一、安全防护：
1.源头控制（ip）
- 封闭式：限定访问的IP（指定服务器才能访问即授权访问）封闭式详解见：《服务器安全防护1-源头控制场景分析-封闭式IP控制》

- 开放式：白名单IP允许
- 开放式：黑名单IP禁止
- 开放式：业务行政物理地址外IP禁止（IP归属地），消除代理攻击
- 开放式：业务行政物理地址内IP允许（IP归属地），消除代理攻击

开放式讲解见：《服务器安全防护2-源头控制场景分析-开放式IP控制》

2.端口控制
- 知名端口：常用的知名端口，如80，修改知名端口或关闭不必要知名端口。
- 匿名端口：采用不常用的端口号，端口不连号。

3.请求标志控制

- 必要的请求需要进行认证（如token），token可以基于IP、时间戳、用户名、密码摘要等相关信息合成

- 接口账号秘钥，每一个能够调用接口的人都需要具备一个特定的秘钥字符串，秘钥字符串在后台登记过，无秘钥则属于非法调用。

- OAuth2.0，这是非常典型的安全控制机制，这里不赘述。

4.应用场景控制(手机或PC和其他)

- 手机端：只会在手机端使用的接口，不对其他终端响应。需要分析适用的场景，确保不要误杀。
- PC端：都可以访问。
- 特定场景：特定场景使用的接口不暴露，且做场景分析控制，非场景下不允许使用。

5.频率控制
- 访问间隔：连续访问间隔控制，如30秒内接口只能调用一次，比如发短信界面本身就有计时等待。
- 周期间隔：周期内访问间隔控制，一段时间内连续访问的间隔。比如开启了缓存，一个接口在一段时间内是不会再被访问的，APP可能会保证这个效果。然而被破解后可以人工直接调用接口导致。
- 周期访问次数：周期访问次数控制，一定时间段内次数是有限的。超出正常范围，则属于异常的攻击行为。
- 特定场景访问次数控制：特定场景次数分析，有些特定场景，只在特定操作触发了才会执行，频率应该极低的，如果被大量执行，必然就是不正常的。

6.请求地址控制
- 不存在的地址控制，很多恶意攻击，可能会去请求不想关的地址，来探测。对于系统不可能出现的接口或页面，凡是发现这样的攻击，则都可以直接拦截并记录下来。
- 恶意攻击地址控制，严重的则会直接上传脚本攻击，有可能你的网站是asp.net做的，有人会上传php脚本来尝试攻击。这是用软件做的常规攻击，可以严格控制。

7.参数控制
- 多余的参数：多余的参数分析和记录，接口的参数总是有限的，很多都是固定的。多余的参数就不是正常提交的。在程序的设计里，不应该存在的参数出现了，必然是恶意提交的。此类情况就可以进行拦截。
- SQL攻击：SQL攻击，这个就不多说了。大家可以自行百度。
- XSS攻击：js脚本攻击和url检测， 这个就不多说了。大家可以自行百度。  
- 参数取值：合理取值范围和类型，参数必然有一个合理的范围，比如气温，正常的不会到100度，否则人活不了。在尝试攻击的时候，在合理范围内的值，一般是不会出错的，不出错也就没有漏洞。而如果不在预定的范围内，可能就会异常而崩溃。所以这个检测哈可以防止SQL攻击等。

8.流程控制
- 流程漏洞控制，确保没有流程空白，这属于设计上的问题。
- 多接口混合使用形成的流程漏洞控制，多个接口一起组成一个功能，在交互的过程中非常容易产生漏洞。特别是一个不正常另外一个是否能够正常确保不产生漏洞。参与的接口越多，越复杂，越容易出漏洞。

9.缓存控制
- 缓存更新漏洞机制，缓存可以加快速度，同时会增加数据不同步的问题。不同步之后就可能产生一些漏洞。比如用户会员到期应该失效了，但是缓存数据还是有效会员。这是一个简单的例子。这是在设计时和编码时需要考虑到位的。
- 缓存不同步漏洞控制，缓存在多个地方需要同步操作，如果多个地方都控制一个缓存项，则可能多操作或者漏操作，这都会导致缓存不同步。这个可以采用统一控制的方式，最终只有一个地方来直接控制，其他地方都是委托方。更多是需要在逻辑上严谨一些。

10.bug错误控制
- 异常控制
- 异常暴露
- 异常流程控制
- bug对设计的冲击控制，bug是意料外的错误，通常会导致意想不到的现象。系统设计的是否完整安全，需要将bug的情况考虑在内，先要防止bug出现，二是出现了bug也要合理处理，最后是即使没有捕捉到异常，也不至于将问题延续下去，可以极大降低损失。

11.系统协作控制
- 多端协作流程漏洞控制，在一个整个系统体系里，涉及到手机端、PC端、小程序端、硬件端、服务器端等等，多端配合非常复杂，每一端本身都可能存在很多难以攻克的问题，只能尽力完善，而多端配合如果设计不当，则很容易造成很大的漏洞。

12.分布式控制
- 数据一致性漏洞，这个和缓存的数据不一致问题类似。而且会更复杂，因为分布式涉及到多节点的控制。当然，缓存也可能涉及到分布式缓存。
- 其他

13.服务器漏洞
- 漏洞检测和修复，服务器系统安装的各种软件和服务是否存在安全漏洞，要及时更新和修复。

二、保护措施：
1.拒绝服务：当次停止响应，减少性能消耗
2.拉黑：后续全部停止响应
3.限制降频：降低允许访问的频率