PTT數位生活區 / Linux

[閒聊] 關於 Linux 系統更新的安全看法？

看板Linux作者 (Nash)時間6年前 (2018/11/12 00:52), 編輯推噓21(22推 1噓 92→)
留言115則, 22人參與, 6年前最新討論串1/1
公司目前用CentOS當作Server OS 但從來沒有更新過… 而個人職務為系統工程師，當然不希望這樣下去… 問題在於許多研發人員認為 一直都沒更新也沒遇過什麼資安問題 為什麼現在要更新？ 更新出了問題誰負責？ 為什麼要從 CentOS 6 改到 CentOS 7？ 為什麼CentOS 5 EOL 就不能用了？ 而我說明可以從測試環境開始更新 依序進行，卻又被說沒有那麼多時間配合測試 而且如何保證每個環境都相同？？？ 就說完全一樣，他們卻說他們上面的程式版本不同 那只好使出手段，提到如不配合更新 本人不會負責任何系統上的資安責任 但卻被針對系統工程師卻不負責資訊系統安全？ 覺得好笑的事情是，系統工程師卻沒有系統決定權 卻需要負責所有系統的責任 重點是，以下這句話… “很久沒更新卻又沒遇過任何資安事件” 是因為 Linux 的定時安全性更新真的不重要嗎？ 但我個人觀點是認為更新漏洞是非常重要的 定時安排並測試本來就是工作項目 不知道這邊的版友對於Linux系統更新想法是？ 還是如同他們想法，是我個人找研發人員麻煩… 在離職為最後手段下，有沒有什麼好建議呢？ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.136.32.146 ※ 文章網址: https://www.ptt.cc/bbs/Linux/M.1541955172.A.D42.html
推
11/12 01:52, 6年前 , 1F
有對外嗎？有可能加防火牆或是設定 iptables rule 因
11/12 01:52, 1F
→
11/12 01:52, 6年前 , 2F
應？
11/12 01:52, 2F
→
11/12 01:53, 6年前 , 3F
先把新的系統建起來，再請他們慢慢移過去
11/12 01:53, 3F
→
11/12 01:54, 6年前 , 4F
系統工程師的權利不包含隨意更新系統，除非你能確保
11/12 01:54, 4F
→
11/12 01:54, 6年前 , 5F
不影響既有的功能跟其他人的工作
11/12 01:54, 5F
→
11/12 01:55, 6年前 , 6F
講白一點，公司要的是產出，被攻擊當然會影響產出，
11/12 01:55, 6F
→
11/12 01:55, 6年前 , 7F
但是如果更新也會，哪跟被攻擊有什麼不同？
11/12 01:55, 7F
→
11/12 07:43, 6年前 , 8F
我是支持更新的
11/12 07:43, 8F
→
11/12 07:43, 6年前 , 9F
但剛更新我自己的Server
11/12 07:43, 9F
→
11/12 07:43, 6年前 , 10F
然後等等要跑一趟機房了
11/12 07:43, 10F
→
11/12 07:43, 6年前 , 11F
現在啥都不能幹
11/12 07:43, 11F
→
11/12 07:43, 6年前 , 12F
給你參考一下
11/12 07:43, 12F
→
11/12 07:52, 6年前 , 13F
如果要更
11/12 07:52, 13F
→
11/12 07:52, 6年前 , 14F
把change log什麼之類的全看清楚
11/12 07:52, 14F
→
11/12 07:52, 6年前 , 15F
然後請假睡到飽
11/12 07:52, 15F
→
11/12 07:52, 6年前 , 16F
隔天再更
11/12 07:52, 16F
→
11/12 07:52, 6年前 , 17F
之前我還是小白的時候沒看清楚把php從5.6更到7 ……
11/12 07:52, 17F
→
11/12 07:52, 6年前 , 18F
然後剛剛是整晚沒睡
11/12 07:52, 18F
→
11/12 07:52, 6年前 , 19F
腦還沒想好 手已經敲下去了
11/12 07:52, 19F
→
11/12 07:52, 6年前 , 20F
敲完馬上後悔
11/12 07:52, 20F
推
11/12 08:39, 6年前 , 21F
那叫升級吧。更新不是只修漏洞跟bug？
11/12 08:39, 21F
推
11/12 08:49, 6年前 , 22F
樓上說的應該是 patch, 事實上很多時候修 bug 跟漏洞
11/12 08:49, 22F
→
11/12 08:49, 6年前 , 23F
的方式是要你更新版本
11/12 08:49, 23F
→
11/12 08:55, 6年前 , 24F
可能我說得部分不夠清楚，這邊只是針對小版號更新
11/12 08:55, 24F
→
11/12 08:56, 6年前 , 25F
但無論大小更新，都是從測試環境開始部署
11/12 08:56, 25F
→
11/12 08:57, 6年前 , 26F
也跟1F說得，採取先建後拆，但問題是研發認為不需要
11/12 08:57, 26F
→
11/12 08:59, 6年前 , 27F
ChangLog部分也會先看是否有影響功能面
11/12 08:59, 27F
→
11/12 09:00, 6年前 , 28F
VM不只一台，通常都是更新一週後沒問題才執行下一台
11/12 09:00, 28F
→
11/12 09:00, 6年前 , 29F
不過我不認同你說得隨意更動系統
11/12 09:00, 29F
→
11/12 09:01, 6年前 , 30F
如果是隨意更動，那當然是我的責任
11/12 09:01, 30F
→
11/12 09:01, 6年前 , 31F
可是要如何創造雙贏的局面，讓研發了解嚴重性？
11/12 09:01, 31F
→
11/12 09:02, 6年前 , 32F
我認為系統不能分內外網而有所不同
11/12 09:02, 32F
→
11/12 09:02, 6年前 , 33F
許多異常行為往往是內部人員造成的
11/12 09:02, 33F
→
11/12 09:04, 6年前 , 34F
不過看來大家都認為更新是有必要性的吧？
11/12 09:04, 34F
推
11/12 09:13, 6年前 , 35F
更新有其必要性，也一定會遇到阻力跟問題，這是資訊人
11/12 09:13, 35F
→
11/12 09:13, 6年前 , 36F
員存在的價值，如果沒必要，都不更新，或是不會有問題
11/12 09:13, 36F
→
11/12 09:13, 6年前 , 37F
，找個工讀生打打指令，那還要資訊人員幹嘛？
11/12 09:13, 37F
→
11/12 10:25, 6年前 , 38F
問題是他們認為我們就是打打指令就好…
11/12 10:25, 38F
推
11/12 10:25, 6年前 , 39F
看主管支不支持 如果主管不認同 那也沒辦法做下去
11/12 10:25, 39F
還有 36 則推文
→
11/13 00:16, 6年前 , 76F
系統工程師是資安的最後防線，那就看良心與遮羞費是否
11/13 00:16, 76F
→
11/13 00:16, 6年前 , 77F
可以重過天平的另一端。
11/13 00:16, 77F
推
11/13 00:51, 6年前 , 78F
docker 處理
11/13 00:51, 78F
→
11/13 00:52, 6年前 , 79F
直接上 centos7 裝 docker-ce docker-compose
11/13 00:52, 79F
→
11/13 00:52, 6年前 , 80F
全部包成 container 就沒有套件版本相容問題
11/13 00:52, 80F
→
11/13 00:53, 6年前 , 81F
如果沒辦法 就讓舊機器不能對外 外面加一層新機器做防護
11/13 00:53, 81F
推
11/13 01:00, 6年前 , 82F
推iflyinsky板友，這工作真的要擇善固執點
11/13 01:00, 82F
推
11/13 11:49, 6年前 , 83F
我公司的也是這樣子，手上甚至還有RHEL3...不過這個需要
11/13 11:49, 83F
→
11/13 11:50, 6年前 , 84F
太多單位配合，加上重心又不在這款產品上，沒有辦法做
11/13 11:50, 84F
→
11/13 11:51, 6年前 , 85F
甚至有些程式原本是在32bit環境下開發，CentOS7只有64bi
11/13 11:51, 85F
→
11/13 11:51, 6年前 , 86F
bit，轉過去不能保證一定不會有問題
11/13 11:51, 86F
→
11/13 11:57, 6年前 , 87F
一般 security update 可以，但是换整個大版本要評估
11/13 11:57, 87F
推
11/13 11:59, 6年前 , 88F
我覺得真要做，讓其他單位了的話提出完整的企劃比較好
11/13 11:59, 88F
推
11/13 13:33, 6年前 , 89F
說錯，真要做的話提出企劃讓其他單位瞭解比較好
11/13 13:33, 89F
推
11/13 13:49, 6年前 , 90F
有辦法可以把整個OS包成docker喔？
11/13 13:49, 90F
→
11/13 14:14, 6年前 , 91F
改用container，其實更需要RD的配合…
11/13 14:14, 91F
→
11/13 14:17, 6年前 , 92F
我的想法是，如果不制定一個良好的更新流程
11/13 14:17, 92F
→
11/13 14:18, 6年前 , 93F
只會越欠越多，我覺得作假不是我想做的事情
11/13 14:18, 93F
→
11/13 14:18, 6年前 , 94F
雖然ISMS只是一張紙，但我還是想照著做
11/13 14:18, 94F
→
11/13 14:20, 6年前 , 95F
來這裡問，只是想知道是不是很多公司都不管這件事情
11/13 14:20, 95F
→
11/13 14:22, 6年前 , 96F
之前有考過ISO 27001，但發現主導很多阻力
11/13 14:22, 96F
→
11/13 14:23, 6年前 , 97F
但看完各位的推文，我相信我堅持更新應該是對的
11/13 14:23, 97F
→
11/13 14:23, 6年前 , 98F
謝謝各位的回答
11/13 14:23, 98F
推
11/13 23:02, 6年前 , 99F
不要太熱血，時間拿來修問題，不更新其實不會怎樣。
11/13 23:02, 99F
→
11/14 21:57, 6年前 , 100F
拿來應付上級自己也不重視的機器不用太...?
11/14 21:57, 100F
→
11/14 23:43, 6年前 , 101F
上級不重視，出事下級背，讚
11/14 23:43, 101F
→
11/15 00:40, 6年前 , 102F
所以才想要改變一下公司的想法…
11/15 00:40, 102F
推
11/16 14:16, 6年前 , 103F
新版本又不是一定沒其它問題
11/16 14:16, 103F
推
11/17 09:59, 6年前 , 104F
要玩就先備份再更新
11/17 09:59, 104F
→
11/18 22:21, 6年前 , 105F
所以不更新不測試會比較好嗎？
11/18 22:21, 105F
推
11/19 10:20, 6年前 , 106F
RD 願意幫忙就沒問題，不願意你就準備背鍋。
11/19 10:20, 106F
推
11/19 11:50, 6年前 , 107F
更新後的系統是否可靠，我覺得要有嚴謹的測試報告才能說
11/19 11:50, 107F
→
11/19 11:50, 6年前 , 108F
服保守牌的疑慮
11/19 11:50, 108F
推
11/19 11:52, 6年前 , 109F
感覺要先建立測試機制和項目
11/19 11:52, 109F
推
11/19 11:55, 6年前 , 110F
測得越嚴謹說信心越強
11/19 11:55, 110F
→
11/19 11:56, 6年前 , 111F
自動選字讓我失去打字的信心了...
11/19 11:56, 111F
→
11/23 11:12, 6年前 , 112F
先承報告上去 告知可能風險 若不更新 發生列表中的風險
11/23 11:12, 112F
→
11/23 11:12, 6年前 , 113F
責任不該由系統管理員全擔
11/23 11:12, 113F
→
11/24 00:55, 6年前 , 114F
樓上的方式試過，但出問題必須證明是因為這個漏洞
11/24 00:55, 114F
→
11/24 00:56, 6年前 , 115F
而且會被說不負責任
11/24 00:56, 115F
‣ 更多 kenwufederer 的文章
文章代碼(AID): #1Rw5var2 (Linux)
Linux 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 kenwufederer 的文章
文章代碼(AID): #1Rw5var2 (Linux)