這是一篇我早就應該寫的文章，但一直懶癌發作，so……
彩蛋：晚些時候主站會更新一篇關於 Pragmata 的評測，至於時間，嗯……
一個項目上，由於甲方原本購買的 Saas 軟件到期了，嫌功能較少之類的，不想續費，找到我司。舊軟件是部署在甲方自行購買的伺服器上，而前軟件公司拒絕幫忙導出數據，及甲方擔心前軟件公司會搗亂，刪除數據之類的，故希望我司幫忙先備份數據。
事情自然而然地落到我頭上。
甲方提供了登入信息 —— 用 root 登入，只有長密碼保護，也算是不安全中的安全了。進去看了一圈常見的 /home 和 /www，發現有寶塔面板的痕跡，當時就開始覺得奇怪了。
偷偷 nmap 了一下，發現提供的兩台伺服器除了對外暴露 80 和 443 之外，還暴露 3306，他們是怎麼做到沒有中 db 勒索的？
總之，看來看去沒有看到業務使用的配置文件有在哪裏寫下數據庫密碼的痕跡，當時已發現使用的是 mysql，不想用 skip-grant-table 的方式進，一是操作會有些限制，二是實在好奇心上來了，想研究一下。
當然最後也沒找到，top 裡有不少 java，最終也只找到幾個業務 jar。
百度找了一下（這種知識真的是奇怪地只能在百度找到）「java springboot 寶塔」這樣的關鍵字，發現有一種寶塔部署的方式，是把配置文件放在 jar 裡，部署時再指定 jar 內的配置文件。
把 jar 下到本地一看，果然是這樣的設計，甚至連這家公司其它生產環境的 db connect string 都齊齊整整擺在裡面，明文。
我：(=_=)
之前不知道那家前軟件公司對待 SaaS 過期之後是怎麼處理的，不過昨天甲方詢問，前軟件登入賬户被限制，問我能不能修改。
再次進入 db，show tables status，找到備註對應操作員的表，select * 出來看看，發現只是把 STATUS 那列改成了 DISABLE（此處我實在是很好奇為什麼要用 string 來管理狀態，正常情況下應該是使用 0/1/2 之類的，至少不能讓人一眼就看出來），做了個好事，把甲方提供的賬户這列都改回 ENABLE 就可以登入了。
這家前軟件公司，我實在是想不到怎麼能接到業務，至少有三個危險操作：
- 3306 對公網暴露而且真的可以登入；
- 伺服器上不應允許 root@localhost 登入；
- 其它生產環境密碼直接明文保存在 jar 內，而且這份 jar 四處分發；
- 這點應該算是甲方運維的問題，伺服器不應使用密碼登入。
世界真的是個大草台班子。
伺服器安全是個很神奇的領域，上下限相差得太多。很多方面是那些只懂看數據 / KPI 的白痴領導所無法觸及的。
説得難聽一點，如果運維利用職便，在伺服器上擺自己的服務，實際上也可能沒有人知道。
發佈留言