系統密碼過期引發的故障

■ 四川 賴文書

編者按： 近期筆者單位遇到Exadata數據庫未及時更改密碼導致定時任務無法正常運行，就此引發歸檔日志空間占滿，最終導致數據庫被掛起應用系統無法登錄。

筆者單位配 備 了1套Exadata X5-2的數據庫一體機，為應用提供后端數據管理，Exadata是 Oracle軟硬件整合一體化產品，主要用于解決超大型數據庫所存在的普遍性性能瓶頸，也就是磁盤存儲系統向數據庫服務器傳輸大量的數據。Exadata相當于Oracle通過硬件和軟件的組合優化有效的解決了存儲層和數據庫層之間的傳輸瓶頸。

Exadata數據庫一體機軟件層面的安全配置相比其他Oracle數據庫平臺也更高。此次故障也是由于我們對這方面的特性了解不夠深入，因普通的Oracle Linux用戶密碼過期引發了信息系統的故障，并在處理過程中大費周折。

圖1 Oracle告警日志

故障突發用戶無法登錄應用系統

運維的同事突然接到用戶反饋，應用系統無法登錄，經確認系統的Web登錄頁面能正常打開，就是輸入用戶名密碼后報錯。對應用服務器的操作系統、中間件和部署的應用進行檢查，均沒有發現任何問題，結合登錄報錯信息，對后端數據進行檢查，能正常ping通數據庫IP地址，也能正常Telnet應用連接Oracle的1521端口。我們的監測平臺北塔BTSO也對Exadata重點監測，以SNMP協議從Linux操作系統層面，同時也從數據庫實例面層作了實時監測，此時均未發現Oracle數據庫相關報警。

再三分析排查，基本確定引起無法登錄原因還是在后端數據庫。在檢查監測平臺上數據庫實時運行數據時，才猛然發現兩臺DB（數據庫）節點的會話數都是0，平時都是在1000左右，根據以往巡檢歷史數據的經驗，即使在晚上也是400左右。再次查看近24小時會話數曲線圖，確認從昨晚凌晨0點45分會話數開始異常，持續到現在。

在確定了引發故障的具體區域范圍后，立刻聯系公司高級DBA進行遠程協助診斷。通過SQLPlus能正常連接到數據庫實例，確認Oracle數據庫也是open狀態，只是用select語句進行數據表檢索時無法返回結果，再結合數據庫的alert告警日志分析如圖1，有經驗的DBA很快意識到是歸檔日志空間滿了導致數據庫被hang住。

由于歸檔日志是Oracle數據庫在線日志文件的備份，用于恢復到任意時間點而不丟數據，所以此時還不能急于直接清理，先檢查這些歸檔日志是否已經有相應備份。公司使用NBU（Veritas NetBackup Appliance）一體機對該數據庫進行的備份，確認備份無誤后進行手動清理歸檔日志所在FRA（Flash Recovery Area）快速恢復區目錄中的文件，由于是在操作系統手動刪除，存儲數據庫相關元數據的控制文件無法感知其變化，還得在RMAN(Recovery Manager)恢復管理器使用“crosscheck archivelog all”命令進行更新，待一系列操作完成后，數據恢復正常，用戶也能順利地登錄應用系統了。

緊急的問題算是解決了，只是數據庫的歸檔日志空間為什么會滿呢？以往一直在linux層面配置了Crontab定時任務，使用shell腳本自動清除指定天數以前的歸檔日志文件，難道腳本沒有正常工作，還得進一步排查故障的深層原因。

圖2 無法編輯Crontab

發現Oracle用戶無法編輯crontab任務

首先檢查腳本文件/home/oracle/scripts/ArchRM.sh正常，再檢查確認腳本配置如下：

e x p o r t T Z=A s i a/Shanghai

export ORACLE_BASE=/u01/app/oracle

export ORACLE_HOME=/u01/app/oracle/product/12.1.0.2/dbhome_1

export ORACLE_SID=CCK02

export PATH=$PATH:$ORACLE_HOME/bin

rman target=/ log=/home/oracle/scripts/ArchRM.log <

run

