【茶包射手日記】SQL Client 與 Windows 4625 登入失敗稽核事件
0 |
調查了一起開發測試過程引發 Windows 稽核失敗事件的案例。
本機不小心在 Visual Studio 啟動了某個測試網站專案,在另一個伺服器留下多筆操作登入使用者登入失敗的 Windows 安全事件:
依據微軟文件,4625 事件用於記錄任何登入失敗,留存在嘗試登入的電腦上。這個事件也是之前我在實用小工具 - 查誰在偷連我的 Windows?偵測外部存取軌跡的依據之一,這回補上子狀態的參考值:
狀態\子狀態碼 | 描述 |
---|---|
0XC000005E | 目前沒有可用於服務登入要求的登入伺服器 |
0xC0000064 | 使用拼錯或錯誤的使用者帳戶登入的使用者 |
0xC000006A | 使用拼錯或錯誤密碼的使用者登入 |
0XC000006D | 原因可能是使用者名稱或驗證資訊錯誤 |
0XC000006E | 表示參照的使用者名稱和驗證資訊有效,但某些使用者帳戶限制 (驗證成功,例如一天中限制) 。 |
0xC000006F | 使用者于授權時間以外登入 |
0xC0000070 | 使用者從未經授權的工作站登入 |
0xC0000071 | 使用過期密碼登入的使用者 |
0xC0000072 | 系統管理員停用的使用者登入帳戶 |
0XC00000DC | 表示 Server 的狀態不正確,無法執行所需的作業。 |
0XC0000133 | DC 與其他電腦之間的時鐘太不同步 |
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