Herbrhythm

互联网上用户最多最活跃的是大型科技巨头，如Apple,Google,Facebook,腾讯，阿里的巨型社区，但数量最多的是大量中小公司和组织的网站。这些网站往往实际用户不多，甚至每天爬虫和扫描的请求远超正常用户的数量，但为了各种实际业务需求不得不维持和更新。这些网站也是最容易被各种黑客恶意攻击的对象。同时，由于这些网站的维护者预算，人手，精力和技术都比较有限，所以，在处理网站安全问题上，方案并不使用大型企业的哪一套规范制度。

我们根据经历过的各种被攻击的经验，实际业务场景，以及各种等级保护的精力，整理了一套适用小型网站实际情况的安全防护方案。

目标分析

小型网站的安全防护的主要特点是

• 预算有限，一般仅有1-2台服务器，不会采购大量安全产品。
• 人员有限，一般是1-2个半全职甚至兼职的技术人员进行维护。也没人负责最新CVE的跟进。
• 技术有限，没有大量安全产品的最佳实践经验。
• 访客少，交互少，主要用于信息/产品的展示，而非与用户互动。
• 信息更新频率低，更重视信息的准确新。

小型网站面临的主要安全威胁是

• 页面挂马，被嵌入各种广告/赌博/色情网站信息。
• 内容被篡改，被发布各种谣言/反动/影响商誉的信息。
• 机器被黑，数据丢失，性能下降，被用作攻击源，被服务商警告/关停。
• 被CC攻击，大量请求造成服务器无法响应，过多请求导致服务器OOM最后kill数据库导致站点崩溃，资源被滥用导致大量费用。

安全防护的策略

根据上述对中小型网站的分析，我们认为这类网站的安全防护策略应该着重如下特点。

• 被动防御为主，主动介入防御为辅。因为技术人员的精力和技术水准，很难及时做好技术层面的主动防御。
• 以站点一定出现安全问题为基准，而非不切实际的做好完美安全防护。实际上就算大公司也时不时会出现很多安全事故，精力财力有限的小公司做完美的防护可以说是空中楼阁。能控制风险，做到降低安全问题出现的频率，降低出现安全问题的损失就是很好的方案了。
• 隔离为主。从网络到程序，尽可能的进行隔离。一方面增加攻击者的难度，另一方面锁定被攻击成功后的损失。

方案概览

本方案的概览如下

• 端口白名单
• IP物理隔离
• 定期更新与升级迁移
• 尽量使用静态页面
• 使用WAF
• 对非GET请求采用白名单
• 尽量避免使用php/wordpress
• 慎重使用spring程序
• 上传文件使用对象存储服务
• 做好备份
• 定期漏洞扫描

系统漏洞防护措施

系统漏洞防护的主要思路是坚壁清野，将IP/端口都隐藏起来。

这样哪怕有漏洞无法直接修复，也能因为攻击方无法连接到服务器，延缓被攻击的可能，然后在定期升级更新时修复漏洞。

安全组(防火墙)端口 白名单

防火墙白名单是安全的第一步，也可以说是最重要的一步。对于非专业IT人士来说，端口白名单能解决80%的系统漏洞(开发语言和代码的问题无法解决)问题。

对于标准的Linux服务器，一般端口的开发情况应该为

• 不限ip的80端口(http服务)
• 不限ip的443 端口(https服务)
• 限制ip的22或修改过的ssh端口

SSH端口可能的话必须限制ip，哪怕你是动态拨号ip，也应该在每次维护时登陆网页设定下当前ip。毕竟连服务器ip的频率一般并没有那么高。

如果有其他访问服务器其他端口的需求，比如直接mysql等，建议不要直接开发对应端口，可以ssh -D 的转发功能，通过ssh通道进行访问。

IP隔离

IP隔离分为两个部分，公网IP和内网IP

公网ip很简单，就是在互联网上要保护好机器的实际ip,绝大部分情况不该通过ip访问。

最佳方案就是在服务器适用云服务商的WAF。如果不能接受大部分WAF的后付费模式，可以开启一个低配服务器，使用雷池之类本地WAF做反代转发。

当然，如果是无备案网站，或者非主域名，对访问速度要求没那么高的，可以套 https://www.cloudflare.com/ 的免费cdn+防火墙，cf是全球最著名的cdn/waf供应商之一。

内网IP隔离主要是防止云供应商的其他用户对内网机器进行遍历扫描，一般的云供应商都有VPC功能,确保开通服务器时使用了自己的VPC子网就好。