{

d e l e t e n o p r o m p t archivelog until time"sysdate-5"; #刪除5天前的oracle歸檔日志

}

EOF

正找不著頭緒時，用crontab -e編輯任務時居然報錯“Authentication token expired，You (oracle) are not allowed to access to (crontab) because of pam configuration.” 如圖2所示。起初判斷報錯為Oracle用戶沒有相關權限，于是查詢網上資料怎樣給普通用戶授權，依次檢查各項配置又都是正常的。再回頭細看報錯信息，其中Authentication token是用戶登錄Linux后生成的，由于此次一系列操作中，均是以root賬號登錄，再用命令“su- oracle”切換到Oracle用戶的，于是試著“ssh -l -u oracle@192.168.100.5”登錄居然失敗。難道是密碼記錯了，試了多次均無果，只得以root賬號下用命令“passwd oralce”強制修改密碼，然后再用Oracle密碼登錄結果還是一樣，真是邪門兒了，又沒啥提示信息，診斷的方向都沒了。

我們只能再向公司資深工程師求助，反饋Exadata的Oracle用戶無法登錄Linux，剛開始他也是提出了上面改密碼的方法，可是試過了沒用。無奈只得遠程協助檢查，用命令“cat /etc/passwd |grep oracle”檢查配置文件該用戶最后一列的shell類型不是“/sbin/nologin；cat /etc/shadow|grep oracle”，第二列密碼項也非“*”； 測試從不同網卡的IP進行登錄，情況依舊；檢查了ssh配置文件“/etc/ssh/ssh_config”，未發現有任何對該登錄的限制；嘗試passwd修改密碼再登錄情況依舊。解決問題的思路都耗光了，到底原因在哪兒呢？

以前在學習視頻課程中，還略微記得講過pam模塊（Pluggable Authentication Module）和用戶登錄驗證有關，于是搜索關鍵字“linux賬號密碼鎖定策略”，發現一篇相關文章，從RedHat Linux6開 始pam.d使 用pam_tally2.so，而 老 版 本使用的pam_tally.so的“reset”、”no_magic_root”和”no_reset”選項在pam_tally2.so已經沒有了；sshd所包含的pam認證文件是password_auth，而不是system_auth。檢查Exadata主機操作系統相關文件，在/etc/pam.d/sshd發現存在對應的配置如圖3，導致輸入錯誤密碼被鎖定而無法登錄，且賬戶已鎖定時ssh登錄默認是不會顯示任何信息的，可以修改sshd_config文件中的配置項ChallengeRespo nseAuthentication?yes?。

根據以上資料使用命令“pam_tally2 -u oracle”查看oralce賬戶的鎖定情況，再運行命令“pam_tally2?-u?oracle?-r”重置賬戶的登錄失敗次數，最后用Oracle賬戶順利登錄操作系統，定時刪除過期歸檔日志任務也正常運行了。

圖3 pam模塊配置sshd登錄

Exadata安全配置初步分析

通過學習李亞著的《Oracle Exadata技 術 詳解》，才知道了一體機的安全相關配置情況。

1.最小安裝的原則。作為數據庫服務器只需要提供數據庫服務，杜絕安裝其他不相關的應用。

2.安裝啟動最少的服務。“通常安裝的服務越多，發生漏洞的機會也越多”。

總而言之，新課程背景下提高小學語文教學的有效性對于提高學生的語文水平具有重要的作用。教師在教學活動中需要具備足夠的耐性，充分了解學生在學習過程中發現的問題。并且在教學活動中需要不斷創新教學模式、豐富教學活動，不斷提高小學語文教學活動的有效性。

3.使用安全增強工具。在Exadata的Cell節點是開啟了iptables服務，并在其中加入了相應的安全規則。

4.網段隔離的原則。Exadata共包括三個網段，生產網對外提供數據庫服務，管理網是用來Exadata管理員對Exadata進行維護和管理， 而私網則用于各節點內部通信和交換數據。

5.移除圖形界面Xwindow。Exadata的管理并不需要圖形界面，所有的工作都可以通過命令行來完成。

