seo sem 外贸建站 网站建设 文化墙设计,wordpress 推广返利,成都信用,55g游戏网哈喽大家好#xff0c;我是咸鱼
今天我们来看一个关于 Keepalived 检测脚本无法执行的问题
一位粉丝后台私信我#xff0c;说他部署的 keepalived 集群 vrrp_script 模块中的脚本执行失败了#xff0c;但是手动执行这个脚本却没有任何问题 这个问题也是咸鱼第一次遇到我是咸鱼
今天我们来看一个关于 Keepalived 检测脚本无法执行的问题
一位粉丝后台私信我说他部署的 keepalived 集群 vrrp_script 模块中的脚本执行失败了但是手动执行这个脚本却没有任何问题 这个问题也是咸鱼第一次遇到为了能让更多的小伙伴以后不会踩这个坑便有了今天这篇文章
前言
在正式开始之前我们先来简单复习一下 Keepalived 中的资源检测功能
vrrp_script 模块
在 Keepalived 中vrrp_script 模块是用于定义和配置虚拟路由冗余协议VRRP的自定义脚本检查这个模块专门用于对集群中的服务资源进行监控
与 vrrp_script 模块搭配使用的是 track_script 模块这个模块中可以引入监控脚本、命令组合、Shell 语句来实现对服务资源的监控 track_script 通过调用 vrrp_script可以灵活地定义需要监测的服务或资源例如网络连接、服务状态、系统资源等 当监测到故障时Keepalived 可以触发状态转移将主节点切换到备用节点以确保服务的高可用性 通过 killall -l 命令监测
killall 命令会发送一个信号给进程以信号 0 为例如果发现进程关闭或者异常将返回状态码 1反之进程运行正常状态码返回0
vrrp_script nginx_check {script killall -0 nginxinterval 2
}track_script {nginx_check
}通过端口监测
检测端口的运行状态也是较常见的监控方式
vrrp_script nginx_check {script /dev/tcp/127.0.0.1/80interval 2fall 2rise 1
}track_script {nginx_check
}其中 fall表示检测到失败的最大次数如果请求失败两次就认为该节点发生了故障
rise 表示如果请求一次成功就认为该节点恢复正常
通过 shell 语句监测
vrrp_script nginx_check {script if [ $(pidof nginx | wc -l) -eq 0 ]; then exit 1; else exit 0; fiinterval 2fall 2rise 1
}track_script {nginx_check
}通过脚本监测
vrrp_script nginx_check {script /etc/keepalived/nginx_check.shinterval 2fall 2rise 1
}track_script {nginx_check
}问题
在介绍完了 keepalived 的监测功能之后我们来看下这个问题
我根据他的描述复现了这个场景keepalived 通过监测上游网络来判断该节点是否正常运行如果到上游的网络不通则认为该节点发生了故障
检测脚本如下
[rootlocalhost ~]# cat /etc/keepalived/check.sh
#!/bin/bash
# 检查上行链路
check_route192.168.149.135
ping -c 3 $check_route /dev/null 21
result$?
echo ${date}----checking..... result:${result} /tools/log.log
if [ $? -eq 0 ]; thenexit 0 # 正常
elseexit 1 # 链路异常
fi一切准备就绪之后启动 keepalived 服务发现报 Keepalived_vrrp[2653]: /etc/keepalived/check.sh exited with status 1
[rootlocalhost ~]# systemctl status keepalived.service
● keepalived.service - LVS and VRRP High Availability MonitorLoaded: loaded (/usr/lib/systemd/system/keepalived.service; disabled; vendor preset: disabled)Active: active (running) since 三 2023-08-14 23:53:49 CST; 4min 56s ago...
8月 14 23:53:49 localhost.localdomain Keepalived_vrrp[2653]: /etc/keepalived/check.sh exited with status 1
...说明脚本没有执行成功返回状态码 1 了我尝试着手动执行发现脚本没有任何问题
[rootlocalhost ~]# sh /etc/keepalived/check.sh
[rootlocalhost ~]# echo $?
0排查
首先看一下 /var/log/messages如果 keepalived 没有专门指定日志文件路径这个便是默认的日志文件路径
...
Aug 14 23:53:49 localhost Keepalived_vrrp[17889]: SECURITY VIOLATION - scripts are being executed but script_security not enabled
...
Aug 14 23:53:49 localhost Keepalived_vrrp[17889]: /etc/keepalived/check.sh exited with status 1
...SECURITY VIOLATION - scripts are being executed but script_security not enabled 这条信息引起了我的注意
”安全违规-脚本正在执行但 script_security 未启用“看输出应该是 keepalived 进程想要执行该脚本但是受到了安全限制
既然是跟系统安全相关的我们就先来看看这个脚本的权限吧
# 查看脚本权限
[rootlocalhost ~]# ll /etc/keepalived/check.sh
-rwxr-xr-x. 1 root root 281 8月 9 15:52 /etc/keepalived/check.sh# 查看是 keepalived 进程的属主
[rootlocalhost ~]# ps -ef | grep keep
root 19163 1 0 01:00 ? 00:00:00 /usr/sbin/keepalived -D
...由上面的输出我们可以得知 keepalived 进程的属主是 root 而 root 用户是可以去执行这个脚本的有 x 权限
权限没问题我们再来查看下 /var/log/audit/audit.log /var/log/audit/audit.log 是一个存储系统审计日志的文件 这个文件记录了系统中发生的各种安全事件、用户操作和系统行为以及与安全相关的信息 系统审计日志是用来监控系统活动、检测潜在的安全问题和追踪系统事件的重要工具之一 ...
typeSYSCALL msgaudit(1692033018.624:12555): archc000003e syscall4 successno exit-13 a0190abc0 a17ffd028eafc0 a27ffd028eafc0 a37ffd028eaae0 items0 ppid19472 pid19473 auid4294967295 uid0 gid0 euid0 suid0 fsuid0 egid0 sgid0 fsgid0 tty(none) ses4294967295 commcheck.sh exe/usr/bin/bash subjsystem_u:system_r:keepalived_t:s0 key(null)typeAVC msgaudit(1692033018.624:12555): avc: denied { getattr } for pid19473 commcheck.sh path/usr/bin/ping devdm-0 ino50555278 scontextsystem_u:system_r:keepalived_t:s0 tcontextsystem_u:object_r:ping_exec_t:s0 tclassfile permissive0
...我们现在来看一下上面日志输出表示什么
先看第一段
typeSYSCALL: 这个部分是系统调用事件类型。archc000003e syscall4 successno exit-13: 这里描述了系统调用的详细信息包括系统调用号、是否成功等
subjsystem_u:system_r:keepalived_t:s0描述了进程的安全上下文信息后面内容则是一些更多与系统调用相关的信息如参数、进程信息、用户信息等
再看第二段
typeAVC: 这个部分指示了事件类型为 AVCAccess Vector Cache是 SELinux 的访问控制事件
avc: denied { getattr }: 表示操作是一个 getattr获取属性操作但是被拒绝。pid19473 commcheck.sh: 进程 ID 是 19473进程名称是 check.sh。path/usr/bin/ping: 文件路径是 /usr/bin/ping表示被操作的文件。scontextsystem_u:system_r:keepalived_t:s0: 发起操作的进程的安全上下文。tcontextsystem_u:object_r:ping_exec_t:s0: 被操作文件的安全上下文。tclassfile: 被操作对象的类型是文件。permissive0: 表示 SELinux 不是处于宽松模式
总结一下
这个是 SELinux 的审计日志这两条日志记录了一个操作即 keepalived 进程试图通过执行 check.sh 脚本访问 /usr/bin/ping 文件但被 SELinux 拒绝了
解决
排查到这思路就逐渐清晰起来了这是因为 SELinux 权限导致的在解决这个问题之前我们先来简单复习一下 SELinux 后面我会专门写一篇文章来介绍 SELinux
SELinuxSecurity Enhanced Linux安全强化的 Linux 由美国国家安全局NSA开发的
为什么要开发 SELinux
我们知道系统的账户主要分为系统管理员root和普通用户这两种身份能否使用系统上面的文件资源则与 rwx 权限设置有关
所以当某个进程想要对文件进行读写操作时系统就会根据该进程的属主和属组去比对文件权限只有通过权限检查才能够进一步操作文件
这种方式被称为自主访问控制Discretionary Access Control, DACDAC 是 Linux 操作系统中的一种基本权限控制机制用于限制用户对系统资源的访问权限
但是 DAC 的一大问题就是当用户获取到进程之后他可以通过这个进程与自己所获得的权限去处理对应的文件资源
万一用户对系统不熟悉就很容易导致资源误用的问题出现 举个例子你们公司的新人为了自身方便将网页所在目录 /var/www/html 目录的权限设置成了 777则代表所有进程都可以对该目录进行读写 如果黑客接触到了某个进程就极有可能向你的系统里面写入某些东西 为了避免 DAC 的问题便有了 SELinux
SELinux MAC 机制
SELinux 引入了强制访问控制Mandatory Access Control, MAC机制
强制访问控制MACMandatory Access Control是 Linux 操作系统中一种更加严格和细粒度的访问控制机制用于加强对系统资源的保护和控制
MAC 有趣的地方在于它可以针对特定的进程与特定的文件资源来管理权限即使你是 root 用户在使用不同的进程时你所能获取的权限也不一定是 root 安全上下文
前面我们知道SELinux 是通过 MAC 的方式来管理进程的权限的
它控制的主体是【进程】而【目标】则是该【进程】能否读取的文件资源
主体
SELinux 主要管理的就是进程进程和主体可以画上等号
目标
主体能否读写的目标一般就是文件资源
除了策略指定之外主体与目标的安全上下文必须一致才能够顺利读写
安全上下文有点类似于文件系统的 rwx 如果设置错误主体就无法读写目标资源了 安全上下文存放在文件的 inode 内可以通过 ll -Z 命令去查看前提是 SELinux 是开启着的
回到我们的案例上来日志输出说进程 check.sh 试图获取 /usr/bin/ping 的属性getattr操作但被 SELinux 拒绝了
但是我们发现没有这个进程
[rootlocalhost ~]# ps -ef | grep check也就是说由于 SELinux 权限问题 keepalived 一开始想要调用 check.sh 脚本就失败了
我们分别来看一下 keepalived 进程和 check.sh 的安全上下文
[rootlocalhost ~]# ps -eZ | grep keepalived
system_u:system_r:keepalived_t:s0 19609 ? 00:00:00 keepalived[rootlocalhost ~]# ll -Z /etc/keepalived/check.sh
-rwxr-xr-x. root root system_u:object_r:etc_t:s0 /etc/keepalived/check.sh可以看到 keepalived 进程的安全上下文类型为 keepalived_t而 check.sh 的安全上下文是 etc_t
即——主体与目标的安全上下文并不一致就算有 rwx 权限也无法执行
解决方案一关闭 SELinux
简单粗暴直接关闭 SELinux 就没有这么多乱七八糟的限制了
# 以 CentOS 7 为例
# 临时关闭
[rootlocalhost ~]# setenforce 0#永久关闭将 SELINUXenforcing 改为 SELINUXdisabled然后保存退出
[rootlocalhost ~]# sed -i s/SELINUXenforcing/SELINUXdisabled/ /etc/selinux/config解决方案二失败了修改 check.sh 的安全上下文与 keepalived 一致
我想把 check.sh 的安全上下文改成与 keepalived 一致可是失败了有小伙伴知道原因吗
[rootlocalhost ~]# chcon -t keepalived_t /etc/keepalived/check.sh
chcon: 改变/etc/keepalived/check.sh 的环境到system_u:object_r:keepalived_t:s0 失败: 权限不够解决方案三修改 check.sh 的安全上下文
依旧是修改 check.sh 的安全上下文不过这次参考了资料
[rootlocalhost ~]# chcon -t keepalived_unconfined_script_exec_t /etc/keepalived/check.shkeepalived_unconfined_script_exec_t 是一个在 SELinux 中用于标识 Keepalived 执行未限制脚本的上下文这个上下文允许 Keepalived 进程在执行脚本时绕过一些 SELinux 限制从而可以在需要的情况下执行脚本
解决方案四将脚本转移到 /usr/libexec/keepalived 目录中
# keepalived 配置
vrrp_script nginx_check {script /usr/libexec/keepalived/check.shinterval 2fall 2rise 1
}这个目录的安全上下文是 keepalived_unconfined_script_exec_t与解决方案三同理
[rootlocalhost ~]# ll -Z /usr/libexec/keepalived/ -d
drwxr-xr-x. root root system_u:object_r:keepalived_unconfined_script_exec_t:s0 /usr/libexec/keepalived/解决方案五 keepalived 全局配置添加 enable_script_security 字段
加了这个字段意味着如果脚本路径的任一部分对于非 root 用户来说都具有可写权限则不会以 root 身份运行脚本
以非 root 身份运行的脚本就能够通过 SELinux 的审查吗这一块我不太懂有懂的小伙伴可以告诉我
global_defs {...enable_script_security...
}参考资料
https://github.com/acassen/keepalived/issues/1322
https://serverfault.com/questions/709428/track-script-doesnt-work-after-keepalived-update
https://www.mankier.com/8/keepalived_selinux
https://linux.vbird.org/linux_basic/centos7/0440processcontrol.php#selinux