定期系统更新/系统迁移升级

对于非专业人员而言，及时的安全补丁更新未毕很容易，一般做一个定期计划即可，遇到比较大的漏洞再做紧急更新。在这种场合下，安装的服务应该尽量使用系统源/Docker/snap等进行安装。而不要用下载/编译的安装方式，这样打补丁时会比较痛苦。

系统迁移升级是另一很容易踩坑的话题。一般来说，普通开发人员的安全升级依赖于系统更新。这种情况下，需要选择合适的发行版，一般是LTS(长期支持)的Linux发行版，比如Debian,Ubuntu LTS。但LTS也总有失去支持的时候，所以在系统失去支持时进行迁移升级是一个很常见的场景。但没有准备的迁移是一件很痛苦的事情，所以在部署时应该提前做好准备，具体来说，措施包括:

• 可能的情况下，使用Docker以及响应的安装脚本来进行服务的安装。由于和系统足够解耦，在迁移时很容易能够迁移走。
• 在部署时，将数据和配置都放在一个固定的文件夹内，通过ln -s 软连接的方式对接到系统里，确保在迁移时不会丢了什么数据和配置。操作系统的归操作系统，应用的归应用。
• 进行服务的安装，不论是Docker/Systemd或者是其他系统服务的设置，尽量通过脚本而非手动的方时进行，这样在迁移时只需要确保脚本能正常执行就行。

注:本方案以Linux环境为主。对于Windows Server环境来说，如果不是强依赖于Windows生态，可以使用Caddy/Supervisord之类轻量级的系统服务取代IIS和服务组件。以一定的性能和功能换取迁移的便利性。

良好的部署习惯能降低迁移升级的难度，保证系统更新的安全性，是很容易忽视但却很重要的安全措施。

最后，对于一般使用的云环境，不建议做跨系统的大版本升级。先不说很云厂商可能会使用共享/指定内核的虚拟化技术，大版本升级往往会需要很长的停机修复时间，一般更多还是采用备用服务器升级，再取消原服务器订阅的方式。

应用层防护

系统层防护可以说是十分简单容易的体力活，一些基本策略就能起到很好的效果，但是服务器上跑的应用，才是大部分漏洞破坏力最大的地方，也是最难防护的地方。

对于站点的攻击，一般分为针对性的入侵和广撒网漏洞扫描。

针对性的入侵，中小网站的运维人员往往只能尽人事，听天命，做好备份，降低损失，多保留证据。真被高手盯上，这不是不够专业的运维人员能解决的。

中小网站的运维人员主要能做的还是对于自动化扫描入侵的防护，用通用的盾防通用的矛。

对于常见的漏洞扫描，在服务器的HTTP访问日志上很明显能看到分为几类

• 知名软件的漏洞
• 知名软件的登陆/接口的密码爆破
• 知名软件的评论/提交接口
• 常见备份文件位置
• 常见配置文件位置

所以，我们一般可以采取一些基本的防护措施。

尽量使用静态页面

对于一般的网站需求，我们建议，如果可以的话，大部分页面应该采用纯静态的html生成方案，配合一些livechat/crm表单的第三方接口方案。

这种方案能满足大概80小网站的需求。

国内网站主要的需求就是

• 展示内容，新闻，产品
• 搜索
• 表单提交

表单提交其实在国内的应用范围很窄，国内用户一般更习惯livechat或者微信公众号。

搜索的话，属于理论上需要的功能。实际用户最多有产品的搜索需要，将产品信息存静态JSON文件做个自动补全一般就能满足需求了。

实在不行的话，可以通过跨域方式调用第三方API。

一定要使用动态内容的话，静态页+Headless CMS可能也是不错的方案。

出于安全原则和国内监管需要，正常情况下中小网站应该不能用任何形式(评论/留言)等将用户互动显示出来。如果有硬性的需求，建议使用独立域名+国外服务器+cloudflare,与主站点进行隔离。

使用WAF防护

WAF指WEB应用防火墙。本质时一个反向代理中转，根据实现设定的规则(访问和响应的特征)，将可以的访问者进行阻断。

WAF能防护很多流传较广的通用漏洞。

一般来说，国外服务器直接用cloudflare的防护，国内有预算用云服务商的WAF，没预算本级自建WAF。

但在使用WAF后要注意一点。

WAF不是万能的，甚至可以说用处很有限，只能防护对基本的扫描，对于针对性的入侵作用即为有限。

