2.1.5.3. Get-bulk
“Get-bulk” đƣợc định nghĩa trong SNMPv2. Nó cho phép lấy thông tin quản trị từ nhiều phần trong bảng. Dùng “get” có thể làm đƣợc điều này. Tuy nhiên, kích thƣớc của câu hỏi có thể bị giới hạn bởi agent. Khi đó nếu nó không thể trả lời toàn bộ yêu cầu, nó gửi trả một thông báo lỗi mà không có dữ liệu. Với trƣờng hợp dùng câu lệnh “get-bulk”, agent sẽ gửi càng nhiều trả lời nếu nó có thể. Do đó, việc trả lời một phần của yêu cầu là có thể xảy ra:
Hình 2.10 – Minh họa quá trình thực hiện thông báo Get-Bulk
2.1.5.4. Set
Để thay đổi giá trị của một đối tƣợng hoặc thêm một hàng mới vào bảng. Đối tƣợng này cần phải đƣợc định nghĩa trong MIB là “read-write” hay “write-only”. NMS có thể dùng “set’ để đặt giá trị cho nhiều đối tƣợng cùng một lúc:
Hình 2.11 – Minh họa quá trình thực hiện thông báo Set
2.1.5.5. Error Response của “Get”, “Get-next”, “Get-bulk” và “Set”
SNMPv1 Error Message Ý nghĩa
noError(0) Không có lỗi
tooBig(1) Yêu cầu quá lớn để có thể dồn vào một câu trả lời
noSuchName(2) OID yêu cầu không tìm thấy, tức không tồn tại ở agent
badValue(3) Câu lệnh “set” dùng không đúng với các đối tƣợng
“read-write” hay “write-only”
readOnly(4) Lỗi này ít dùng.
Lỗi “noSuchName” tƣơng đƣơng với lỗi này
genErr(5) Dùng cho tất cả các lỗi còn lại, không nằm trong các
lỗi trên
Bảng 2.1 – Các loại lỗi thông báo SNMPv1
Các loại lỗi của SNMPv1 mang tính chất chung nhất, không rõ ràng. Do đó SNMPv2 đƣa ra thêm một số loại lỗi nhƣ sau:
SNMPv2 Error Message Ý nghĩa
noAccess(6) Lỗi khi lệnh “set” cố gắng xâm nhập vào một biến
cấm xâm nhập. Khi đó, biến đó có trƣờng “ACCESS” là “not-accessible”
wrongType(7)
Lỗi xảy ra khi lệnh “set” đặt một kiểu dữ liệu khác với kiểu định nghĩa sẵn của đối tƣợng. Ví dụ khi “set” đặt giá trị kiểu string cho một đối tƣợng kiểu số nguyên INTEGER
wrongLength(8) Lỗi khi lệnh “set” đƣa vào một giá trị có chiều dài lớn
hơn chiều dài tối đa của đối tƣợng
WrongEncoding(9) Lỗi khi lệnh “set” sử dụng cách mã hóa khác với cách
đối tƣợng đã định nghĩa wrongValue(10)
Một biến đƣợc đặt một giá trị mà nó không hiểu. Khi một biến theo kiểu liệt kê “enumeration” đƣợc đặt một giá trị không theo kiểu liệt kê
noCreation(11) Lỗi khi cố đặt một giá trị cho một biến không tồn tại
inconsistentValue(12) Một biến MIB ở trạng thái không nhất quán, và nó không chấp nhận bất cứ câu lệnh “set” nào
resourceUnavailable(13) Không có tài nguyên hệ thống để thực hiện lệnh “set”
commitFailed(14) Đại diện cho tất cả các lỗi khi lệnh “set” thất bại undoFailed(15)
Một lệnh “set” không thành công và agent không thể phục hồi lại trạng thái trƣớc khi lệnh “set” bắt đầu thất bại
authorizationError(16) Một lệnh SNMP không đƣợc xác thực, khi một ngƣời nào đó đƣa ra mật mã không đúng
notWritable(17) Một biến không chấp nhận lệnh “set”
inconsistentName(18) Cố gắng đặt một giá trị, nhƣng việc cố gắng thất bại vì biến đó đang ở tình trạng không nhất quán
Bảng 2.2 – Các loại lỗi thông báo SNMPv2
2.1.5.6. SNMP Traps
Trap là cảnh báo của agent tự động gửi cho NMS để NMS biết có tình trạng xấu ở agent
Hình 2.12 – Minh họa quá trình thực hiện thông báo Trap
Khi nhận đƣợc một “trap” từ agent, NMS không trả lời lại bằng “ACK”. Do đó agent không thể nào biết đƣợc là lời cảnh báo của nó có tới đƣợc NMS hay không. Khi nhận đƣợc một “trap” từ agent, nó tìm xem “trap number” để hiểu ý nghĩa của “trap” đó:
Tên kiểu trap & Số hiệu Ý nghĩa
coldStart (0)
Thông báo agent vừa khởi động lại. Tất cả các biến quản trị sẽ đƣợc reset, các biến kiểu “Counters” và “Gauges” đƣợc đặt về 0.
“coldStart” dùng để xác định một thiết bị mới gia nhập vào mạng. Khi một thiết bị khởi động xong, nó gửi một “trap” tới NMS. Nếu địa chỉ NMS là đúng, NMS có thể nhận đƣợc và xác định xem có quản trị thiết bị đó hay không.
warmStart (1) Thông báo agent vừa khởi tạo lại, không có
biến nào bị reset.
linkDown (2)
Thông báo rằng thiết bị gửi thông báo này phát hiện đƣợc một trong những kết nối truyền thông (communication link) của nó gặp lỗi. Trong thông báo trap có tham số chỉ ra ifIndex của kết nối bị lỗi.
linkUp (3)
Thông báo rằng thiết bị gửi thông báo này phát hiện đƣợc một trong những kết nối truyền thông của nó đã khôi phục trở lại. Trong thông báo trap có tham số chỉ ra ifIndex của kết nối đƣợc khôi phục.
authenticationFailure (4)
Thông báo rằng thiết bị gửi thông báo này đã nhận đƣợc một thông báo không đƣợc chứng thực thành công (thông báo bị chứng thực không thành công có thể thuộc nhiều giao thức khác nhau nhƣ telnet, ssh, snmp, ftp, …). Thông thƣờng trap loại này xảy ra là do user đăng nhập không thành công vào thiết bị.
egpNeighborLoss (5)
Thông báo rằng một trong số những “EGP neighbor” của thiết bị gửi trap đã bị coi là down và quan hệ đối tác (peer relationship) giữa 2 bên không còn đƣợc duy trì. (EGP : Exterior Gateway Protocol)
enterpriseSpecific (6)
Thông báo rằng thông báo trap này không thuộc các kiểu generic nhƣ trên mà nó là một loại thông báo do ngƣời dùng tự định nghĩa.
Bảng 2.3 – Tên và số hiệu các loại Trap trong SNMP
2.1.5.7. SNMP Notification
Để chuẩn hóa định dạng PDU “trap” của SNMPv1 do PDU của “get” và “set” khác nhau, SNMPv2 đƣa ra “NOTIFICATION-TYPE”. Định dạng PDU của “NOTIFICATION-TYPE” là để nhận ra “get” và “set”.
2.1.5.8. SNMP inform
SNMPv2 cung cấp cơ chế truyền thông giữa những NMS với nhau, gọi là SNMP inform. Khi một NMS gửi một SNMP inform cho một NMS khác, NMS nhận đƣợc sẽ gửi trả một con số xác nhận sự kiện. Việc này giống với cơ chế của “get” và “set”.
2.1.5.9. SNMP report
Đƣợc định nghĩa trong bản nháp của SNMPv2 nhƣng không đƣợc phát triển. Sau đó đƣợc đƣa vào SNMPv3 và hy vọng dùng để truyền thông giữa các hệ thống SNMP với nhau.
2.2. Bảo mật trong SNMPv1
Một SNMP management station có thể quản trị/giám sát nhiều SNMP Agent, thông qua hoạt động gửi request và nhận trap. Tuy nhiên một SNMP Agent có thể đƣợc cấu hình để chỉ cho phép các SNMP management station nào đó đƣợc phép quản trị/giám sát mình.
Các cơ chế bảo mật đơn giản này gồm có : community string, view và SNMP access control list (danh sách điều khiển truy cập).
Community string là một chuỗi ký tự đƣợc cài đặt giống nhau trên cả SNMP manager và SNMP agent, đóng vai trò nhƣ “mật khẩu” giữa 2 bên khi trao đổi dữ liệu. Community string có 3 loại : Read-community, Write-Community và Trap- Community.
Khi manager gửi GetRequest, GetNextRequest đến agent thì trong thông báo gửi đi có chứa Read-Community. Khi agent nhận đƣợc thông báo request thì nó sẽ so sánh Read-community do manager gửi và Read-community mà nó đƣợc cài đặt. Nếu 2 chuỗi này giống nhau, agent sẽ trả lời; nếu 2 chuỗi này khác nhau, agent sẽ không trả lời.
Write-Community đƣợc dùng trong thông báo SetRequest. Agent chỉ chấp nhận thay đổi dữ liệu khi write-community 2 bên giống nhau.
Trap-community nằm trong thông báo trap của trap sender gửi cho trap receiver. Trap receiver chỉ nhận và lƣu trữ thông báo trap chỉ khi trap-community 2 bên giống nhau, tuy nhiên cũng có nhiều trap receiver đƣợc cấu hình nhận tất cả thông báo trap mà không quan tâm đến trap-community.
Community string có 3 loại nhƣ trên nhƣng cùng một loại có thể có nhiều string khác nhau. Nghĩa là một agent có thể khai báo nhiều read-community, nhiều write-community.
Trên hầu hết hệ thống, read-community mặc định là “public”, write- community mặc định là “private” và trap-community mặc định là “public”.
Community string chỉ là chuỗi ký tự dạng cleartext, do đó hoàn toàn có thể bị nghe lén khi truyền trên mạng. Hơn nữa, các community mặc định thƣờng là “public” và “private” nên nếu ngƣời quản trị không thay đổi thì chúng có thể dễ dàng bị dò ra. Khi community string trong mạng bị lộ, một ngƣời dùng bình thƣờng tại một máy tính nào đó trong mạng có thể quản trị/giám sát toàn bộ các device có cùng community mà không đƣợc sự cho phép của ngƣời quản trị.
View
Khi manager có read-community thì nó có thể đọc toàn bộ OID của agent. Tuy nhiên agent có thể quy định chỉ cho phép đọc một số OID có liên quan nhau, tức là chỉ đọc đƣợc một phần của MIB. Tập con của MIB này gọi là view, trên agent có thể định nghĩa nhiều view. Ví dụ : agent có thể định nghĩa view interfaceView bao gồm các OID liên quan đến interface, storageView bao gồm các OID liên quan đến lƣu trữ, hay AllView bao gồm tất cả các OID.
Một view phải gắn liền với một community string. Tùy vào community string nhận đƣợc là gì mà agent xử lý trên view tƣơng ứng. Ví dụ : agent định nghĩa read-community “inf” trên view interfaceView, và “sto” trên storageView. Khi manager gửi request lấy OID ifNumber với community là “inf” thì sẽ đƣợc đáp ứng do ifNumber nằm trong interfaceView; nếu manager request OID hrStorageSize với community “inf” thì agent sẽ không trả lời do hrStorageSize không nằm trong interfaceView; nhƣng nếu manager request hrStorageSize với community “sto” thì sẽ đƣợc trả lời do hrStorageSize nằm trong storageView.
Việc định nghĩa các view nhƣ thế nào tùy thuộc vào từng SNMP agent khác nhau. Có nhiều hệ thống không hỗ trợ tính năng view.
Access control list
Khi manager gửi không đúng community hoặc khi OID cần lấy lại không nằm trong view cho phép thì agent sẽ không trả lời. Tuy nhiên khi community bị lộ thì một manager nào đó vẫn request đƣợc thông tin. Để ngăn chặn hoàn toàn các SNMP manager không đƣợc phép, ngƣời quản trị có thể dùng đến SNMP access control list (ACL).
SNMP ACL là một danh sách các địa chỉ IP đƣợc phép quản trị/giám sát agent, nó chỉ áp dụng riêng cho giao thức SNMP và đƣợc cài trên agent. Nếu một manager có IP không đƣợc phép trong ACL gửi request thì agent sẽ không xử lý, dù request có community string là đúng. Đa số các thiết bị tƣơng thích SNMP đều cho phép thiết lập SNMP ACL.
Hạn chế SNMPv1 trong bảo mật là: Do sử dụng community nhƣ là mật khẩu nên SNMPv1 là giao thức rất yếu về bảo mật. Các gói tin đƣợc gửi đi dƣới dạng thuần văn bản nên không chống đỡ đƣợc kiểu tấn công bằng cách nghe lén (sniffer). Do đó các phiên bản SNMPv2 ra đời để khắc phục vấn đề này, chúng ta sẽ nghiên cứu ở phần tiếp sau đây.
2.3. Cơ chế bảo mật trong SNMPv2
SNMPv2 cố gắng giải quyết vấn đề an ninh của SNMPv1 dựa trên các cách tiếp cận chặt chẽ hơn. Một phiên bản gọi là SNMPv2 party-based tiếp cận theo hƣớng: tùy từng yêu cầu về xác thực và tính bảo mật mà có thể sử dụng các kênh khác nhau để trao đổi thông tin. Sử dụng 3 kênh bảo mật khác nhau bằng cách thay
thế community (chia sẻ dùng chung giữa tất cả các bên tham gia) bằng kênh (party), mỗi party chia thành nhiều nhóm, mỗi nhóm trao đổi theo cách thức riêng.
Kênh thứ nhất sử dụng để truyền số liệu không quan trọng giữa A và B, do vậy sử dụng cặp Party 1.A và Party 1.B có tính chất mở - open. Kênh thứ hai để đọc và thay đổi cấu hình thông thƣờng, yêu cầu có xác thực nên sử dụng cặp Party 2.A và Party 2.B có tính chất xác thực (authenticated). Kênh thứ ba truyền cấu hình rất quan trọng, yêu cầu phải bảo mật nên sử dụng cặp Party 3.A và Party 3.B có tính mật.
Tuy nhiên, với nhiều nỗ lực để tăng cƣờng bảo mật trong SNMP đã dẫn tới ba phiên bản không tƣơng thích với nhau là: SNMPv2p hay SNMPv2 party-based, SNMPv2u hay SNMPv2 user-based và SNMPv2*. Các phiên bản này đã thất bại trong việc tìm đƣợc sử hỗ trợ của các nhà sản xuất và dừng lại ở bản thảo, rồi chuyển sang quá khứ. Cuối cùng, một sự thỏa hiệp đƣợc thực hiện và kết quà là chuẩn SNMPv2c hay SNMP community-string-based. Đây là một bƣớc tụt lùi khi quay lại sử dụng community nhƣ SNMPv1, tuy nhiên chuẩn này lại đƣợc hỗ trợ của IETF cũng nhƣ cách nhà sản xuất. Trong luận văn này, khi nói đến SNMPv2 là ám chỉ SNMPv2c. Vấn đề về bảo mật chỉ đƣợc giải quyết triệt để chỉ khi xuất hiện phiên bản SNMPv3. SMNPv3 ra đời chủ yếu để giải quyết vấn đề bức xúc về bảo mật.
2.4. Giải pháp an ninh cho các thông báo trong SNMPv3 2.4.1. Các khái niệm cơ bản 2.4.1. Các khái niệm cơ bản
Tất cả các Agent SNMP và Network Management Stations (NMS) trƣớc đây nay đƣợc gọi là các SNMP entity. Một SNMP entity đƣợc tạo ra từ hai phần: một SNMP engine và các phần mềm ứng dụng SNMP (application).
SNMP Engine
SNMP engine cung cấp các dịch vụ cho quá trình gửi và nhận các thông báo, chứng thực và mã hoá các thông báo, điều khiển truy cập tới các đối tƣợng quản trị. Có một sự kết hợp 1-1 giữa SNMP engine và SNMP entity chứa nó.
SNMP engine chứa 4 thành phần là: - Dispatcher: Bộ điều vận.
- Security Subsystem: Phân hệ bảo mật.
- Access Control Subsystem: Phân hệ điều khiển truy cập.
Bộ điều vận: Trong mỗi SNMP entity chỉ có một bộ điều vận duy nhất. Nó cho phép sự hỗ trợ tồn tại nhiều phiên bản khác nhau của thông báo SNMP. Bộ điều vận có trách nhiệm:
- Gửi và nhận các thông báo SNMP.
- Xác định các phiên bản của thông báo và tƣơng tác với các mô hình xử lý thông báo. Khi nhận đƣợc một thông báo, bộ điều vận xác định số hiệu phiên bản của thông báo và sau đó chuyển thông báo đến khối xử lý thông báo tƣơng ứng. Nếu thông báo không thể phân tích để xác định phiên bản thì bộ đếm snmpInASNParseErrs tăng lên và thông báo bị loại bỏ. Nếu phiên bản không đƣợc hỗ trợ bởi phân hệ xử lý thông báo thì bộ đếm snmpInBadVersions tăng lên và thông báo bị loại bỏ.
- Cung cấp một giao diện tới ứng dụng SNMP cho các lần gửi và nhận của các PDU tới ứng dụng.
- Cung cấp một giao diện tới các ứng dụng SNMP mà nó cho phép chúng gửi một PDU tới một SNMP entity ở xa.
Phân hệ xử lý thông báo: Phân hệ xử lý thông báo có trách nhiệm: chuẩn bị các thông báo để gửi đi và trích dữ liệu từ các thông báo nhận đƣợc.
Phân hệ xử lý thông báo đƣợc tạo thành từ một hoặc nhiều khối xử lý thông báo.
Phân hệ bảo mật: Các phân hệ bảo mật cung cấp các dịch vụ bảo mật nhƣ: Xác nhận thông báo, mã hoá và giải mã các thông báo để đảm bảo bí mật.
Hình 2.13 – Phân hệ bảo mật User-Based Security Model (Mô hình bảo mật ngƣời dùng) Community-Based Security Model (Mô hình bảo mật truyền thống) Other Security Model (Mô hình bảo mật khác) Security Subsystem (Phân hệ bảo mật)
Hình 2.14– Cấu trúc SNMP entity
Phân hệ điều khiển truy cập: Trách nhiệm của phân hệ điều khiển truy cập là: xác định khi nào việc truy cập vào một đối tƣợng quản trị là đƣợc phép. Hiện nay mới định nghĩa một mô hình: mô hình điều khiển truy cập trên cơ sở thẩm tra (View-base Access Control Model - VACM). Cấu trúc SNMPv3 cho phép các mô hình điều khiển truy cập bổ sung đƣợc định nghĩa trong tƣơng lai.
SNMPv3 cung cấp hệ thống quản trị với các chức năng bảo mật quan trọng bằng cách sử dụng hai mô hình an ninh khác nhau. Mô hình bảo mật ngƣời dùng dựa trên Security Model (USM) cung cấp các chứng thực giữa ngƣời quản trị và agent để chứng thực chỉ ra những thông báo là đáng tin cậy. USM cũng cung cấp thêm sự bí mật bằng cách cung cấp mật mã của payload SNMP. Mô hình View-
Dispathcher Bộ điều vận Message Processing Subsystem Hệ thống con xử lý thông báo Security Subsystem Hệ thống con bảo mật Access Control Subsystem Hệ thống con điều khiển truy
cập