Linux Note / 安全攻防 / 运维笔记

运维高危操作

Einic Yeo · 5月2日 · 2022年 · ·

简述

“对数据要有敬畏之心”这个主题是同事在一个早会分享时提出的,却直接引起我心中的共鸣。前几年各种删库跑路事件、Facebook宕机事件仍不绝于耳,虽然大家将“删库跑路”当作一个调侃与谈资,但上升到“对数据要有敬畏之心”的高度,作为运维我们就要居安思危,防患于未然。

数据的定义

从运维的角度,数据不是独立存在的,它存在于日常运维过程中的各个环节,如例行维护、变更、故障处理等。因此如果我们只考虑数据本身则意义不大,要从数据存在的各个环节去分析。

在此我们将其大体概括为:

  • 数据备份
  • 文件系统+例行维护
  • 数据版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!
  • 大数据
  • 业务版本发布
  • 需求变更

数据备份

从数据安全的角度出发,我们最先想到的肯定是数据备份,下面我们来看下数据备份的几个关键点。首先,根据备份空间和从备份恢复的速度情况下,我们可以将数据备份分为本地备份和异地备份(不考虑多机房容灾)。其次,无论是何种备份方式,我们都需要考虑备份保存周期,因此无规则限制的归档会带来存储成本的不断升高。最后,针对数据丢失或误删等各种场景,我们需要确定就是备份哪些内容。

对此我们总结需要备份的内容如下:

  • 系统级配置文件 内核参数、hosts解析、crontab计划任务、环境变量、防火墙等
  • 应用级配置文件 nginx、java应用、中间件、dns等
  • 日志级数据 应用日志、nginx日志等
  • 数据库备份 binlog日志、逻辑备份、配置文件、慢查询日志

文件系统+例行维护

和文件系统联系最紧密的莫过于日常例行维护了,如磁盘清理、文件处理等所有与数据丢失风险相关的操作。当我们在例行维护过程中,运维必须精神高度集中,非常清醒的注意每个指令,执行危险操作时可以和同事进行二次确认

操作文件系统虽然都是简单命令,但也是有窍门的,在此给大家推荐下。

【运维小贴士:巧用Linux冒号命令,实现rm防误删】
Linux系统中冒号(:)在bash中是一个內建命令,而不单纯是一个分隔符,它的主要作用是空命令、参数扩展、重定向、注释等。
我们可以使用其参数扩展特性实现rm的防误删功能,下面我们来通过实例讲解下其用法。
格式:${parameter:-test}
功能:如果parameter没有设置或者为空,替换为test;否则替换为parameter的值。
命令:rm -rf ${dest:-test}
用法:当变量dest为空时,删除test;当变量dest不为空时,删除test
用例:rm -rf /$dest。当变量dest没有设置或为空时,则命令变成rm -rf /,这将误删系统根目录,导致系统崩溃。
改进:rm -rf /${dest:-test},当变量dest没有设置或为空时,会使用test代替,则命令变成rm -rf /test,删除此目录不会产生任何影响。

除了以上方法,如果我们的服务器都使用堡垒机登录的话,那么福利来了。我们可以使用堡垒机自带的命令过滤功能,禁用操作系统的危险命令。

数据库+大数据

数据库和大数据都作为基础数据,虽然有单独的DBA和大数据运维对其负责,但是我们仍可以借鉴堡垒机的命令过滤功能:

  • 对数据库操作过滤,如:drop、truncate、delete等
  • 对大数据操作过滤,如:hdfs dfs -rm等

除了堡垒机的助力,我们还是需要从标准化流程出发,使用工具进行规范化管理。例如数据库可以使用Archery SQL审核查询平台,而大数据生态由于组件较多,可能无法找到一个统一的管理工具,这个我没有太多的经验,就不在此造次了,但是做好数据备份以不变应万变是必须的。

业务版本发布

业务版本发布绝对是运维工作中紧张又刺激的一项工作了,导致发布失败的原因也很多:

  • 配置文件混乱
  • 多环境污染
  • git分支管理混乱
  • 版本发布比较随意
  • 缺少测试环节,如回归测试、冒烟测试等
  • 等等

导致版本发布的原因很多,我这面只是列举了一部分。解决这部版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!分问题需要研发、运维、测试的多方面配合,也就是我们耳熟能详的DevOps。

我们从代码托管开始梳理:

  1. 代码管理必须严格,按功能区分分支,不能随意合并代码至master;
  2. 按环境区分配置文件,以免混淆;
  3. 测试、生产等环境最好严格的物理隔离或逻辑隔离,避免环境互通;
  4. 版本生产发布前,需要经过严格的功能测试;
  5. 确定统一的版本发布日,非发版日严禁变更;
  6. 标准化的版本发布流程,实现参数化自动版本发布;
  7. 屏蔽/回复发版过程中的告警,实现更精细化的监控;

以上几点不是只靠运维就能解决的,而是需要规范+流程+研发/运维/测试+工具的整体配合。常见的开源组合如下:Jira+Jenkins+Git+Sonar+Pipeline+监控

需求变更

生产无小事,生产故障很可能就是因微小的变更操作导致的。在这方面曾经的基础运维同学和DBA同学都吃过亏,版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!就是一个很平常、甚至有过很多实操的动作,触发了一个bug,进而影响业务。

