Syslog在網絡管理中的應用
摘要
Syslog是一種工業標準的協議，可用來記錄設備的日誌。在UNIX系統，路由器、交換機等網絡設備中，系統日誌（System Log）記錄系統中任何時間發生的大小事件。管理者可以通過查看系統記錄，隨時掌握系統狀況。UNIX的系統日誌是通過syslogd這個進程記錄系統有 關事件記錄，也可以記錄應用程序運作事件。通過適當的配置，我們還可以實現運行syslog協議的機器間通信，通過分析這些網絡行爲日誌，藉以追蹤掌握與 設備和網絡有關的狀況。
關鍵詞：Syslog，Syslogd，Priority（PRI），Facility，Severity，Header，Message（MSG），Timestamp。
1．引言
電信運營商的網絡龐大而複雜，其上運行着多種網絡設備、主機系統以及業務應用。而且隨着電信業的不斷髮展，各種新業務的推出，不同的系統紛紛建立，網絡的 複雜性不斷增長，使得被管理的對象在系統中不是集中的而是分散的。分佈式的管理必然要求網絡管理員在網絡的協議層次結構上對系統管理做出重新的認識，通過 適當的策略實現集中式管理，實現事件的實時監控和快速響應的網絡管理。傳統的網絡管理員關心的問題不單是安裝配置、備份恢復、系統安全、性能優化等，還必
須從OSI模型不同的層次重新考慮系統管理的內容和形式，再加上承載業務的特點，側重於事件監控和響應的建設是當今網絡管理的主要方向。
2．網絡管理的原則和要求
從技術的角度來說，網絡管理有兩條原則：1、由於管理信息而帶來的通行量不應明顯的增加網絡的通信量。2、被管理設備上的協議代理不應明顯得增加系統處理 的額外開銷，以致於該設備的主要功能都被削弱。網絡管理的對象主要是構成網絡的硬件和軟件應用所組成。這一類包括工作站、服務器、網卡、路由器、網橋和集 線器等等。通常情況下這些設備都分散在不同的地方，另外由於設備衆多，要做到實時實地管理需要大量的人力和物力。有什麼辦法可以對網絡設備進行遠程管理和
狀態進行預警呢？
3．集中式網絡管理的實現
實際工作中，由於管理員不可能7×24小時監視着網絡設備，網絡運行中可能會發生很多突發情況。因此，使用日誌記錄設備的報警信息十分重要，管理員可以借 此對安全事件進行原因追查和故障排除等工作。以路由器爲例，一般都會設定內存保留Syslog。但路由器的內存（Buffer）容量有限，大量事件發生 時，會覆蓋之前的記錄，不利於實時預警和報告。而對UNIX系統來說，由於管理設備的多樣性和數量的緣故，一臺臺登錄訪問日誌效率低下也不現實。所以有必
要建立專門的日誌服務器，通過Syslog服務，接收設備發送出的報警信息。
4．Syslog在網絡管理中的應用
4.1. Syslog Protocol簡介
Syslog是一種工業標準的協議，可用來記錄設備的日誌。在UNIX系統，路由器、交換機等網絡設備中，系統日誌（System Log）記錄系統中任何時間發生的大小事件。管理者可以通過查看系統記錄，隨時掌握系統狀況。在UNIX系統裏，被syslog協議接受的事件可以被記錄 到不同的文件，還可以通過網絡實現運行syslog協議的機器之間的信息傳遞。
Syslog已被許多日誌函數採納，它用在許多保護措施中——任何行爲都可以通過syslog 記錄事件。通過System Call，記錄用戶自行開發的應用程序的運行狀況。日誌系統的重點之一便是要研究及開發一些系統程序，例如logger等，將網絡應用程序重要的行爲向syslog接口呼叫並記錄爲日誌，大部分內部系統工具如郵件和打印系統都是如此生成信息的，許多新增的程序如Tcpwrappers和SSH也是如此工 作的。通過syslogd（負責大部分系統事件的daemon），系統事件可以寫到一個文件或設備中，或給用戶發送一個信息。它能記錄本地事件或通過網絡
記錄遠端設備上的事件。
圖1 Syslogd運作圖
4.2. Syslog在網絡管理方面應用
Syslog協議提供了一個傳遞方式，允許一個設備通過網絡把事件信息傳遞給事件信息接受者(也稱之爲日誌服務器)。由於每個進程、應用程序和操作系統都 或多或少地被獨立完成，在syslog信息內容會有一些不一致的地方。因此，協議中並沒有任何關於信息的格式或內容的假設。這個協議就是簡單地被設計用來 傳送事件信息，但是事件已經被接受到不會被通知。Syslog協議和進程最基本原則就是簡單，在協議的發送者和接受者之間不要求有嚴格的相互協調。事實
上， syslog信息的傳遞可以在接受器沒有被配置甚至沒有接受器的情況下開始。反過來，在沒有被清晰配置或者定義的情況下，接收器也可以接收到信息。
幾乎所有的網絡設備都可以通過syslog protocol將日誌信息以UDP方式傳送到遠端服務器，遠端接收日誌服務器必須通過syslogd來監聽UDP Port 514，並且根據syslog.conf中的配置來處理本機和接收訪問系統的日誌信息，把指定的事件寫入特定檔案中，供後臺數據庫管理和響應之用。也就是 說可以讓任何所產生的事件都登錄到一臺或多臺服務器上，以便後臺數據庫可以相對遠端設備以Off-line的方法分析事件。
圖2日誌分析系統架構圖
4.3. Syslog的格式說明
設備必須通過一些規則來配置，以便顯示或者傳遞事件信息。不管管理員決定怎樣配置對事件信息的處理，把這些信息發送到syslog接受者的過程一般都由下面部分構成：決定哪個幫助信息要被髮送，要被髮送的級別，定義遠程的接受者。
被傳輸的syslog信息的格式主要有3個容易識別出來的部分，分別是PRI、HEADER、MSG。數據包的長度小於1024個 字節。PRI部分必須有3、4、5個字符，以“<”開頭，然後是一個數字，並以“>”結尾。在方括號內的數字被稱爲優先級 （Priority），由facility和severity兩個值構成。信息中的facilities和severities通過十進制值進行數字的編
碼。一些操作系統的後臺監控程序和進程被分配一個facility值，那些沒有分配一個facility值的進程和daemons將會使用“local use”的facilities值或者“用戶級別”的facilities值。下面的表格表示被指定的Facilities值和對應的數字代碼。
Numerical Code Facility
0 kernelmessages
1 user-levelmessages
2 mail system
3 system daemons
4 security/authorization messages
5 messages generatedinternally by syslogd
6 line printersubsystem
7 network newssubsystem
8 UUCP subsystem
9 clock daemon
10 security/authorization messages
11 FTP daemon
12 NTP subsystem
13 log audit
14 log alert
15 clock daemon
16 local use0 (local0)
17 local use1 (local1)
18 local use2 (local2)
19 local use3 (local3)
20 local use4 (local4)
21 local use5 (local5)
22 local use6 (local6)
23 local use7 (local7)
表1 Syslog Message Facilities
每個信息優先級也有一個表示十進制Severity登記的參數, 下面的表格描述出他們和對應數值。
Numerical Code Severity
0 Emergency
1 Alert
2 Critical
3 Error
4 Warning
5 Notice
6 Informational
7 Debug
表 2 SyslogMessage Severities
Priority（優先級） = facility * 8+ severity值。比如說，一個核心信息（facility=0）和一個Emergency的severity將會產生優先級爲0。同樣， 一個“local use 4”信息（facility=20）和一個Notice的severity（severity=5）將會產生165的優先級。
標題（HEADER）部分由稱爲TIMESTAMP和HOSTNAME的兩個域組成，PRI結尾的“>”會馬上跟着一個 TIMESTAMP，任何一個TIMESTAMP或者HOSTNAME域後面都必須跟着一個空格字符。HOSTNAME包含主機的名稱，若無主機名或無法 識別則顯示IP地址。如果一個主機有多個IP地址，它通常會使用它傳送信息的那個IP地址。TIMESTAMP是本機時間，採用的格式是“Mmm
dd hh:mm:ss”表示月日時分秒。HOSTNAME域僅僅能夠包括主機名稱，Ipv4地址或者是信息產生者的Ipv6地址。
MSG部分是Syslog數據包剩下的部分。這通常包含了產生信息進程的額外信息，以及信息的文本部分。MSG部分有兩個域，分別爲TAG域和 CONTENT域，TAG域的值是產生信息的程序或者進程的名稱，CONTENT包含了這個信息的詳細內容。傳統上來說，這個域的格式較爲自由，並且給出 一些時間的具體信息。TAG是一個不許超過32個字符的字母數字字符串，任何一個非字母數字字符都將會終止TAG域，並且被假設是CONTENT域的開
始。在大多數情況下，表示TAG結束的CONTENT域的第一個字符用左大括號( [ ],分號( : )或者是空格來表示。
4.3. Syslog的發送和接收
接受端服務器收到發送給它的syslog數據包，它將檢查它的有效PRI。如果第一次字符不是一個“<”，或者第三、第四或者第五不是一個“>”，接收端將認爲數據包沒有包含有效的PRI。接着檢查在標題部分的有效TIMESTAMP，從這些規則中，信息的接收一般有三個情況，下面給 出了這三個情況的通常屬性，並列舉了隨後在這篇中什麼地方會描寫這些情況。
有效的PRI and TIMESTAMP：在數據包中發現一個有效的PRI和TIMESTAMP，那麼會接着檢查數據包的內部配置，接收端必須根據數據包的優先級來還原，或者 在不對數據包做任何變化的情況下將它轉發出去。這裏要注意到的是接受端沒有必要確認TIMSTIMP裏面的時間，同時接收端也沒有必要確認 HOSTANME的值和發送信息設備的主機名或者IP地址一致。
有效的 PRI，但沒有TIMESTAMP 或者TIMESTAMP無效：要是在數據包中發現一個有效的TIMESTAMP，那麼必須馬上添加一個TIMESTAMP和一個空格字符在PRI部分的結 尾的方括號內，它還必須添加一個HOSTNAME和空格字符在TIMESTAMP後面，接收到的信息包剩下的部分必須被當曾MSG的CONTENT域並附 加上，由於無法識別產生信息的設備所發出的進程，TAG的值無法被識別出來，
所以不會包含再裏面。TIMESTAMP將會是接收端的本地時間，HOSTNAME是設備的名稱，它被中繼器所識別。如果名字如能被決定, 設備的IP地址將被使用到。要是中繼器添加一個TIMESTAMP(或者同時添加TIMESTAMP和HOSTNAME)在PRI後面, 然後檢 查是否數據包的總體長度仍然小於或等於1024個字節。如果數據包被擴展超過1024個比特, 中繼器必須截去一部分數據包數據使它到達到1024比特。這將會導致原始數據包結尾部分重要信息的丟失. 所以，這就是產生的syslog數據包的PRI和HEADER部分包含在4.3節所記錄的值和域之中的緣故。
沒有 PRI or 或者 PRI無法識別：如果收不到PRI或者PRI不可識別，除了必須插入一個優先級爲13的PRI和我們在上面描述的TIMESTAMP，還必須插入一個 HOSTNAME。被接收到的數據包的全部內容將被認爲是被傳遞的MSG的CONTENT並被添加在後面。一個不可識別的PRI的例子就是“< 00>”，這也許是一個信息的前4個字符。如果接收到這樣的syslog信息，那麼它的優先級將被中繼器或收集者改爲13，並且加入
TIMESTAMP。具體如下：
原來接收到的信息
<00>...
被傳遞或識別的信息
<13>TIMESTAMPHOSTNAME <00>...
如果中繼器添加一個TIMESTAMP(或者同時添加一個TIMESTAMP和HOSTNAME)在PRI後面, 那麼它將檢查這個數據包的總體長度是否等於或者小於1024個比特。
在UNIX文件系統裏頭，syslog設備依據兩個重要的文件：syslogd（守護進程）和syslog.conf配置文件。習慣上，多數syslog 信息被寫到/var/adm或/var/log目錄下的信息文件中（syslog或messages.*）。一個典型的syslog紀錄包括生成程序的名 字和一個文本信息。它還包括一個設備和一個優先級範圍（但不在日誌中出現）。Syslog.conf的格式比較複雜，大家可以參考一下有關書籍（或者在主 機上man syslog.conf），主要是如下語句形式： facility、level、action。Facility代表各種服務，level代表syslog的認證級別，action代表的是針對前面信息
的處理動作。Action字段如果是@loghos（主機名或具體IP），則把信息發送到loghost，而不是本地的 /var/adm/messages。
4.4. 配置實例
4.4.1 UNIX à UNIX服務器
接收端設置：
我們採用一臺Sun服務器作爲日誌接收服務器（Hostname：nmtest1-yd，IP爲192.168.3.71）。一般情況下，UNIX系統的 本地系統日誌都存放在/var卷下（Solaris系統默認存放在/var/adm/messages），當然我們也可以更改存放路徑。根據需求，配置 syslogd.conf文件，重啓syslogd應用。監控應用多的話，message可能會增大很多，可以做一些簡單的分類即可。
# vi /etc/syslogd.conf
kern.crit /dev/console *把kern.crit、kern.alert及kern.emerg相關信息送到系統consle
authpriv.*/var/log/securelog
mail.info;mail.!err/var/log/maillog *把mail信息priority大於等於info，但priority爲error除外的信息記錄
發送端設置：（一臺Sun服務器，IP爲192.168.3.72）
指定好loghost，讓後編輯/etc/syslog.conf，將原先的設定
*.info;mail.none;authpriv.none;cron.none[Tab]/var/log/messages
改成：
*.err;kern.debug;daemon.notice;mail.crit[Tab]/var/log/[email protected]
保存後退出，在兩臺服務器上重啓syslogd進程。在接收端和發送端上通過snoop監聽514端口狀況。可以發現有包進出。在nmtest1-yd上查看/var/log/syslog，可以發現：
Nov 23 18:17:25[192.168.3.72.159.195] sendmail[17259]: unable to qualify my own domain name(nmtest2-yd) -- using short name
Nov 23 18:17:25[192.168.3.72.159.195] sendmail[17895]: My unqualified host name (nmtest2-yd)unknown; sleeping for retry
Nov 23 18:17:25[192.168.3.72.159.195] last message repeated 1 time
4.4.2 路由器à UNIX服務器
接收端設置：
我們採用一臺Sun服務器作爲日誌接收服務器（Hostname：nmtest1-yd，IP爲192.168.3.71），配置syslog.conf文件。
local0.info[Tab]/var/log/hw.log
保存退出，並生成hw.log空文件，touch /var/log/hw.log。
發送端設置：
router1# conf
router1(config)#logging on
router1(config)#loggin192.168.3.71
router1(config)#loggingfacility local0
router1(config)#loggingtrap info
router1(config)#loggingtimestamps log datetime localtime
在nmtest1-yd上查看/var/log/hw.log，可以發現：
Nov 18:17:25:%LINK-3-UPDOWN: Interface POS2/0/0, changed state to up
Nov 18:17:25:%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/0, changed stateto up
Nov 18:17:25:%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet3/1, changed stateto up
Nov 18:17:25:%LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0/0, changed state toup
5. 結束語
結合syslog進行集中式網絡管理，應先了解系統日誌運作原理，並且能夠依照本身需求，靈活運用日誌系統，打造一個適合自身的記錄環境。這種方法也存在 不足之處，由於syslog是以UDP方式傳送，個別的日誌消息可能會遺失；在網絡設備崩潰的情況下，可能不會將最有用的信息發送到syslog服務器 上，這對於排除崩潰故障不是很有用；而且syslog日誌服務器容易成爲攻擊者的目標，對於防範系統方面的攻擊比較脆弱，需要特別注意。