6.對用戶和密碼進行加固，對于放置核心數據的數據庫服務器，主要是為了防止暴力破解之類的方法給系統帶來的風險。

7.移除或者限制SSH。僅允許指定用戶組里面的用戶使用SSH登錄。

8.保證軟件包保持最（較）新。新版本不僅對程序本身bug做了修復，同時對已發現的安全漏洞進行了修復。

9.移除特殊權限SUID/SGID。Exadata安裝完成后已經將不需要的權限移除了。

10.對NTP進行優化和加固。系統時間大幅度跳變可能引起Exadata數據庫服務器及存儲服務器宕機。

11.對內核參數進行加固，如禁用了IP包轉送、IP源路由等。

12.增強共享文件系統的安全性。

解除Exadata默認的安全限制

在廠商工程師安裝部署一體機時用OneCommand程序對Exadata進行初始化，并且執行完步驟ResecureMachine后，對初始密碼進行重置，并且修改其復雜度，以使系統更加安全。

但是很多客戶已有公司的一套密碼及加固標準方 案，Exadata默 認 的 加固方案可能并不適用。如果Exadata的安全方案進行重新設置，那么需要先解除其默認的安全限制。從OneCommand的安裝日志中可以看到ResecureMachine這一步實際上調用“/opt/oracle.SupportTools/harden_passwords_reset_root_ssh”這個腳本，要了解此腳本做對系統所做的配置，就要先查看其內容。

cat /opt/oracle.SupportTools/harden_passwords_reset_root_ssh

# sed -i "s/5，5，5，5，5 /disabled ， disabled， 16 ， 12 ， 8 / g ;" /etc/pam.d /eystem-auth

此命令將/etc/pam.d/system-auth文 件 中的 5.5.5.5 用 disabled，disabled，16，12，8 替 換，替換以后新的密碼規則變為：不接受任何單字符類型的口令，不接受任何兩種字符類型混合的口令，口令字(passphrases)最小長度為16位，三種字符類型混合口令最小長度為12位，四種字符類型混合口令最小長度為5位。其中四種字符類型分別為“數字”、“小寫字母”、“大寫字母”及“其他字符”。要解除此限制，執行與之相對應的逆向替換命令即可。

# sed -i " s/ disabled， disabled ， 16 ， 12 ， 8/ 5 ， 5 ， 5 ， 5 ， 5 / g ;" /etc/pam.d /eystem-auth

#/bin/rm -rf /root/.ssh

從該命令可知，resecure這一步刪除了root用戶的密鑰，就意味著root用戶的ssh等效性被移除，如果需要撤銷這一步，那么需要重新建立root用戶的ssh等效性。幸運的是在Exadata上，想要重建某一用戶的ssh等效性，并不需要單獨對每個節點逐一地進行等效性配置。Exadata提供了一個名為setup_ssh_eq.sh的腳本用于重建ssh等效性。此命令的運行格式如下：

# /o p t/o r a c l e.SupportTools/setup ssh eg.sh /opt/oracle.SupportTools/onecommand/

all_group root 其中第一個參數需要配置root用戶ssh等效性的節點名稱，第二個參數為用戶名，第三個參數為root用戶的密碼。值得注意的是，運行這個腳本有一個前提，是在建立等效性的時候所有節點的密碼必須一致。同時注意到，在resecure步驟運行完以后，會設置ssh的登錄超時時間。此配置實際上參數文件/etc/ssh/sshd config 中添加了一行ClientAlivelnterval 30。

操作系統中Oracle賬號被修改成了90天密碼過期必須更改，可通過Linux命令“chage -M 99999 oracle”，即可使該賬號的密碼永不過期，或將密碼過期時間配置成符合公司安全策略。

總結

此次故障是正是由于未及時按照規定更改操作系統密碼導致定時任務無法正常運行，從而引發歸檔日志空間占滿，最終導致數據庫被掛起應用系統無法登錄。同時暴露出我們運維工作中一些薄弱的環節。另外我們對于Exadata操作系統的安全配置不夠熟悉，未能及時發現用戶密碼過期的情況，導致排查故障時找不到正確的方向，就因為操作系統的小問題引發了整個應用系統的故障。