:fire: 你的服务器够安全吗
目录
:fire: 你的服务器够安全吗
一份不一定很全的服务器安全防范措施, 但值得看看. (╯-_-)╯~╩╩.
文章地址:
前言
本文分享了一些十分有用的服务器安全防范措施, 欢迎补充.
阅读本文你能收获到:
一些服务器安全防范的措施.
快乐 (如果学习能使你快乐的话 (~.~) )
一. 防火墙
防火墙采用白名单策略, 只开放必要端口. 如: 80/443 以及 SSH 登录端口.
而数据库, 缓存等端口, 最好只允许本地访问, 若需要调试, 建议使用白名单 IP, 代理等方法进行连接.
二. 利用内网穿透工具
参考文档: https://github.com/fatedier/frp/
对于有调试需求的服务器而言, 数据库, 缓存, 消息队列等端口需要开放. 而直接开放端口会给服务器带来不必要的安全隐患. 此时我们必须对访问者进行限制, 如: IP 白名单, VPN 等. 除此之外, 笔者推荐一个内网穿透工具用来辅助建立调试环境 -- FRP https://github.com/fatedier/frp
FRP 是一个可用于内网穿透的高性能的反向代理应用, 有多种穿透方式, 可以指定端口进行代理. 我们可以在服务器启动服务端 (frps) 和客户端 (frpc) 两个服务, 本地客户端的 frpc 通过 frps 监听的唯一端口与服务端的 frpc 建立连接, 这样就能将服务器上只能内部访问的端口映射到开发者电脑本地端口.
使用 FRP 的优势: 指定端口, 可压缩流量, 可加密, 服务端只需要暴露 frps 的端口.
三. 隐藏无用信息
参考文档:
- ). http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_hide_header
- ). http://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens
- http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_hide_header
通过服务器返回的信息, 攻击者能从中发现一些漏洞, 比如 nginx 版本, 所使用的 web 服务器等. 而这些信息对于用户来说都是非必要的. 笔者随便找了个网站查看, 如图:
这些细节都可能为攻击者提供途径. 所以有必要屏蔽掉这些信息.
proxy_hide_header {Your-Header} : nginx 中, 通过 proxy_hide_header 可以隐藏掉上游服务返回的某些 header.
server_tokens off : 是 nginx 版本信息开关, 可以开启或隐藏 错误页 或 header 的 Server 字段后面带的版本号.
fastcgi_hide_header X-Powered-By : 如果您使用的是 PHP-fpm, 这个配置可以隐藏掉 header 中 PHP 及版本信息.
配置完成后执行 nginx -s reload 后配置即生效.
四. 限流
参考文档:
用户正常的访问行为, 不会产生过于频繁的请求, 限流可以防止 某些不安分的 IP 因某些目的而频繁访问服务器而导致资源耗尽, 影响正常用户的访问体验.
一般地, 我们可以通过 nginx 配置 进行限流:
- http {
- limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
- ...
- server {
- ...
- location /search/ {
- limit_req zone=one burst=5;
- }
limit_req_zone... : 设置一个大小为 10M 的共享区域, 命名为 one , 其 KEY 为 $binary_remote_addr 即 IP, 访问速率限制为 1 次 / 秒.
limit_req... : 路径为 search 的 location 使用共享区域 one 进行限流, 突发请求限制为 5. (如果只限制了 1r/s, 将会严格按照每秒一次的请求进行限制, 但对于用户来说, 点开网页可能会并发请求数个资源, 如此死板的限制对于体验并不友好, 所以我们还需要设置突发的请求限制)
五. 祸水东引
总之一句话, 引流到扛得住高并发的静态页. 比如 GitPage.
参考文章: 我是如何通过 Nginx 日志实时封禁风险 IP 的 https://juejin.im/post/5dd10c2c6fb9a020156232b5
相信不少站长都了解被 cc 或 ddos 攻击支配的恐惧.
尤其对于个人主页等小站来说, 购买高防服务器或购买各种防护服务可能性价比并不高. 但普通服务器遇到稍大规模的攻击(也许这规模并不是真的很大), 可能服务器直接就挂了, 就算配置了页面的静态缓存, 也不一定能扛得住多大规模的攻击, 况且流量挺贵的.
对此笔者的方案是:
ipset+iptables
之所以对于一般危险等级的 IP 进行重定向, 主要目的是:
节约流量, 节约服务器资源(这点对动态网站尤为重要)
劝退攻击者: 大家无冤无仇, 您去找更好搞的站点攻击, 请不要在这里耗费太多时间.
防止误杀, 异常 IP 评估可能存在误差, 直接封禁对于访问者而言极其不友好, 会白白损失用户. 服务降级总比不提供服务要好. 故选择先临时重定向, 若该 IP 行为仍旧不规范, 此时再封禁也不晚.
可以参考我的前一篇文章 《我是如何通过 Nginx 日志实时封禁风险 IP 的》 https://juejin.im/post/5dd10c2c6fb9a020156232b5
- sequenceDiagram
- participant Nginx
- participant Filebeat
- participant Redis
- participant Monitor
- participant Actuator
- Nginx ->> Filebeat: accessLog(File)
- Filebeat ->> Redis: accessLog(JSON)
- loop Always
- Redis ->> Monitor: accessLog(JSON)
- activate Monitor
- Monitor ->> Monitor: Analysis
- Monitor ->> Monitor: Risk assessment
- Monitor ->> Actuator: Banned
- Monitor ->> Monitor: Storing
- end
- deactivate Monitor
六. 禁用 root 远程登录
禁止使用 root 用户远程登录, 仅允许某个权限少的普通用户远程登录, 登录后再执行 su 提权.
对于允许远程登录的账户, 建议不要使用密码登录, 更不能使用简单密码 . 建议使用秘钥登录.
SSH-keygen 生成秘钥对, 将公钥放入 authorized_keys 文件中即可.
七. 其他
定期备份, 建议使用 crontab 配置备份定时任务. 并且定期将重要数据冷备份.
及时更新系统, 修复安全漏洞.
只安装需要的, 用不着就关闭
结语
服务器安全事大, 对于开发, 运维, 测试等工作来说, 安全都是重点关注的问题, 养成良好的习惯, 防患于未然.
来源: http://www.tuicool.com/articles/AvQBjef