记10月份两次生产故障

标签：10 gitlab 两次 故障 服务器 root pam tally2

记10月份两次生产故障 　　我的线下考试因为新冠疫情，本来12月能考，硬是推到了年后，搞到我无比困扰，早考早超生嘛~~~~感觉太久没写博客，人都懒了 　　之前说过，在10月份那会出现了两次生产故障，一个是关于系统安全加固的；另一个是git问题。   生产故障（1） 　　系统安全加固做的是登录失败处理功能策略，大家肯定不陌生，centos 7用的是pam_tally2模块，但如果换成阿里的操作系统：Alibaba Cloud Linux 3.2104 LTS 64位，再使用pam_tally2模块，就会出现问题了。而我在生产环境刚部署完（9月份），就设置了这个登录失败功能的配置。当时记得等保是需要做的，而且我还做过多次，于是直接编辑文件：/etc/pam.d/system-auth 和 /etc/pam.d/password-auth，不假思索地敲进去

auth        required      pam_tally2.so  onerr=fail  deny=5  unlock_time=180 even_deny_root root_unlock_time=180

       wq保存的时候，是不会直接告诉你配置是没问题的，只有查看：/var/log/secure，才会看到报错（这个我还是事后才知道关于pam模块的日志都在secure里）

Oct 12 10:43:10 sudo[610567]: PAM unable to dlopen(/usr/lib64/security/pam_tally2.so): /usr/lib64/security/pam_tally2.so: cannot open sh
ared object file: No such file or directory
Oct 12 10:43:10 sudo[610567]: PAM adding faulty module: /usr/lib64/security/pam_tally2.so

       我当时以为没有问题，因为测过登录失败处理是能生效的。 　　另外，为了方便，我还设置了普通用户免密码切换到root “sudo su -”。 　　visudo查看是这样的配置

{普通用户}    ALL=(ALL)      NOPASSWD:ALL

　　然后，10月份那会，阿里的云安全中心，爆出个应用系统的远程执行漏洞，我们经理测试过，这个漏洞很可怕，能在系统上提权。当时领导担心攻击者已经偷偷潜入到服务器，伪装成正常程序，甚至想我格式化系统，等修复完问题再重新部署。我苦口婆心地给他说，要是以后又爆出个这样的漏洞，岂不是每次都要格式化系统？这样非常浪费人力物力，所以最后还是没有格式化，该安全加固赶紧加固。想到应用程序运行用户就是那个可以直接免密码切换到root的用户，所以我得赶紧把这个权限收回来，运行“su - ”需要输入root密码。大家都知道直接 visudo 把普通用户那条命令去掉即可，我当时选择晚上10点后生产环境服务停了之后再去掉。 　　当去掉的时候，我发现普通用户再也切换不到root了，报su 模块错误，当时我还以为root密码改过，关机重置密码后还是不行。 　

 　　在接近11点夜深人静的时候，我开始急了（那会也是经常加班，系统刚上线没多久，所以人确实不太清醒），改之前没有做快照备份，想着一个这么简单的东西，我多做过很多次了，然而，就是自信过头害了我~~~，想到每天凌晨3点都有备份快照，应用服务器应该除了jar包外，没有什么重要东西，然后关机直接回滚前一天云盘快照了。回滚完能切换到root了，但想起来开发有在这台服务器建了个目录，专门用来存用户图片，再查下这个目录，搞丢了当天凌晨3点后到我回滚快照前的数据！跟阿里沟通能不能后台恢复，他们也没办法，话说故障是国庆假期之后连续上班7天的第7个工作日，本想着第二天终于能休息，但搞出个这样的故障，只能第二天回去认错（是的，我基本一晚上没睡，想着怎么被祭天，想着我赶紧转行再也不要当运维了，乱七八糟想了一堆，第二天也是早早醒了，7点多打电话给我经理、开发说明了情况，说回去公司一趟，承担各种后果）。最后这个事，我经理统一了客服口径，给说那天网络不好，叫客户重传数据，而我将功补过，后面两周基本天天无偿加班，都不好意思提加班，因为自己犯的错。后面的重传数据，并不是把客户图片放上去就行了，图片名字是程序给的无规律一长串的字符串，我得改成那样的名字，才能对上。。。

　　回到正题，为啥会搞出这样的问题：因为阿里的操作系统是基于centos 8 的（Alibaba Cloud Linux 3.2104 LTS 64位），centos 8 是没有 pam_tally2.so 这个模块，直接就写上去了，连在测试服务器都没测过！！！当时做的采购方案，是没有预留买相同操作系统的测试服务器的（一直想着采购方案怎么压成本），全部都是生产，以至于我对阿里的操作系统很陌生，第一次用。

　　写了这个模块到配置文件没关系，前提是visudo没有去掉普通用户免密码运行root命令的配置，去掉就会导致普通用户怎么样都无法切换到root。最后发现centos 8 需要用 faillock.so。

　　总结就是：

（1）不要太过自信； 

（2）按规范行事（后来我领导还真的搞了个工单记录，说修改生产环境配置前有提交个工单记录，包括问题处理措施，恢复措施，需要申请什么权限等等），改之前一定要做好备份！

（3）不要一知半解，譬如我就不知道pam安全模块的日志都写到 secure 日志里的，而且我还直接忽略报错信息，没去深究报错会影响什么东西

 

生产故障（2）

　　这个也是10月份的生产故障，不过只有前台和我知道，业主方没有发现。。。 　　当时老板想把业主方的网站代码迁回到他们的服务器上，不要放在我们公司域名下，因为想用他们的WAF保护，因为原来一直用我们公司的gitlab，所以需要我在他们服务器上重新部署个gitlab。然后把域名配置到WAF防护下。 　　在测试修改远程关联的gitlab地址时（也就是从我们公司，指回到业务方的服务器上），不知道什么原因，在同步到线上的过程中，竟然把在我们公司的gitlab存放的代码给清空了！！！这个网站一直是从gitlab拉的代码，gitlab代码空了，直接导致网站访问404。 　　幸好我之前空闲没事的时候，做了一主两备的架构，其中一台备机是20分钟同步一次，另一台是晚上同步一次。一主一备代码都被清空了，只能用那台晚上同步一次的备机恢复着先。 　　最终不需要改回到业主方的gitlab，因为gitlab拉取代码的时候用到ssh协议，WAF压根不支持，只支持https协议，迁移回去没有多大意义（总不能git同步的时候开个https协议，每次都需要人手输入账号密码那么麻烦的吧），WAF防护不了他们的代码。所以后来，我再也不需要做这种危险的修改关联gitlab远程仓库的测试（感觉已经超出我的能力水平），业主方这个gitlab也变成备用代码仓库留着。。。 　　因为我告诉老板，不仅WAF保护不了，而且业主方那批服务器还没有快照备份（天翼云），放我们公司名下（阿里云），会更有保障。终逃过一劫。。。 　　

 

标签：10,gitlab,两次,故障,服务器,root,pam,tally2
From： https://www.cnblogs.com/windysai/p/17062274.html