服务器托管要比自行维护更安全。服务器托管不会因为共享主机，而引起的主机负载过重，导致服务器性能下降或瘫痪。在独立主机的环境下，可以对自己的行为和程序严密把关、精密测试，将服务器的稳定性提升到最高。共享主机时，对于不同的用户会有不同的权限，这就存在安全隐患。在独立主机的环境下，可以自己设置主机权限，自由选择防火墙和防病毒设施。、

对于安全防护来讲，我这里按照从源头到服务器内部的顺序，依次梳理出防护的措施。对于目前的服务器来讲，很多服务器是已经做了这里大部分的安全措施的，有一些措施可能还没有做。当然，鉴于本人水平有限，壹基比小喻这里列出的肯定没有完全覆盖，

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

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

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

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

一、安全防护：

1.源头控制（ip）

-封闭式：限定访问的IP（指定服务器才能访问即授权访问）

-开放式：白名单IP允许

-开放式：黑名单IP禁止

-开放式：业务行政物理地址外IP禁止（IP定位），消除代理攻击

-开放式：业务行政物理地址内IP允许（IP定位），消除代理攻击

2.端口控制

-知名端口：常用的知名端口，如80，修改知名端口或关闭不必要知名端口。

-匿名端口：采用不常用的端口号，端口不连号。

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

-手机端：只会在手机端使用的接口，不对其他终端响应

-PC端：都可以访问

-特定场景：特定场景使用的接口不暴露，且做场景分析控制，非场景下不允许使用

4.频率控制

-访问间隔：连续访问间隔控制

-周期间隔：周期内访问间隔控制

-周期访问次数：周期访问次数控制

-特定场景访问次数控制：特定场景次数分析

5.请求地址控制

-不存在的地址控制

-恶意攻击地址控制

6.参数控制

-多余的参数：多余的参数分析和记录

-SQL攻击：SQL攻击

-XSS攻击：js脚本攻击和url检测

-参数取值：合理取值范围和类型

7.流程控制

-流程漏洞控制，确保没有流程空白

-多接口混合使用形成的流程漏洞控制

8.缓存控制

-缓存更新漏洞机制

-缓存不同步漏洞控制

9.bug错误控制

-异常控制

-异常暴露

-异常流程控制

-bug对设计的冲击控制

10.系统协作控制

-多端协作流程漏洞控制

11.分布式控制

-数据一致性漏洞

-其他

12.服务器漏洞

-漏洞检测和修复