0

調查了一起開發測試過程引發 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