公司目前用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先承報告上去 告知可能風險 若不更新 發生列表中的風險責任不該由系統管理員全擔
樓上的方式試過，但出問題必須證明是因為這個漏洞而且會被說不負責任