记一次crontab定时任务被清空的故障原因定位及复盘过程
记一次crontab定时任务被清空的故障原因定位及复盘过程
一、问题描述及事件经过
大年二十九,接到运维值班同事反馈的一个问题:
某生产服务器上的1月17号下午1点左右业务部门运维人员通过堡垒机登录时查看crontab -l定时任务是在的
但是1/18号早上业务部门另外一名运维人员,通过堡垒机登录时查看crontab -l却发现全空了
当时已经通过1月17号的堡垒机上的运维日志恢复了crontab定时任务,业务已经修复
但要回溯一下crontab -l被清空的根因, 业务部门一度怀疑17-18号这期间是不是有人绕过堡垒机登录过这台服务器,做过啥运维操作导致crontab定时任务被清空
二、问题原因分析过程
当运维值班同事的这个问题反馈过来后,开始着手分析
1、先排查SSH ACL访问控制,白名单配置文件中没有堡垒机以外的IP地址
为了证明不存在堡垒机绕过的情况,我这里直接GrayLog日志服务器查询了一下这台服务器这个时间区间的SSH登录日志 除了堡垒机IP没有其他IP有登录过服务器的SSH
再说了,即使有绕过堡垒机登录的情况,GrayLog也会发送相应的堡垒机绕过告警到运维群里
所以不要怀疑自己这个SSH防堡垒机绕过的安全加固机制,要对自己有信心
2、这时查看堡垒机的1/18号最早的运维日志记录
只发现crontab -l 多了一个空格,也只发现这样一个异常
我尝试在Linux虚拟机上做了测试,crontab - l 多了一个空格,这时会话会卡住
这时Ctrl+C直接退出,然后再crontab -l 查看crontab定时任务还是在的
3、所以很诡异,问题陷入僵局
根据上面的测试论证,看来多一个空格也不至于说会把crontab定时任务清空哈 所以问题卡住
4、借助搜索引擎
https://blog.csdn.net/Dr_Guo/article/details/123085782
https://www.modb.pro/db/188537
这时不要禁锢在思维定势里,借助搜索引擎尝试找找有没有其他可能性
好家伙,感觉和我现在的问题场景一模一样!
5、在Linux虚拟机下测试论证一下
crontab - l这时卡住了,然后直接关闭SecureCRT,中断SSH会话
然后再登录SSH会话,再查看crontab -l发现果然被清空了
并且/var/log/cron日志也有这个REPLACE关键字
crontab[13022]: (root) REPLACE (root)
6、然后GrayLog上查询cron日志发现1/18的日志中也有REPLACE关键字
那就是这个原因无疑了
三、问题原因总结及后续改进措施
- 1、问题原因:业务部门运维人员使用了错误的crontab - l 命令(多了一个空格)导致卡住,然后他看这时卡住了,接着直接关闭了这个堡垒机SSH会话,进而导致Crontab所有计划任务被清空
- 2、问题评价:墨菲定律:你认为越没有可能发生的事情,越有可能发生
有点算一个小黑天鹅事件:虽然某个黑天鹅事件在某个时间点出现是非常小概率的事件,但是生活工作中“黑天鹅”事件是一定会出现的,只是不知道是哪一个或者在哪个时间点
- 3、如何加固,避免这种现象再次发生
chattr +i /var/spool/cron/root (加锁:禁止修改定时任务)
chattr -i /var/spool/cron/root (解锁:先解锁,才能修改定时任务,避免误操作)
- 4、当然也可以做告警,当堡垒机操作日志中出现chattr -i /var/spool/cron/root解锁命令时进行告警提醒
相关文章
- css固定定位_css定位布局
- 微信企业号开发:微信考勤百度地图定位详解手机开发
- 微信小程序判断手机有没有定位的方法详解手机开发
- Linux下文件查找命令:快速定位文件(linux文件查找命令)
- Linux 用户主目录重新定位(linux更改主目录)
- 挖掘Oracle日志:开启精准故障定位之旅(oracle日志挖掘)
- Linux定位故障:不容忽视的步骤(linux定位错误)
- SQL Server慢速日志:精准定位网站性能瓶颈(sqlserver慢日志)
- MSSQL错误日志分析:指引你精准定位复杂故障(mssql 错误日志)
- cmd快速定位oracle数据库的终极之道(cmd找到oracle)
- java调用百度定位api服务获取地理位置示例