Syslog là gì?

Syslog là gì?

 

 

Nội dung bài viêt: 

[external_link_head]

1. Syslog là gì?

2. Định dạng thông báo Syslog

3. Ví dụ về thông báo Syslog

4. Syslog Server

5. Bảo mật

6. Thiết kế Syslog

7. Sử dụng Syslog

 

 

1. Syslog là gì?

– Syslog là viết tắt của System Logging Protocol (tạm dịch sang tiếng Việt là Giao thức ghi nhật ký hệ thống) và là một giao thức tiêu chuẩn được sử dụng để gửi nhật ký hệ thống hoặc thông báo sự kiện đến một máy chủ cụ thể, máy chủ này được gọi là máy chủ nhật ký hệ thống “Syslog server”. Nó chủ yếu được sử dụng để thu thập các bản ghi nhật ký thiết bị “device logs” khác nhau từ một số máy khác nhau ở một vị trí trung tâm để theo dõi và xem xét.

 

– Giao thức System Logging Protocol được kích hoạt trên hầu hết các thiết bị mạng như bộ định tuyến “router”, bộ chuyển mạch “switch”, tường lửa “firewall” và thậm chí một số máy in “printer” và máy quét “scanner”. Ngoài ra, Syslog có sẵn trên các hệ thống dựa trên Unix và Linux và nhiều máy chủ web bao gồm cả Apache. Syslog không được cài đặt theo mặc định trên các hệ thống Windows sử dụng Windows Event Log của riêng chúng. Các sự kiện này có thể được chuyển tiếp thông qua các tiện ích của bên thứ ba hoặc các cấu hình khác bằng giao thức nhật ký hệ thống Syslog protocol.

 

– Syslog được định nghĩa trong RFC 5424, Giao thức Syslog, so với RFC 3164 trước đó.

 

– Syslog components (Syslog của các thiết bị thành phần mạng)

• Trên bất kỳ thiết bị nhất định nào, các sự kiện khác nhau được hệ thống tạo ra để đáp ứng với các điều kiện thay đổi. Những sự kiện này thường được ghi lại cục bộ nơi chúng có thể được xem xét và phân tích bởi quản trị viên. Tuy nhiên, việc theo dõi nhiều bản ghi “logs” trên một số lượng tương ứng của các bộ định tuyến, thiết bị chuyển mạch và hệ thống sẽ tốn thời gian và không thực tế. Syslog giúp giải quyết vấn đề này bằng cách chuyển tiếp các sự kiện đó đến một máy chủ tập trung.

 

– Syslog transmission (Truyền gửi Syslog)

[external_link offset=1]

• Theo truyền thống, Syslog sử dụng giao thức UDP trên cổng Port 514 nhưng có thể được cấu hình để sử dụng bất kỳ cổng nào. Ngoài ra, một số thiết bị sẽ sử dụng TCP 1468 để gửi dữ liệu Syslog data để nhận được thông báo gửi được xác nhận.

• Việc truyền các gói tin Syslog packet là không đồng bộ. Nguyên nhân của việc này là thông báo Syslog message được tạo ra và được định cấu hình trong chính bộ định tuyến, bộ chuyển mạch hoặc máy chủ. Không giống như các giao thức giám sát khác, chẳng hạn như SNMP, không có cơ chế để thăm dò dữ liệu Syslog data. Trong một số triển khai, SNMP có thể được sử dụng để đặt “set” hoặc sửa đổi “modify” các thông số “Parameters” của Syslog từ xa.

2. Định dạng thông báo Syslog

– Thông báo của giao thức Syslog bao gồm 3 phần: PRI (giá trị ưu tiên được tính toán), HEADER (với thông tin nhận dạng), và MSG (thông báo chính).

 

– Dữ liệu PRI được gửi qua giao thức nhật ký hệ thống “Syslog Protocol” đến từ hai giá trị số giúp phân loại thông báo. Đầu tiên là giá trị Facility value. Giá trị này là một trong 15 giá trị được xác định trước hoặc các giá trị được xác định cục bộ khác nhau trong trường hợp từ 16 đến 23. Các giá trị này phân loại loại thông báo hoặc hệ thống nào đã tạo ra sự kiện.

Number	Facility description
0	Kernel messages
1	User-level messages
2	Mail System
3	System Daemons
4	Security/Authorization Messages
5	Messages generated by syslogd
6	Line Printer Subsystem
7	Network News Subsystem
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 – 23	Local Use 0 – 7

