[工具介紹] 利用 rsyslog + mysql + loganalyzer 做好日誌管理 (上)

在上一篇的文章中，我提到 FIM 的建置可能是為了遵守法規的要求，而今天要分享的日誌管理 (Log Management, LM)，更是許多法規中不可或缺的規範。尤其是在這一兩年嗆到不行新版個資法當中，日誌管理更是佔了相當重要的地位。

舉凡硬體設備、作業系統到應用系統，運行過程當中總會產生許許多多的紀錄，而這些記錄不管目的為何，都可以統稱為日誌 (Log)。而日誌管理大致上可以分為日誌的產生與收集、日誌的保護與日誌的應用幾個項目，其中日誌的應用是最為弔詭也可能是最為困難的一個項目。弔詭之處在於如果是為了遵守法規而建置日誌管理的機制，那麼就可能失去了真正應用的價值。而困難的地方在於，如何從眾多收集而來的日誌當中找出有用的資訊，甚至發現隱藏在當中的(可能)問題。這部份的技術門檻相當高，通常是智慧型分析工具或者是 SIEM 的強項，光靠人工或是一般日誌管理工具 (尤其是免費的工具) 就顯得較為無力了。

前面提到日誌有許多不同的來源，而這些來源可能因為需要記錄不同的內容而有不同的格式，這些不同的格式造成了日誌管理的第一個難題。在眾多的格式中，syslog 算是相當重要也普遍受到支援的一種格式，原因在於 syslog 的格式相當簡單。因為我要介紹的工具就是以 syslog 當做日誌的格式，所以在介紹工具之前我先花點時間說明一下有關 syslog 的注意事項。

首先我們看一下在 Linux 下實際 syslog 日誌的內容為何 (取自 /var/log/message)：

Mar 28 04:16:21 www fail2ban.filter : INFO   Log rotation detected for /var/log/secure
Mar 28 04:18:33 www snmpd[1980]: Connection from UDP: [192.168.0.99]:32770

從例子中我們可以發現，即使是同屬 Linux 下的 syslog 訊息，也會有很大的差異。除了日期 (Mar 28 04:16:21) 與主機名稱 (www) 之外，後面的格式就開始出現不同之處了。第一行顯示了應用程式的名稱 (fail2ban.filter)，但是第二行除了應用程式的名稱 (snmpd) 之外還多了一組數字，而這組數字通常是代表程序的ID (Process ID, PID)。在此之後就是 syslog 訊息的主體 (message)，也就是一串任意組合的字串 (例如例子中的 INFO Log rotation detected for /var/log/secure)。這個幾乎沒有任何規範要求的字串，就是 syslog 簡單之所在，卻也是 syslog 應用上困難之所在。因為沒有規範，所以很難利用自動化的程式加以處理，尤其是面對多種不同來源的 syslog 時，問題將更加嚴重。除了日誌檔中可以看到的資訊，syslog 其實還定義了兩個很重要的屬性，那就是 facility 與 severity。簡單來說，facility 可以看成是分類，而 severity 則是表示訊息的重要程度。因為這兩個屬性的定義較為明確，也很容易判斷，所以很適合用來當做自動化判斷的依據。以早期 syslog 套件而言，都是利用這兩個屬性來決定相關訊息應該如何加以處理 (例如記錄到哪個日誌檔中)。嚴格來說，syslog 還定義了其他結構化的欄位用以表示其他資訊，但是因為並非強制性，所以很多實作就沒有提供相關的資訊了。而且這些結構化的資訊，還是不足以滿足所有系統的需求，所以造成了過多無結構化的資訊存放在訊息主體的現象。總的來說，syslog 解決了日誌格式混亂的問題，但是卻只解決了一部分。儘管如此，至少這是目前應用上較切合實際的方法。

syslog 除了支援本機的日誌，也支援透過網路來遞送日誌的內容。但是透過網路遞送日誌時有兩個問題需要特別注意，那就是 syslog 缺少對日誌來源的驗證，以及以明文方式傳送資訊。尤其是當使用預設的 UDP 方式傳送訊息時，這兩個問題將導致有心人士可以很容易地產生假冒或是竄改過的日誌內容。對此，IETF 另外訂定了簽章式的 syslog (RFC-5848 Signed Syslog Messages)，以防範這類問題的產生，有興趣的朋友還請自行參閱。

講了這麼多，先休息一下，有關工具的操作就留待下篇吧。