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等

除了堡版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!垒机的助力,我们还是需要从标准化流程出发,使用工具进行规范化管理。例如数据库可以使用Archery SQL审核查询平台,而大数据生态由于组件较多,可能无法找到一个统一的管理工具,这个我没有太多的经验,就不在此造次了,但是做好数据备份以不变应万变是必须的。

业务版本发布

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

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

导致版本发布的原因很多,我这面只是列举了一部分。解决这部分问题需要研发、运维、测试的多方面配合,也就是我们耳熟能详的DevOps。

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

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

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

需求变更

生产无小事,生产故障很可能就是因微小的变更操作导致的。在这方面曾经的基础运维同学和DBA同学都吃过亏,就是一个很平常、甚至有过很多实操的动作,触发了一个bug,进而影响业务。

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

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

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

细分类别

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

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

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

命令处理

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

类别命令措施
磁盘管理badbocks阻断
磁盘管理cfdisk阻断
磁盘管理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监控
文件管理s版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!maba监控
文件管理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监控
大数据管理hdf版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!s 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.*阻断
大数据管理hadoop fs -rmdir.*阻断
数据库管理truncate阻断
数据库管理drop database阻断
数据库管理版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!drop tables阻断
数据库管理delete阻断

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

监控管理

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

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

总结

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

0 条回应