Redis安全的笔记

Redis is designed to be accessed by trusted clients inside trusted environments.

上述说明来自官方文档Redis Security。因而在实现针对Redis的安全保护方案时,需要付出更多的代价。 考虑因素包括系统安全、网络安全、软件安全、应用安全。

系统安全

  • 操作系统及相关软件及时升级至最稳定版本。
  • 及时修复操作系统及相关软件的安全漏洞。
  • 关闭不相关的服务。
  • 禁用不必要的端口。
  • 卸载不相关的软件,如编译器。
  • 清理未使用的账号。

网络安全

  • 推荐绑定在本地回环地址,即只允许本机访问。
  • 避免直接对Internet暴露服务。
  • 绑定到指定IP,避免使用通配方式暴露服务。
  • 使用非标准端口对外提供服务。
  • 定义黑名单和白名单,使用iptables控制访问来源。

软件安全

  • 推荐使用Redis当前的稳定版本。
  • 及时升级Redis的版本。
  • 清理不相关的文件,如安装Redis时使用的源码包、样例文件、未使用的工具等。
  • 禁止高危命令,使用样例:
    rename-command CONFIG ""
  • 重定义必须使用的高风险命令,使用样例:
    rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
  • 指定内存的使用上限,避免影响应用和系统的稳定性。
  • 指定客户端最大通信链接数,规避DoS攻击。
  • 指定客户端通信链接的闲置时间的上限值,当客户端链接空闲时间超出上限后,将自动关闭链接,避免占用过多的资源。
  • 禁止将数据文件保存至系统分区。
  • 禁止将日志文件保存至系统分区。
  • 控制Redis软件、配置文件、日志文件、数据文件等的系统权限和属主,避免信息泄漏。

应用安全

  • 使用单独的操作系统用户运行Redis服务。
  • 关闭Redis运行用户的登录权限。
  • 禁止在Redis中保存敏感数据。
  • 禁止在命令行中使用Redis的口令,避免攻击者通过查阅history得到口令。
  • 合理使用日志切割工具控制日志文件的大小和数量,避免中断业务。
  • 对访问Redis的客户端进行认证,并且定期更换认证口令。

其它措施

建议通过修改对Redis的源码,提供如下特性:

  • Redis客户端在传输口令时,使用传输密钥对口令进行加密。
  • 传输密钥支持更换。
  • 在Redis的配置文件中,加密存储口令。
  • 存储密钥支持更换。
  • Redis客户端与Redis服务端之间定义加密的数据传输通道。
  • Redis客户端与Redis服务端之间实现双向认证。
  • Redis服务端认证客户端时,定义认证操作的超时时间,规避慢攻击。
  • 从使用场景将Redis的指令区分为管理用途和数据访问用途。对于管理类的指令,仅允许在Redis服务端本地使用;对于数据访问类的指令,可以在客户端使用。

参考资料

发表在 Redis, 数据库 | 标签为 | 留下评论

Redis配置文件的说明

Redis的配置文件中,各个配置项已有详细的说明,结合网友的总结,基本上可以了解个大概。在使用过程中,结合业务场景和验证结果,做出合理的取舍。

参考资料

发表在 Redis | 标签为 | 留下评论

自定义mvn命令

mkdir -p ~/software/bin
cd ~/software/bin
cat > mvn << EOF
#!/bin/sh
JAVA_HOME=~/software/jdk
export JAVA_HOME

if [ -z "$M2_HOME" ] ; then
    M2_HOME=~/software/maven
    export M2_HOME
fi

PATH=$JAVA_HOME/bin:$PATH
export PATH

MAVEN_OPTS="-Xms512m -Xmx1024m"
export MAVEN_OPTS

MAVEN_SKIP_RC="true"
export MAVEN_SKIP_RC

$M2_HOME/bin/mvn $*

EOF

chmod +x ~/software/bin/mvn
PATH=~/software/bin:$PATH

不需要维护环境变量M2_HOME,不需要修改官方的mvn命令,原生mvn命令运行时使用的全部依赖都包含在新创建的shell命令中,使用时非常方便。

