一介闲人
2024-10-09
64
原创
关于CentOS的一些高危级别的安全项
1.系统安全风险项
风险项描述：
连续n次失败登录尝试后锁定用户。
修复方案:
编辑/etc/pam.d/password-auth 和/etc/pam.d/system-auth 文件，以符合本地站点策略： 建议严格按照顺序插入
auth required pam_faillock.so preauth audit silent deny=5 unlock_time=900
auth [success=1 default=bad] pam_unix.so
auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900
auth sufficient pam_faillock.so authsucc audit deny=5 unlock_time=900
风险项描述：
MaxAuthTries参数指定每个连接允许的最大身份验证尝试次数。登录失败次数达到设置参数一半时，错误消息将写入syslog文件，详细说明登录失败。
修复方案:
编辑/etc/bashrc，/etc/profile和/etc/profile.d/*.sh文件（以及系统上支持的任何其他Shell的适当文件），，并添加或编辑umask参数，如下所示：
umask 027
# 备注（修复完后运行以下命令以确保是否已完全修复）
grep "umask" /etc/bashrc
grep "umask" /etc/profile
grep "umask" /etc/profile.d/*.sh
# 如果umask配置不为027的，需全部修改为027或更严格
风险项描述：
MaxAuthTries参数指定每个连接允许的最大身份验证尝试次数。登录失败次数达到设置参数一半时，错误消息将写入syslog文件，详细说明登录失败。
修复方案:
编辑/etc/ssh/sshd_config文件以设置参数，如下所示：
MaxAuthTries 4
风险项描述：
这两个选项ClientAliveInterval和ClientAliveCountMax控制SSH会话超时。当ClientAliveInterval变量被设置，对指定的时间长度没有活动的SSH会话被终止。当ClientAliveCountMax变量被设置，sshd将在每一个客户端发送活动消息ClientAliveInterval的时间间隔。当连续发送的客户端活动消息数没有客户端响应时，ssh会话将终止。
修复方案:
编辑/etc/ssh/sshd_config文件以设置参数：
ClientAliveInterval 300
ClientAliveCountMax 0
风险项描述：
PermitEmptyPasswords参数指定SSH服务器是否允许登录具有空密码字符串的帐户。
修复方案:
编辑/etc/ssh/sshd_config文件以设置参数，如下所示：
PermitEmptyPasswords no
风险项描述：
默认值TMOUT确定用户的shell超时时间。TMOUT值以秒为单位。
修复方案:
编辑/etc/bashrc和/etc/profile文件（以及系统上支持的任何其他Shell的适当文件），并添加或编辑任何umask参数，如下所示：
TMOUT=600
2.三方组件安全风险项
风险项描述：
如果 Redis 以 root 权限启动且未授权访问，则会造成任意文件写入，最终导致命令执行漏洞。通过命令注入漏洞，黑客可以在服务器上执行任意系统命令，获取服务器权限，造成服务器敏感信息和源代码泄漏。
修复方案:
- 以低权限用户权限启动 Redis；
- 如非业务需要，绑定 Redis 在 具体IP 而非 0.0.0.0；
- 删除 Redis 的 CONFIG、SAVE 等命令
- 开启 AUTH 密码验证（仍然有被利用的风险，所以不会取消安全提醒）
风险项描述：
启动的MongoDB服务时如果不添加任何参数时,默认是没有权限验证的,黑客可以远程访问数据库，登录的用户可以通过默认端口无需密码对数据库进行增、删、改、查等任意高危操作，过去已发现黑客利用该漏洞对受影响的用户实施数据勒索。
修复方案:
- 建议修改默认的27017端口为其他端口，如29017
- 启动MongodDB的时候增加 --auth或者在配置文件中将auth设置为True开启鉴权，并在admin表添加管理用户
- 通过bind_ip绑定服务器启动IP，避免绑定在0.0.0.0导致服务暴露在外网
- 推荐使用腾讯云文档数据库 MongoDB服务，无需担心未授权访问问题 更多修复建议可以参考http://bbs.qcloud.com/thread-42928-1-1.html
风险项描述：
默认安装情况下，Elasticsearch会开启并监听9200端口，但是对于该端口并没有访问控制，恶意用户可以在未授权的情况下通过浏览器访问ip:9200/_nodes/stats等链接获得系统信息、以及存储的敏感数据等；在低版本(<1.7.1)的ElasticSearch可直接执行系统命令，导致服务器被入侵。
修复方案:
- 增加验证，官方推荐并且经过认证的是shield插件，也可使用elasticsearch-http-basic，searchguard插件；
- 使用Nginx搭建反向代理，通过配置Nginx实现对Elasticsearch的认证；
- 如果是单台部署的Elasticsearch，9200端口不要对外开放；
- 使用1.7.1以上的版本；
风险项描述：
Kubelet 未限制访问来源且未配置任何认证，导致攻击者可以在任意 Pod 中执行任意代码。也可以造成 Pod 泄漏导致敏感信息泄漏等。
修复方案:
# kubelet 监听在本地：
--address=127.0.0.1
# kubelet server 禁止匿名访问：
--anonymous-auth=false
# 如果已经通过防火墙等方式对端口访问进行限制，请忽略。
# 配置证书：
--client-ca-file=path/to/ca
--kubelet-client-certificate
--kubelet-client-key
风险项描述：
CouchDB是一个开源的面向文档的数据库管理系统，由于CouchDB可通过BRESTful JavaScript ObjectNotation (JSON) API访问，默认会开放5984端口，6984端口（ssl），默认配置不进行验证，因此任意用户均可通过API访问导致未授权访问，进而导致入侵等风险
修复方案:
- 指定CouchDB绑定的IP（需要重启CouchDB才能生效）； 修改 /etc/couchdb/local.ini 文件中的 “bind_address = 0.0.0.0” ，将 0.0.0.0 改为 127.0.0.1 ，保存； 注意：修改后只有本机才能访问CouchDB；
- 设置访问密码（重启CouchDB才能生效）； 在 /etc/couchdb/local.ini 中找到“[admins]”字段配置密码；
- 设置WWW-Authenticate认证；
CentOS
评论