公司目前用CentOS当作Server OS
但从来没有更新过…
而个人职务为系统工程师，当然不希望这样下去…
问题在于许多研发人员认为
一直都没更新也没遇过什么资安问题
为什么现在要更新？
更新出了问题谁负责？
为什么要从 CentOS 6 改到 CentOS 7？
为什么CentOS 5 EOL 就不能用了？
而我说明可以从测试环境开始更新
依序进行，却又被说没有那么多时间配合测试
而且如何保证每个环境都相同？？？
就说完全一样，他们却说他们上面的程式版本不同
那只好使出手段，提到如不配合更新
本人不会负责任何系统上的资安责任
但却被针对系统工程师却不负责资讯系统安全？
觉得好笑的事情是，系统工程师却没有系统决定权
却需要负责所有系统的责任
重点是，以下这句话…
“很久没更新却又没遇过任何资安事件”
是因为 Linux 的定时安全性更新真的不重要吗？
但我个人观点是认为更新漏洞是非常重要的
定时安排并测试本来就是工作项目
不知道这边的版友对于Linux系统更新想法是？
还是如同他们想法，是我个人找研发人员麻烦…
在离职为最后手段下，有没有什么好建议呢？
有对外吗？有可能加防火墙或是设定 iptables rule 因应？先把新的系统建起来，再请他们慢慢移过去系统工程师的权利不包含随意更新系统，除非你能确保不影响既有的功能跟其他人的工作讲白一点，公司要的是产出，被攻击当然会影响产出，但是如果更新也会，哪跟被攻击有什么不同？
作者:
da21510 (da21510)
2018-11-12 07:43:00我是支持更新的但刚更新我自己的Server然后等等要跑一趟机房了现在啥都不能干给你参考一下如果要更把change log什么之类的全看清楚然后请假睡到饱隔天再更之前我还是小白的时候没看清楚把php从5.6更到7 ……然后刚刚是整晚没睡脑还没想好 手已经敲下去了敲完马上后悔
楼上说的应该是 patch, 事实上很多时候修 bug 跟漏洞的方式是要你更新版本
可能我说得部分不够清楚，这边只是针对小版号更新但无论大小更新，都是从测试环境开始部署也跟1F说得，采取先建后拆，但问题是研发认为不需要ChangLog部分也会先看是否有影响功能面VM不只一台，通常都是更新一周后没问题才执行下一台不过我不认同你说得随意更动系统如果是随意更动，那当然是我的责任可是要如何创造双赢的局面，让研发了解严重性？我认为系统不能分内外网而有所不同许多异常行为往往是内部人员造成的不过看来大家都认为更新是有必要性的吧？
更新有其必要性，也一定会遇到阻力跟问题，这是资讯人员存在的价值，如果没必要，都不更新，或是不会有问题，找个工读生打打指令，那还要资讯人员干嘛？
作者:
guezt 2018-11-12 10:25:00看主管支不支持 如果主管不认同 那也没办法做下去
作者:
guezt 2018-11-12 10:26:00另外还在维护中的版本 套件应该都是小更新 不致于造成影响
我会尽力说服他们看看的…g大想法没错，但研发可不是这么想…他们只觉得我用得好好的，干嘛更新还有配合测试而已
作者:
guezt 2018-11-12 10:31:00金融相关产业有一堆稽核法规要你更新 其他就自主管制了先搞定你主管 再让主管去搞定研发
再怎么更新版本也不会像 distro upgrade 那样升版吧 XD
作者:
noonee (我和烤肉间只差一撮孜然)
2018-11-12 12:42:00对于重要长期使用的 server 不要太常更新大版本比较好需要更新的只是安全性更新吧？以debian 来说 只需要做security update 就好另外不要小看大版本的更新 尤其是gcc 总是让我被迫在本地自己装gcc 来应付问题另外 为了配合大家各自不同的使用环境 可以试试看用module如果真的只是安全更新 软件的大版本号都不会变吧?
主要是推动小版号更新，大版本都是先建后拆进行我再努力看看，感谢大家回答
作者:
rexsony (雷克斯索尼)
2018-11-12 13:30:00当然是离职囉，这种鸟公司。还想救？
作者: dou0228 (7777) 2018-11-12 15:44:00
真实情况是，一堆 RD 根本也不知道 CentOS 5/6/7 差别在哪，当然，程式码也没有抽离开系统，通通用 sys default当遇到系统要升级时，就一推 456 说不升级
作者:
lspci (awk sed echo)
2018-11-12 18:55:00风险评估先 好吗？
作者:
rexsony (雷克斯索尼)
2018-11-12 23:37:00这种跟电信业很像,尤其是MD要它动CDR简直是要死给你看但是在工作经验当中,通常都是先建后拆.如果有非升级不可的理由,要换新系统都是这个做法若是单纯只是弱扫问题,就iptables DROP掉它 xD其实我碰过rehat 6.7搭tomcat ver7版本有弱扫问题就是一直升到tomcat 7版本最后一版,再有问题就是大家下来先在Labs测tomcat 8的相容性再做升版SOP跟rollback准备基本上主机如果没有对外的话,更新的理由就还好了除非这台主机有对外服务,那安全性的东西就是要一直升
作者: iflyinsky (加油！前进～) 2018-11-13 00:16:00
虽然觉得更新是一种必然，却也会有推动不了的时候。往往在同行发生过类似的事件，才会意识到其重要性。如果系统工程师是资安的最后防线，那就看良心与遮羞费是否可以重过天平的另一端。
docker 处理直接上 centos7 装 docker-ce docker-compose全部包成 container 就没有套件版本相容问题如果没办法 就让旧机器不能对外 外面加一层新机器做防护
作者:
soem (æµæ°´)
2018-11-13 01:00:00推iflyinsky板友，这工作真的要择善固执点
我公司的也是这样子，手上甚至还有RHEL3...不过这个需要太多单位配合，加上重心又不在这款产品上，没有办法做甚至有些程式原本是在32bit环境下开发，CentOS7只有64bibit，转过去不能保证一定不会有问题
一般 security update 可以，但是换整个大版本要评估
我觉得真要做，让其他单位了的话提出完整的企划比较好说错，真要做的话提出企划让其他单位了解比较好
作者:
chang0206 (Eric Chang)
2018-11-13 13:49:00有办法可以把整个OS包成docker喔？
改用container，其实更需要RD的配合…我的想法是，如果不制定一个良好的更新流程只会越欠越多，我觉得作假不是我想做的事情虽然ISMS只是一张纸，但我还是想照着做来这里问，只是想知道是不是很多公司都不管这件事情之前有考过ISO 27001，但发现主导很多阻力但看完各位的推文，我相信我坚持更新应该是对的谢谢各位的回答
作者: brli7848 (无理阿？) 2018-11-14 23:43:00
上级不重视，出事下级背，赞
作者: TWLAB (AlphaGO) 2018-11-17 09:59:00
要玩就先备份再更新
作者: dou0228 (7777) 2018-11-19 10:20:00
RD 愿意帮忙就没问题，不愿意你就准备背锅。
作者: onionys (Why?Why?) 2018-11-19 11:50:00
更新后的系统是否可靠，我觉得要有严谨的测试报告才能说服保守牌的疑虑感觉要先建立测试机制和项目测得越严谨说信心越强自动选字让我失去打字的信心了...
作者:
dave01 (札西连琪)
2018-11-23 11:12:00先承报告上去 告知可能风险 若不更新 发生列表中的风险责任不该由系统管理员全担
楼上的方式试过，但出问题必须证明是因为这个漏洞而且会被说不负责任
有对外吗？有可能加防火墙或是设定 iptables rule 因应？先把新的系统建起来，再请他们慢慢移过去系统工程师的权利不包含随意更新系统，除非你能确保不影响既有的功能跟其他人的工作讲白一点，公司要的是产出，被攻击当然会影响产出，但是如果更新也会，哪跟被攻击有什么不同？
作者:
da21510 (da21510)
2018-11-12 15:43:00我是支持更新的但刚更新我自己的Server然后等等要跑一趟机房了现在啥都不能干给你参考一下如果要更把change log什么之类的全看清楚然后请假睡到饱隔天再更之前我还是小白的时候没看清楚把php从5.6更到7 ……然后刚刚是整晚没睡脑还没想好 手已经敲下去了敲完马上后悔
楼上说的应该是 patch, 事实上很多时候修 bug 跟漏洞的方式是要你更新版本
可能我说得部分不够清楚，这边只是针对小版号更新但无论大小更新，都是从测试环境开始部署也跟1F说得，采取先建后拆，但问题是研发认为不需要ChangLog部分也会先看是否有影响功能面VM不只一台，通常都是更新一周后没问题才执行下一台不过我不认同你说得随意更动系统如果是随意更动，那当然是我的责任可是要如何创造双赢的局面，让研发了解严重性？我认为系统不能分内外网而有所不同许多异常行为往往是内部人员造成的不过看来大家都认为更新是有必要性的吧？
更新有其必要性，也一定会遇到阻力跟问题，这是资讯人员存在的价值，如果没必要，都不更新，或是不会有问题，找个工读生打打指令，那还要资讯人员干嘛？
作者:
guezt 2018-11-12 18:25:00看主管支不支持 如果主管不认同 那也没办法做下去
作者:
guezt 2018-11-12 18:26:00另外还在维护中的版本 套件应该都是小更新 不致于造成影响
我会尽力说服他们看看的…g大想法没错，但研发可不是这么想…他们只觉得我用得好好的，干嘛更新还有配合测试而已
作者:
guezt 2018-11-12 18:31:00金融相关产业有一堆稽核法规要你更新 其他就自主管制了先搞定你主管 再让主管去搞定研发
再怎么更新版本也不会像 distro upgrade 那样升版吧 XD
作者:
noonee (我和烤肉间只差一撮孜然)
2018-11-12 20:42:00对于重要长期使用的 server 不要太常更新大版本比较好需要更新的只是安全性更新吧？以debian 来说 只需要做security update 就好另外不要小看大版本的更新 尤其是gcc 总是让我被迫在本地自己装gcc 来应付问题另外 为了配合大家各自不同的使用环境 可以试试看用module如果真的只是安全更新 软件的大版本号都不会变吧?
主要是推动小版号更新，大版本都是先建后拆进行我再努力看看，感谢大家回答
作者:
rexsony (雷克斯索尼)
2018-11-12 21:30:00当然是离职囉，这种鸟公司。还想救？
作者: dou0228 (7777) 2018-11-12 23:44:00
真实情况是，一堆 RD 根本也不知道 CentOS 5/6/7 差别在哪，当然，程式码也没有抽离开系统，通通用 sys default当遇到系统要升级时，就一推 456 说不升级
作者:
lspci (awk sed echo)
2018-11-13 02:55:00风险评估先 好吗？
作者:
rexsony (雷克斯索尼)
2018-11-13 07:37:00这种跟电信业很像,尤其是MD要它动CDR简直是要死给你看但是在工作经验当中,通常都是先建后拆.如果有非升级不可的理由,要换新系统都是这个做法若是单纯只是弱扫问题,就iptables DROP掉它 xD其实我碰过rehat 6.7搭tomcat ver7版本有弱扫问题就是一直升到tomcat 7版本最后一版,再有问题就是大家下来先在Labs测tomcat 8的相容性再做升版SOP跟rollback准备基本上主机如果没有对外的话,更新的理由就还好了除非这台主机有对外服务,那安全性的东西就是要一直升
作者: iflyinsky (加油！前进～) 2018-11-13 08:16:00
虽然觉得更新是一种必然，却也会有推动不了的时候。往往在同行发生过类似的事件，才会意识到其重要性。如果系统工程师是资安的最后防线，那就看良心与遮羞费是否可以重过天平的另一端。
docker 处理直接上 centos7 装 docker-ce docker-compose全部包成 container 就没有套件版本相容问题如果没办法 就让旧机器不能对外 外面加一层新机器做防护
作者:
soem (æµæ°´)
2018-11-13 09:00:00推iflyinsky板友，这工作真的要择善固执点
我公司的也是这样子，手上甚至还有RHEL3...不过这个需要太多单位配合，加上重心又不在这款产品上，没有办法做甚至有些程式原本是在32bit环境下开发，CentOS7只有64bibit，转过去不能保证一定不会有问题
一般 security update 可以，但是换整个大版本要评估
我觉得真要做，让其他单位了的话提出完整的企划比较好说错，真要做的话提出企划让其他单位了解比较好
作者:
chang0206 (Eric Chang)
2018-11-13 21:49:00有办法可以把整个OS包成docker喔？
改用container，其实更需要RD的配合…我的想法是，如果不制定一个良好的更新流程只会越欠越多，我觉得作假不是我想做的事情虽然ISMS只是一张纸，但我还是想照着做来这里问，只是想知道是不是很多公司都不管这件事情之前有考过ISO 27001，但发现主导很多阻力但看完各位的推文，我相信我坚持更新应该是对的谢谢各位的回答
作者: brli7848 (无理阿？) 2018-11-15 07:43:00
上级不重视，出事下级背，赞
作者: TWLAB (AlphaGO) 2018-11-17 17:59:00
要玩就先备份再更新
作者: dou0228 (7777) 2018-11-19 18:20:00
RD 愿意帮忙就没问题，不愿意你就准备背锅。
作者: onionys (Why?Why?) 2018-11-19 19:50:00
更新后的系统是否可靠，我觉得要有严谨的测试报告才能说服保守牌的疑虑感觉要先建立测试机制和项目测得越严谨说信心越强自动选字让我失去打字的信心了...
作者:
dave01 (札西连琪)
2018-11-23 19:12:00先承报告上去 告知可能风险 若不更新 发生列表中的风险责任不该由系统管理员全担
楼上的方式试过，但出问题必须证明是因为这个漏洞而且会被说不负责任