发表在 Java, Linux, Maven, 工作总结 | 标签为 | 留下评论

口令安全的笔记

口令复杂度

要求

区分业务场景,设定规则的强度。
口令的规则中,需要包含如下要素:

  • 口令的长度
  • 口令中字符的组成
  • 口令与用户名的关系
  • 当前口令与历史口令的相关性

举例

比如对管理系统中管理员的口令,可以做如下要求

  • 口令要求由8~32个字符组成,包括8和32。
  • 口令中的字符由英文字母(包括大写/小写)、数字、特殊符合组成,并且口令中包含至少一个大写字母、一个小写字母、一个数字、一个特殊字符。特殊字符如~!@#$%^&*()-_
  • 口令中不允许出现用户名,无论大、小写形式。
  • 曾经使用过的口令在36个月内不得使用。

口令的呈现

要求

  • 口令校验失败时,不得直接提示口令错误。
  • 用户在界面上输入口令时,口令输入框中不允许呈现明文,同时输入框不支持复制。
  • 用户在命令行终端输入口令时,不允许回显口令。
  • 禁止在shell命令中使用口令,包括明文和密文。

防暴力破解

要求

需要考虑如下要素:

  • 一段时间内,重试次数的上限。
  • 两次重试之间的时间间隔。
  • 重试2次后,要求用户输入验证码。
  • 重试次数达到上限后,在一定时间内,禁止账号登录或者禁止来自某IP的登录请求。防止慢重试和DoS攻击。

对验证码的要求

  • 验证码需在服务端生成。
  • 验证码需要包含英文字母(包括大写字母、小写字母)、数字。
  • 验证码中字符的位置、相互之间的距离,随机生成。
  • 验证码中需包含一定的干扰线条。
  • 验证码的背景、字符、线条,需使用不同的色彩。
  • 验证码的生成器中,需使用安全随机数生成器。

修改策略

要求

需要考虑如下要素:

  • 用户的初始口令由系统生成,并且使用恰当的方式通知用户。
  • 用户使用初始口令登录系统时,系统强制用户修改口令。
  • 系统允许用户修改登录口令。
  • 修改口令时,系统要求验证用户的当前口令。
  • 口令具有有效期,有效期时长由系统定义。
  • 在口令超期后,系统强制用户修改口令。
  • 用户修改口令成功后,跳转至登录界面,用户输入新口令并校验成功,则允许登录。
  • 系统管理员可以强制初始化用户的口令为初始口令。

存储策略

要求

  • 如无必要,禁止保存口令。
  • 禁止明文保存口令。

规范

  • 在对口令在处理前,需要将用户名和口令拼接在一起,然后再进入加密处理。
    说明:假设小明、小强二人使用相同的口令登录网站系统,假如网站系统在保存口令时未按上述规范实现,则当攻击人员获知小明的口令,并且攻击人员知道小明和小强使用相同的口令,则导致小强的账号被间接攻破。
  • 如无必要,则优先使用单向加密算法对口令进行处理,后续使用时以密文形式进行一致性判断。
  • 使用存储密钥对口令进行处理。
  • 存储密钥不允许和其它用途的密钥混用。
  • 存储密钥不允许在代码中写死,必须支持更换。

举例

  • 对于配置文件、shell脚本、应用的日志(包括自研软件和外部软件等记录的日志)、数据库存储、应用使用的缓存、浏览器的存储(包括Cookie、LocalStorage、SessionStorage等)等,禁止出现明文口令。
  • 对于shell脚本、应用的日志(包括自研软件和外部软件等记录的日志)、浏览器的存储(包括Cookie、LocalStorage、SessionStorage等)等,禁止出现密文口令。

传输策略

要求

  • 禁止明文传输口令。

规范

  • 使用安全的传输通道传输口令。
  • 传输前使用传输密钥对口令进行处理。
  • 传输密钥不允许和其它用途的密钥混用。
  • 传输密钥不允许在代码中写死,必须支持更换。

例外

外部软件的API,如数据库驱动等需要明文传入口令。

发表在 笔记 | 留下评论