最大的作用时体现在保护源IP和防止CC攻击/爬虫上。

非GET请求白名单

由于GET正文长度和默认缓存策略的限制，从网站访问日志也容易分析出。大部分的攻击都是通过POST或者其他的HTTP METHOD发起的。

所以建议对非GET请求进行白名单，确定对公众开放的接口才对所有IP开放。内部管理用的接口限制本机，然后通过 SSH -D 或者 SSH -L 进行代理访问。

这些限制一般是通过HTTP服务软件进行的，可以根据你使用的HTTP，在APACHE/NGINX/CADDY的响应配置里做设置。

尽量避免使用php程序，特别是wordpress

php很强，wordpress很厉害，很多大公司都在用，非常流行，但是，我们觉得，只有专业的，有经验的IT人员，才能做好php/wordpress的安全防护。

php，以及当年的asp，最大的优势是它通过CGI的形式调用，不用考虑内存泄漏，还能方便的进行热更新。但这也是它安全方面最大的缺点。分析访问日志能够发现，很多入侵就是通过安全防护的漏洞，上传php的webshell，然后修改index.php，使得整个站点被黑。这在所有网络攻击里都属于特殊的。一般的攻击是针对数据的，php可以针对代码。

而Wordpress，作为最知名的php CMS系统，强大点在于利用php的热更新系统建立的，可以说是最强大的插件系统上。但无数的插件也引入的更多的漏洞。大部分用户连审查使用的Wordpress版本的代码都做不到，更不提每个WP站点都使用的大量插件了。

对于一定要使用PHP的场合，建议除了其他防护，还要做到整个程序的只读。程序尽量不要拥有程序区域的写入权限，最好没有任何区域的写入权限，哪怕是临时目录。

慎重使用Spring程序。

Java本身是一个很能打的语言，Spring本身是个很强悍的框架和生态。它最大的问题是，太卷了，以至于很多库都会实现很多用不着的边缘功能。

不论是当年Log4j的注入bug,还是fastjson的各种bug，都会让人反思，是否需要这么高级的功能。

所以，使用Spring的程序，我们建议还是慎重，有些漏洞的确比较需要想象力。

上传文件使用对象服务

站点入侵的主要目的就是修改数据/执行程序。

执行程序这一部，入口就在用户上传上。

使用对象服务进行上传，使得上传工作和APP运行环境独立，甚至可能是不同的服务器上，这样就将服务器入侵的损害降低到了最低。

不同的云服务上都有基于AWS S3的对象服务提供。如果需要本机附件，也可以使用min.io自建。

隔离不同的服务

不同的服务，比如数据库，附件，应用，应该进行必要的隔离。

同一台服务器的话，最简单的方式是通过Docker进行隔离。

如果把适合上Docker环境的话，需要合适的设置各服务的执行用户和用户组(Systemd .service文件里设置)，并做好目录的权限设置。

这样，当一个服务被攻破时，至少其他服务不会直接受影响.

数据备份

数据备份是普通IT人员应对入侵的最后最可靠的保障。

甚至可以说数据备份是普通IT人员应对入侵的唯一可靠手段。

备份包括几个层面

• 代码。一般使用git管理。但有可能的话，将二进制可执行文件也备份一下是个好习惯。很多时候，将老代码编译成老程序，未必那么容易。
• 数据库。如果是Mysql的话，脚本定期mysqldump+2进制日志就能做到很好的备份了。数据实时性要求搞的可以做通过2进制日志的热备份,这样就算磁盘物理层面的问题也顺带解决了。
• 附件。这个数据量太大，一般不备份。尽量不要开放删除权限即可。
• 配置。rsync/git/tar 管理都可以。这个一般变动较少
• 系统。在与服务商那里开一个快照备份，对于不能下线的服务是个很好的备份方式。

定期漏洞扫描

定期漏洞扫描就是利用扫描程序查看站点是否有什么公开的漏洞。

漏扫工具我们选择的是开源工具ZAP

官网地址

ZAP支持多种漏洞 扫描，支持使用无头浏览器扫描JS站点，支持生成html/pdf格式的报告，十分强大。

注意，漏扫时需要使用最新版本的漏扫工具，不然扫描意义大打折扣。

总结

对于普通网站的IT人员来说，安全方案的核心就是 勤备份，定期升级，保护IP和端口，内部做好隔离避免被一锅端。

防止被入侵，更防止入侵后造成巨大损失，不要存有侥幸心理。