調查了一起開發測試過程引發 Windows 稽核失敗事件的案例。

本機不小心在 Visual Studio 啟動了某個測試網站專案,在另一個伺服器留下多筆操作登入使用者登入失敗的 Windows 安全事件:

依據微軟文件,4625 事件用於記錄任何登入失敗,留存在嘗試登入的電腦上。這個事件也是之前我在實用小工具 - 查誰在偷連我的 Windows?偵測外部存取軌跡的依據之一,這回補上子狀態的參考值:

狀態\子狀態碼描述
0XC000005E目前沒有可用於服務登入要求的登入伺服器
0xC0000064使用拼錯或錯誤的使用者帳戶登入的使用者
0xC000006A使用拼錯或錯誤密碼的使用者登入
0XC000006D原因可能是使用者名稱或驗證資訊錯誤
0XC000006E表示參照的使用者名稱和驗證資訊有效,但某些使用者帳戶限制 (驗證成功,例如一天中限制) 。
0xC000006F使用者于授權時間以外登入
0xC0000070使用者從未經授權的工作站登入
0xC0000071使用過期密碼登入的使用者
0xC0000072系統管理員停用的使用者登入帳戶
0XC00000DC表示 Server 的狀態不正確,無法執行所需的作業。
0XC0000133DC 與其他電腦之間的時鐘太不同步
0XC000015B使用者尚未獲得要求登入類型 (也稱為登入) 登入**
0XC000018C登入要求失敗,因為主網域與信任網域之間的信任關係失敗。
0XC0000192嘗試登入,但 Netlogon 服務尚未啟動。
0xC0000193使用過期帳戶登入的使用者
0XC0000224使用者必須于下次登入時變更密碼
0XC0000225明顯是錯誤Windows而非風險
0xC0000234帳戶鎖定的使用者登入
0XC00002EE失敗原因:登入期間發生錯誤
0XC0000413登入失敗:您登入的機器受到驗證防火牆的保護。 指定的帳號不允許向電腦進行驗證。
0x0狀態確定。

回到茶包上,為什麼在本機執行網站會在另一台留下操作者的登入失敗記錄?原本以為是去呼叫了該伺服器的 WebAPI 造成,但一則 WebAPI 只有某個特殊頁面會用到,不該在一啟動觸發登入失敗,二來檢查過該 WebAPI 有啟用匿名存取,不應有登入動作。進一步追查,發現原因出在因為連線字串設定問題,網站的 SQL 誤指向該主機,在 1433 Port 不通的情況下,SQL 客戶端預設會改嘗試 Named Pipe,而連線 Named Pipe 的過程嘗試使用本機登入帳號登入遠端伺服器,因帳號不存在登入失敗,因而留下登入失敗記錄。

SQL Client 可設定使用哪些協定以及協定順序,以我的本機為例,ProtocolsSupported 啟用了 Shared Memory(sm)、TCP(tcp)、Named Pipe(np) 三種協定,順序為 sm、tcp、np:

Shared Memory 只適用本機,故連線遠端 SQL 時,SQL Client 依序試連 TCP,若不成功則改試 Named Pipe ( When the client computer tries to make a TCP connection to the server and the connection attempt returns a non-zero return code, the client transparently tries a connection by using the next protocol in the list, which is Named Pipes. In this scenario, the client cannot make a TCP connection; however, the client successfully makes a Named Pipes connection. 參考)。

使用 Wireshark 觀察,可以證實此一行為。我從 192.168.43.38 使用以下 PowerShell 試連 192.168.43.32 (沒裝 SQL Server 的一般機器):

$cs = "data source=192.168.43.32"
$cn = New-Object System.Data.SqlClient.SqlConnection($cs)
$cn.Open()

因 192.168.43.32 未安裝 SQL,可以看到 192.168.43.38 先試連 1433 Port 無回應,1.88s 後改連 445 Port 成功,透過 SMB2 嘗試以當時的登入帳號登入,得到 STATUS_LOGON_FAILURE,就是 4625 事件的由來:

在大部分的情況下,這屬於無效且無害的嘗試,且只有在連錯主機、網路異常或 SQL 故障的例外狀況才會發生,機率不高理應可忽略,但若不想稽核失敗事件造成困擾,有一些做法可以避免。例如,停用 Named Pipe 協定,或是連線字串寫成 data source=xxx.xxx.xxx.xxx,1433 即可限定只用 TCP 協定,實測如下:

Case of 4625 audit failure security events caused by failed 1433 TCP SQL connection.


Comments

Be the first to post a comment

Post a comment


21 + 4 =