为什么要把需求变更单独拿出来讲,因为这是一个很容易让人忽略的点。对于不可预知的事情,我们必须提前做好预案:

  • 确定变更操作影响的业务范围
  • 通知相关责任人,确定变更关键节点
  • 确定变更方案及具体操作步骤
  • 做好数据备份及数据恢复方案
  • 确定变更时间,避免业务高峰期

通过预案可以更充分的暴露风险点,帮助我们更好的应用突发问题。

细分类别

针对操作系统级命令的功能,我们将高危命令分为以下几类:

  • 磁盘管理
  • 权限管理
  • 设备操作
  • 网络管理
  • 文件管理
  • 系统管理
  • 账号管理
  • 大数据管理
  • 数据库管理
  • 等等

相信如果我们不仔细去梳理,我们永远也意识不到原来高危命令有这么多类型,那么我们继续往下看!

命令处理

对于高危命令的管理,我们不能“一刀切”将其全部禁用,而是要根据其具体需求去区别处理,下面是我们的一些建议。

类别命令措施
磁盘管理badbocks阻断
磁盘管理cfdisk版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!阻断
磁盘管理dd阻断
磁盘管理e2fsck阻断
磁盘管理fsck阻断
磁盘管理fsconf阻断
磁盘管理hdparm阻断
磁盘管理mformat阻断
磁盘管理mkbootdisk阻断
磁盘管理mkdosfs阻断
磁盘管理mke2fs阻断
磁盘管理mkfs.ext4阻断
磁盘管理mkfs.xfs阻断
磁盘管理mkinitrd阻断
磁盘管理mkswap阻断
磁盘管理mpartition阻断
磁盘管理swapon阻断
磁盘管理swapoff阻断
磁盘管理symlinks阻断
磁盘管理sync阻断
磁盘管理mbadblocks阻断
磁盘管理fdisk阻断
磁盘管理mkfs阻断
磁盘管理eject阻断
磁盘管理restore阻断
磁盘管理>阻断
磁盘管理rm阻断
权限管理sudo监控
权限管理su监控
权限管理chmod监控
权限管理chown监控
设备操作mount监控
设备操作umount监控
设备操作shutdown监控
设备操作poweroff监控
设备操作reboot监控
设备操作halt监控
网络管理curl监控
网络管理wget监控
网络管理ftp监控
网络管理sftp监控
网络管理nc监控
网络管理telnet监控
网络管理ssh监控
网络管理rlogin监控
网络管理rsh监控
文件管理smaba监控
文件管理git监控
文件管理mv监控
文件管理rm监控
文件管理cp监控
文件管理scp监控
文件管理dump监控
文件管理rsync监控
系统管理crontab监控
系统管理cron监控
系统管理yum监控
系统管理rpm监控
系统管理apt监控
系统管理eval监控
系统管理exec监控
系统管理kill监控
系统管理killall监控
系统管理skill监控
系统管理reset监控
系统管理init监控
系统管理supervisorctl监控
系统管理systemctl监控
系统管理service监控
系统管理java -jar监控
账号管理useradd监控
账号管理userdel监控
账号管理adduser监控
账号管理deluser监控
账号管理groupdel监控
账号管理groupadd监控
账号管理chgrp监控
账号管理passwd监控
大数据管理hdfs dfsadmin.*阻断
大数据管理hdfs dfs -rm.*阻断
大数据管理hdfs haadmin.*阻断
大数据管理hdfs dfs -chmod.*阻断
大数据管理hdfs dfs -chgrp.*阻断
大数据管理hdfs dfs -chown.*阻断
大数据管理hdfs dfs -moveToLocal.*阻断
大数据管理hdfs dfs -mv.*阻断
大数据管理hdfs dfs -rmdir.*阻断
大数据管理systemctl .* cloudera-scm-server阻断
大数据管理systemctl .* cloudera-scm-agent阻断
大数据管理hadoop distch.*阻断
大数据管理hadoop distcp.*阻断
大数据管理hadoop fs -rm.*阻断
大数据管理hadoop fs -chmod.*阻断
大数据管理hadoop fs -chgrp.*阻断
大数据管理hadoop fs -chown.*阻断
大数据管理hadoop fs -moveToLocal.*阻断
大数据管理hadoop fs -mv.*阻断
大数据管版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!hadoop fs -rmdir.*阻断
数据库管理truncate阻断
数据库管理drop database阻断
数据库管理drop tables阻断
数据库管理delete阻断

当然在实际使用过程中的命令包含但绝不限于这些,而且考虑到操作系统、应用、服务已经在生产中稳定运行,因此我们需要将可能具有潜在危险的命令进行监控或阻断。特殊情况下要执行某个高危命令,我们要有意识进行多人复核,以免误操作。

监控管理

对于处理高危命令的处理,我们要做到监控和管理,在此可以结合监控系统和堡垒机来处理:

  • 监控系统,对高危命令进行监控告警;
  • 堡垒机,对高危命令命令过滤,最好可以和正则表格式结合使用;

总结

数据无处不在,数据风险也就如影随形,因此运维要对数据有敬畏之心,这和运维经验是否丰富无关。要想做到数据的安全性,我们需要一直保持警惕性。其实Linux高危命令不只是存在于单纯的命令执行,而是广泛存在于数据库、应用服务、大数据等和业务息息相关的环节上。如果我们的生产服务器没有做到开发、运维、测试人员的权限分离,那么本次的高危命令总结希望可以派上用场。

0 条回应