– Nhãn hay giá trị thứ hai của thông báo Syslog message nhằm phân loại tầm quan trọng hoặc mức độ nghiêm trọng của thông báo bằng mã số từ 0 đến 7.

 

Code	Severity	Description
0	Emergency	System is unusable
1	Alert	Action must be taken immediately
2	Critical	Critical conditions
3	Error	Error conditions
4	Warning	Warning conditions
5	Notice	Normal but significant condition
6	Informational	Informational messages
7	Debug	Debug-level messages

– Giá trị của cả hai nhãn không có định nghĩa cố định. Do đó, tùy thuộc vào hệ thống hoặc ứng dụng để xác định cách ghi lại một sự kiện (ví dụ: dưới dạng cảnh báo “warning”, thông báo “notice” hoặc thứ gì khác) và trên cơ sở nào. Trong cùng một ứng dụng hoặc dịch vụ, các con số thấp hơn sẽ tương ứng với các vấn đề nghiêm trọng hơn liên quan đến quy trình cụ thể.

 

– Hai giá trị này được kết hợp để tạo ra Giá trị ưu tiên PRI “PRI – Priority Value” được gửi cùng với thông báo. Giá trị Ưu tiên PRI được tính bằng cách nhân giá trị Facility value với tám và sau đó cộng Giá trị Mức độ nghiêm trọng “Severity Value” vào kết quả. PRI càng thấp thì mức độ ưu tiên càng cao.

               (Facility Value * 8) + Severity Value = PRI

 

– Bằng cách này, một thông báo Kernel message nhận được giá trị thấp hơn (ưu tiên cao hơn) so với một cảnh báo nhật ký “Log alert”, bất kể mức độ nghiêm trọng của cảnh báo nhật ký. Các số nhận dạng bổ sung trong gói bao gồm tên máy chủ “hostname”, địa chỉ IP “IP address”, ID tiến trình “Process ID”, tên ứng dụng “App name” và dấu thời gian “timestamp” của thông báo. Xung quanh thực tế hoặc nội dung của thông báo nhật ký hệ thống không được xác định bởi giao thức. Một số thông báo là văn bản đơn giản, có thể đọc được, những thông báo khác chỉ có thể đọc được bằng máy.

 

– Thông báo Syslog Messages thường không dài hơn 1024 byte.

 

 

3. Ví dụ về thông báo Syslog

<165>0877074074T21:14:15.003Z mymachine.example.com appname[su] – ID47 [bem2vnn@gmail.com iut=”3″ eventSource=” eventID=”1011″] BOMAn application log entry…

 

– Các phần của thông báo Syslog Messages

Part	Value	Information
PRI	165	Facility = 20, Severity = 5
VERSION	1	Version 1
TIMESTAMP	0877074074T21:14:15.003Z	Message created on 11 May 2017 at 09:14:15 pm, 3 milliseconds into the next second
HOSTNAME	mymachine.example.com	Message originated from host “mymachine.example.com”
APP-NAME	su	App-Name: “su”
PROCID	–	PROCID unknown
MSGID	ID47	Message-ID: 47
STRUCTURED-DATA	[bem2vnn@gmail.com iut=”3″ eventSource=” eventID=”1011″]	Structured Data Element with a non-IANA controlled SD-ID of type “bem2vnn@gmail.com”, which has three parameters
MSG	BOMAn application log entry…	BOM indicates UTF-8 encoding, the message itself is “An application log entry…”

4. Syslog Server

– Máy chủ nhật ký hệ thống “Syslog Server” còn được gọi là bộ thu nhật ký hệ thống “syslog collector” hoặc bộ nhận nhật ký hệ thống “syslog receiver”.

 

– Các thông báo nhật ký hệ thống “Syslog messages” được gửi từ thiết bị tạo đến bộ thu. Địa chỉ IP của Syslog Server đích phải được định cấu hình trên chính thiết bị, bằng dòng lệnh Command Line hoặc thông qua tệp conf. Sau khi được cấu hình, tất cả dữ liệu Syslog sẽ được gửi đến máy chủ đó. Không có cơ chế nào trong giao thức Syslog Protocol để một máy chủ khác yêu cầu dữ liệu nhật ký hệ thống.

 

