SQL Server | 是誰在敲打我窗使用 IIS Logs 分析 SQL Server 連線的來源

筆記如何從 SQL Server 登入失敗的錯誤紀錄，回推查詢 Web Server 從而找到連線的來源所在。

說明

故事的開始是一個倒敘法，會先收到從 IIS Server 使用特定 SQL Account 去連線 SQL Server Database Server 的錯誤訊息。三個角色都非常關鍵，我們可以確定來源 IIS Server 的 IP，再從該 IIS Server 去查詢。

而一般而言實際上發動連線的並不是 IIS Server，它只是服務 ASP.NET、Java 等後端語言，負責去與資料庫進行連線。而連線的觸發實際上是因為 IIS Server 特定的網站被要求連線所導致的，因此我們可以在往是那一個來自該 IIS Server 那一個網站去做查詢。

這邊可以分從兩個方向進行處理：

（一）從應用程式的連線字串、程式碼原始檔搜尋 SQL Account 關鍵字

Get-ChildItem -Recurse *.asp | Select-String "apuser" -list | select path

如果連線字串有加密或者程式碼是編譯過會讓這個步驟的查詢難度變得相當複雜，而如果幸運的話，可以找到特定的檔案名稱，基本上破案的曙光已經出現了，接著可以在使用 IIS Logs 去尋找更多資訊。

（二）從 IIS Logs 搜尋 SQL Account 關鍵字

Get-Content .\*.log | Select-String "login.asp"

如果在上一個步驟不順利，也可以考慮直接 IIS Logs 尋找，但如果沒有特定的檔案名稱，搜尋起來會較為複雜，需要更多的交叉比對以找到真正的連線 User。

從 IIS Logs 能夠得到真正的連線 User，這一點能夠讓整個查詢脈絡更為豐富。