– Trong khi hầu hết các triển khai Unix và các nhà cung cấp mạng, như Cisco, có bộ thu thập Syslog collectors, của riêng họ, thì cũng có một số công cụ khác.

 

– Phần mềm giám sát PRTG của Paessler cung cấp cảm biến nhận Syslog Receiver Sensor được tích hợp sẵn.  Cảm biến này thu thập tất cả các thông báo Syslog Messages được gửi. Để sử dụng chức năng này, quản trị viên cần thêm Bộ thu Syslog Receiver và sau đó định cấu hình địa chỉ IP của máy chủ đó làm máy chủ đích cho dữ liệu nhật ký hệ thống trên tất cả các thiết bị cần giám sát.

 

– Sau khi tập hợp, bảng điều khiển hiển thị:

• Số lượng thông báo nhật ký hệ thống Syslog messages nhận được mỗi giây.
• Số lượng thông báo được phân loại là cảnh báo “Warning” mỗi giây.
• Số lượng thông báo được phân loại là lỗi “Error” trên giây.
• Số lượng gói tin bị rớt “dropped messages” mỗi giây.

 

– Giao thức nhật ký hệ thống Syslog Protocol có thể tạo ra rất nhiều thông báo. Syslog chỉ đơn giản là chuyển tiếp các thông báo nhanh nhất khi nó tạo ra chúng. Do đó, khả năng quan trọng nhất đối với máy chủ nhật ký hệ thống Syslog Server là khả năng lọc và phản ứng đúng cách với dữ liệu nhật ký hệ thống đến.

 

– Bộ cảm biến nhận “PRTG Syslog Receiver Sensor” cung cấp khả năng thiết lập các quy tắc lọc. Các quy tắc này cho phép các thông báo nhật ký hệ thống được bao gồm hoặc loại trừ dưới dạng cảnh báo “Warning” hoặc lỗi “Error”, bất kể chúng được tạo ban đầu như thế nào trên thiết bị. Bộ lọc này đảm bảo rằng quản trị viên nhận được thông báo về tất cả các lỗi mà họ muốn biết mà không bị choáng ngợp bởi các lỗi ít quan trọng hơn.

5. Bảo mật

[external_link offset=2]

– Giao thức nhật ký hệ thống Syslog Protocol không cung cấp cơ chế bảo mật. Không có xác thực “authentication” được tích hợp sẵn để đảm bảo rằng các tin nhắn đến từ thiết bị được xác nhận là đang gửi chúng. Không có mã hóa nào để che giấu thông tin nào đang được gửi đến máy chủ. Nó đặc biệt dễ bị ảnh hưởng bởi cái gọi là các cuộc tấn công phát lại “Playback Attacks” trong đó kẻ tấn công tạo ra một luồng cảnh báo trước đó để phản hồi bất hợp pháp.

 

6. Thiết kế Syslog

– Cấu hình thiết bị (Device configuration)

• Hầu hết các triển khai Syslog đều có thể định cấu hình đối với cơ sở nào và số mức độ nghiêm trọng nào sẽ tạo ra các sự kiện nhật ký hệ thống được chuyển tiếp đến máy chủ nhật ký hệ thống Syslog Server. Điều quan trọng là phải định cấu hình đúng cách để tránh làm ngập máy chủ (và mạng) với lưu lượng không cần thiết. Ví dụ: Gỡ lỗi không bao giờ được đặt để gửi tin nhắn trừ khi đang thử nghiệm.

• Nên đặt các thông số Syslog để yêu cầu Facility value và mức độ nghiêm trọng Severity cao nhất có thể (được đánh số thấp nhất) để giảm thiểu lưu lượng truy cập. Mặc dù lỗi bộ định tuyến có thể chỉ ra rằng giao diện bị trục trặc và do đó chắc chắn cần được báo cáo, một máy in mạng ít quan trọng hơn có thể được định cấu hình để chỉ tạo lưu lượng nhật ký hệ thống cho các sự kiện quan trọng.

• – Windows

• Hệ thống Windows không triển khai Syslog trong hệ thống Nhật ký sự kiện tiêu chuẩn – Event Log system. Các sự kiện được tạo trong hệ thống ghi nhật ký Windows có thể được thu thập và chuyển tiếp đến máy chủ nhật ký hệ thống Syslog Server bằng cách sử dụng các tiện ích của bên thứ ba. Các tiện ích này giám sát Nhật ký sự kiện “Event Log”, sử dụng thông tin để tạo sự kiện được định dạng nhật ký hệ thống Syslog và chuyển tiếp các sự kiện bằng giao thức nhật ký hệ thống Syslog Protocol tiêu chuẩn.

 

– Các hạn chế của giao thức nhật ký hệ thống Syslog Protocol

• Một hạn chế chính của giao thức nhật ký hệ thống Syslog Protocol là thiết bị đang theo dõi phải được thiết lập và chạy và được kết nối với mạng để tạo và gửi sự kiện nhật ký hệ thống “Syslog Event”. Một lỗi nghiêm trọng từ Kernel Facility có thể không bao giờ gửi lỗi khi hệ thống ngoại tuyến “off-line”. Nói cách khác, Syslog không phải là một cách tốt để theo dõi trạng thái lên “Up” và xuống “Down” của các thiết bị.

7. Sử dụng Syslog

– Mặc dù Syslog không phải là một cách tốt để theo dõi trạng thái của các thiết bị được nối mạng, nhưng nó có thể là một cách tốt để theo dõi tình trạng tổng thể của thiết bị mạng. Mặc dù phần mềm giám sát mạng như PRTG cung cấp một bộ tiện ích để theo dõi qua mạng, nhưng không có gì nói với quản trị viên rằng có sự cố nhanh hơn nhật ký sự kiện đầy cảnh báo. Giám sát nhật ký hệ thống được định cấu hình thích hợp sẽ phát hiện sự gia tăng đột ngột về khối lượng và mức độ nghiêm trọng của sự kiện, có thể cung cấp thông báo trước khi sự cố người dùng có thể phát hiện xảy ra.

 

– Bảo mật / ủy quyền / kiểm soát tuân thủ

• Mạng công ty trung bình chứa nhiều thiết bị mà không ai nên cố gắng truy cập vào một ngày trung bình. Nếu một bộ chuyển mạch “Switch” từ xa chỉ được đăng nhập một lần trong mỗi chu kỳ kiểm tra đột nhiên có các nỗ lực đăng nhập hàng ngày (thành công hoặc theo cách khác), nó có nghĩa là đã đăng xuất. Trên các loại thiết bị này, nhật ký hệ thống có thể được thiết lập để chuyển tiếp các sự kiện xác thực tới máy chủ nhật ký hệ thống “Syslog Server” mà không cần phải cài đặt và định cấu hình tác nhân giám sát đầy đủ.

• Syslog cũng cung cấp một cách để đảm bảo rằng các sự kiện quan trọng được ghi lại và lưu trữ khỏi máy chủ gốc. Nỗ lực đầu tiên của kẻ tấn công sau khi xâm phạm hệ thống là che dấu vết để lại trong nhật ký. Các sự kiện được chuyển tiếp qua nhật ký hệ thống sẽ nằm ngoài tầm với.

 

– Giám sát ứng dụng

• Có rất nhiều cách để theo dõi cách một ứng dụng đang chạy trên máy chủ. Tuy nhiên, những màn hình đó có thể bỏ qua cách ứng dụng đang ảnh hưởng đến các tiến trình khác trên máy chủ. Mặc dù mức sử dụng CPU hoặc bộ nhớ cao đủ dễ dàng để phát hiện với các màn hình khác, các sự kiện được ghi lại có thể giúp hiển thị nhiều sự cố có thể xảy ra hơn. Một ứng dụng liên tục cố gắng truy cập vào một tệp đã bị khóa? Có cố gắng ghi cơ sở dữ liệu tạo ra lỗi không? Những sự kiện như thế này có thể không bị phát hiện khi gây ra bởi các ứng dụng xử lý tốt lỗi, nhưng chúng không nên bị bỏ qua. Syslog sẽ đảm bảo rằng những sự kiện đã ghi nhận được sự chú ý mà chúng xứng đáng được nhận.

 

– Syslog như một phần của giám sát mạng tổng thể

• Việc giám sát mạng hoàn chỉnh yêu cầu sử dụng nhiều công cụ. Syslog là một trụ cột quan trọng trong việc giám sát mạng vì nó đảm bảo rằng các sự kiện xảy ra mà không có tác động lớn sẽ không lọt qua các vết nứt. Cách tốt nhất là sử dụng một phần mềm kết hợp tất cả các công cụ để luôn có cái nhìn tổng quan về những gì đang xảy ra trong mạng.

[external_footer]