VietNetwork.Vn

Các cơ chế bảo mật SNMP:

Một SNMP management station có thể quản lý/giám sát nhiều SNMP element, thông qua hoạt động gửi request và nhận trap. Tuy nhiên một SNMP element có thể được cấu hình để chỉ cho phép các SNMP management station nào đó được phép quản lý/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.

Community String

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 bản tin gửi đi có chứa Read- Community. Khi agent nhận được bản tin 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 bản tin 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 bản tin trap của trap sender gửi cho trap receiver. Trap receiver chỉ nhận và lưu trữ bản tin 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ả bản tin 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 lý/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.

SNMP – ACL (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 lý/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.

Cấu trúc bản tin SNMP
+ Version : v1 = 0, v2c = 1, v2u = 2, v3 = 3.

+ Phần Data trong bản tin SNMP gọi là PDU (Protocol Data Unit).

SNMPv1 có 5 phương thức hoạt động tương ứng 5 loại PDU. Tuy nhiên chỉ có 2 loại định dạng bản tin là PDU và Trap-PDU; trong đó các bản tin Get, GetNext, Set, GetResponse có cùng định dạng là PDU, còn bản tin Trap có định dạng là Trap-PDU.

Cơ sở thông tin quản lý MIB:
Cấu trúc của MIB (Version 1)
MIB là một cấu trúc dữ liệu định nghĩa các đối tượng được quản lý, được thiết kế để quản lý các thiết bị không chỉ riêng TCP/IP. RFC1155 1 mô tả cấu trúc của mib file, cấu trúc này gọi là SMI (Structure of Management Information). Sau này người ta mở rộng thêm cấu trúc của mib thành SMI version 2, và phiên bản trong RFC1155 được gọi là SMIv1.

Trước khi đi vào tìm hiểu cấu trúc của mib, chúng ta phải đi sơ lược qua một chuẩn gọi là ASN.1:

    ASN.1 (Abstract Syntax Notation One) là chuẩn mô tả các luật mã hóa dữ liệu (encoding rules) cho các hệ thống truyền thông số. Một trong 3 hệ thống luật mã hóa trong ASN.1 là BER (Basic Encoding Rules). BER được SNMP dùng làm phương pháp mã hóa dữ liệu. Vì vậy trong các RFC liên quan đến SNMP ta hay bắt gặp dòng ghi chú "use of the basic encoding rules of ASN.1".

    BER mô tả nhiều kiểu dữ liệu như: BOOLEAN, INTEGER, ENUMERATED, OCTET STRING, CHOICE, OBJECT IDENTIFIER, NULL, SEQUENCE, ....

    Chúng ta sẽ dành hẳn một chương để nói về các luật mã hóa của "BER of ASN.1" và cách đọc bản tin SNMP từ việc phân tách các byte dựa vào luật BER.

Quay lại RFC1155, mỗi đối tượng bao gồm 3 phần: Name, Syntax và Encoding.

Name:
Name là định danh của object, có kiểu OBJECT IDENTIFIER. OBJECT IDENTIFIER là một chuỗi thứ tự các số nguyên biểu diễn các nút (node) của một cây từ gốc đến ngọn.

Gốc (root node) trong mib không không có tên. Dưới root là 3 node con:

Ccitt(0): do CCITT quản lý (Consultative Committee for International Telephone and Telegraph).

Iso(1): do tổ chức ISO quản lý (International Organization for Standardization). Joint-iso-ccitt(2): do cả ISO và CCITT quản lý.

Dưới node iso(1), tổ chức ISO thiết kế 1 node dành cho các tổ chức khác là org(3). Dưới org(3) có nhiều node con, một node được dành riêng cho US Department of Defense, dod(6).

Bộ Quốc phòng Mỹ được coi là nơi sáng lập ra mạng Internet, dưới dod(6) chỉ có 1 node dành cho cộng đồng internet ngày nay, là node internet(1).

Tất cả mọi thứ thuộc về cộng đồng Internet đều nằm dưới .iso.org.dod.internet, mọi object của các thiết bị TCP/IP đều bắt đầu với prefix .1.3.6.1 (dấu chấm đầu tiên biểu diễn rằng .iso là cây con của root, và root thì không có tên).

RFC1155 định nghĩa các cây con như sau:

internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }

directory OBJECT IDENTIFIER ::= { internet 1 }

mgmt OBJECT IDENTIFIER ::= { internet 2 }

experimental OBJECT IDENTIFIER ::= { internet 3 }

private OBJECT IDENTIFIER ::= { internet 4 }

enterprises OBJECT IDENTIFIER ::= { private 1 }

Mgmt (management): tất cả các mib chuẩn chính thức của internet đều nằm dưới mgmt. Mỗi khi một RFC mới về mib ra đời thì tổ chức IANA (Internet Assigned Numbers Authority) sẽ cấp cho mib đó một object-identifier nằm dưới mgmt.

Experimental: dùng cho các object đang trong quá trình thử nghiệm, được IANA cấp phát.

Private: dùng cho các object do người dùng tự định nghĩa, tuy nhiên các chỉ số cũng do IANA cấp. Tất cả các đơn vị cung cấp hệ thống mạng có thể đăng ký object-identifier cho sản phẩm của họ, chúng được cấp phát dưới node   Đăng nhập để xem liên kết.
Syntax:

- Syntax mô tả kiểu của object là gì. Syntax được lấy từ chuẩn ASN.1 nhưng không phải tất cả các kiểu đều được hỗ trợ. SMIv1 chỉ hỗ trợ 5 kiểu nguyên thủy (primitive types) lấy từ ASN.1 và 6 kiểu định nghĩa thêm (defined types).

- Primitive types: INTEGER, OCTET-STRING, OBJECT-IDENTIFIER, NULL, SEQUENCE. Defined types :

- NetworkAddress: kiểu địa chỉ internet (ip).

- IpAddress: kiểu địa chỉ internet 32-bit (ipv4), gồm 4 octet liên tục.

- Counter: kiểu số nguyên không âm 32-bit và tăng đều, khi số này tăng đến giới hạn thì phải quay lại từ 0. Giá trị tối đa là 232-1 (4294967295).

- Gauge: kiểu số nguyên không âm 32-bit, có thể tăng hoặc giảm nhưng không tăng quá giá trị tối đa 232-1.

- TimeTicks: kiểu số nguyên không âm, chỉ khoảng thời gian trôi qua kể từ một thời điểm nào đó, tính bằng phần trăm giây. VD từ khi hệ thống khởi động đến hiện tại là 1000 giây thì giá trị sysUpTime=100000.

- Opaque: kiểu này cho phép truyền một giá trị có kiểu tùy ý nhưng được đóng lại thành từng

- OCTET-STRING theo quy cách của ASN.1.

                Encoding

    Cơ chế Encoding như đã nói, là chuẩn BER trong ASN.1

                Cấu trúc kiểu OBJECT-TYPE

RFC1155 quy định cấu trúc của một record "định nghĩa đối tượng quản lý" (a managed object definition), kiểu dữ liệu này gọi là OBJECT-TYPE, các tài liệu mib khác khi viết định nghĩa cho một managed object nào đó thì phải theo quy định của SMI. Một "Managed Object Definition" có kiểu OBJECT-TYPE bao gồm các trường :

- SYNTAX: kiểu của object, là một trong các primitive types hoặc defined types ở trên.

- ACCESS: mức truy nhập của object, mang một trong các giá trị read-only, read-write, write-only, not- accessible.

- STATUS: mang một trong các giá trị mandatory (bắt buộc phải hỗ trợ), optional (có thể hỗ trợ hoặc không), obsolete (đã bị thay thế). Một agent nếu hỗ trợ một chuẩn mib nào đó thì bắt buộc phải hỗ trợ tất cả các object có status=mandatory, còn status=optional thì có thể hỗ trợ hoặc không.

- DESCRIPTION: dòng giải thích cho ý nghĩa của object.

            MIB-2 (RFC1213)

    RFC1155 mô tả cách trình bày một mib file như thế nào chứ không định nghĩa các object. RFC1213 là một chuẩn định nghĩa nhánh mib nằm dưới iso.org.dod.internet.mgmt.mib-2 (tất nhiên phải theo cấu trúc mà RFC1155 quy định). Chúng ta sẽ khảo sát một phần RFC1213 để hiểu ý nghĩa của một số object trước khi dùng công cụ để đọc chúng.

    RFC1156 là đặc tả mib chuẩn cho các thiết bị TCP/IP, được coi là Internet-Standard Mib (mib version 1). RFC1213 là đặc tả mib chuẩn version 2, thường gọi là mib-2. Chú ý phân biệt mib-1 và mib-2 là các chuẩn đặc tả định nghĩa của các object, còn SMIv1 và SMIv2 là đặc tả cấu trúc của mib file. Mib-1 và mib-2 sử dụng cấu trúc của SMIv1.
ib-2 là một trong những mib được hỗ trợ rộng rãi nhất. Nếu một thiết bị được tuyên bố là có hỗ trợ SNMP thì hãng sản xuất phải chỉ ra nó hỗ trợ các RFC nào, và thường là RFC1213. Nhiều bạn chỉ biết thiết bị của mình "có hỗ trợ SNMP" nhưng không rõ hỗ trợ các RFC nào, và dùng phần mềm giám sát SNMP hỗ trợ RFC1213 để giám sát thiết bị nhưng không thu được kết quả. Lý do là phần mềm thì hỗ trợ RFC1213 nhưng thiết bị thì không.

Các kiểu dữ liệu mới được định nghĩa trong mib-2 gồm:

    Display String: kế thừa từ kiểu OCTET STRING nhưng chỉ bao gồm các ký tự in được (printable characters) và dài không quá 255 ký tự.

    Physical Address: giống kiểu OCTET STRING, được dùng để biểu diễn địa chỉ vật lý của thiết bị.

Cấu trúc của mib là dạng cây, để xác định object identifier của một object bạn phải đi từ gốc đến object đó. Ví dụ: bandwidth của interface thứ 3 trên thiết bị thì có OID là.1.3.6.1.2.1.2.2.1.5(.iso.org.dod.internet.mgmt.mib 2.interfaces.ifTable.ifEntry.ifSpeed.3).

Chú ý: mặc dù mib-2 đã quy định index của từng interface phải liên tục và chạy từ 1 đến ifNumber, nhưng trong thực tế nhiều thiết bị không đặt index liên tục mà đặt theo cách riêng để dễ quản lý. Do đó đối với C2950 thì interface thứ 3 có index là 3, nhưng đối với thiết bị khác thì interface thứ 3 có thể có index khác 3, thậm chí là số rất lớn. Chẳng hạn một switch có nhiều card, mỗi card có 12 port thì port1-card1 có index là 101, port12-card1 có index là 112, port1-card2 có index là 201.

            SMIv2

SMIv2 (Structure of Management Information version 2) được trình bày trong RFC2578, bao gồm nhiều thay đổi trong cấu trúc mib file. Phần này trình bày những thay đổi chủ yếu nhất.

Các kiểu dữ liệu mới hoặc thay đổi so với SMIv1

    INTEGER32: số nguyên nằm trong khoảng -231 and 231-1 (-2147483648 to 2147483647 decimal).

    OCTET STRING: kiểu chuỗi ký tự, độ dài tối đa 65535.

    OBJECT IDENTIFIER: định danh của object, không quá 128 phần tử (sub-identifier), mỗi phần tử là số nguyên không quá 232-1.

    COUNTER32: kiểu số nguyên không âm tăng dần, tối đa là 232-1, khi vượt giá trị tối đa thì quay lại từ 0. Counter32 không bắt buộc giá trị bắt đầu phải là 0.

    GAUGE32: kiểu số nguyên không âm tăng hoặc giảm, giới hạn trong khoảng 0 ~ 232-1, nó không thể vượt ra giới hạn này.

    COUNTER64: kiểm số nguyên không âm tăng dần, tối đa là 264-1 (18446744073709551615).

    UNSIGNED32: kiểu số nguyên từ 0 ~ 232-1.

Kiểu dữ liệu OBJECT-TYPE

Trong SMIv1 kiểu OBJECT-TYPE bao gồm : SYNTAX, ACCESS, STATUS, DESCRIPTION. Trong SMIv2 kiểu OBJECT-TYPE bao gồm các trường: SYNTAX, UNITS, MAX-ACCESS, STATUS, DESCRIPTION, REFERENCE, INDEX, AUGMENTS, DEFVAL.

    SYNTAX: kiểu dữ liệu của object, là một kiểu theo chuẩn ASN.1 hoặc các kiểu định nghĩa riêng của SMIv2.

    UNITS: là dòng text mô tả một unit nào đó gắn liền với object, trường này không bắt buộc phải có.

    MAX_ACCESS: có 5 quyền truy xuất object có ưu tiên từ thấp đến cao là "not-accessible", "accessible- for-notify", "read-only", "read-write", "read-create"; MAX_ACCESS quy định quyền cao nhất tác động đến object, quyền cao hơn bao gồm các quyền thấp hơn. VD object có MAX_ACCESS là "read-write" thì có thể được đọc/ghi nhưng không thể tạo.

    STATUS: trạng thái của object, mang một trong các giá trị "current" (định nghĩa của object đang có hiệu lực và đang được sử dụng), "obsolete" (định nghĩa này đã cũ và có thể bỏ đi), "depricated" (định nghĩa này đã cũ và các chuẩn tiếp theo có thể định nghĩa lại).

    DESCRIPTION: dòng text mô tả thông tin ý nghĩa của object.

    REFERENCE: là dòng text mô tả đến các tài liệu khác có liên quan đến object này, reference không bắt buộc phải có.

    INDEX: chỉ ra trường index của object hiện tại. VD ifDescr có INDEX = ifIndex.

    AUGMENTS: tương tự như INDEX và có thể dùng thay thế INDEX, nhưng chỉ một trong 2 trường INDEX hoặc AUGMENTS tồn tại, không thể tổn tại cùng lúc cả 2.

    DEFVA : giá trị mặc định (default value) của object khi nó được tạo ra.

Kiểu dữ liệu NOTIFICATION-TYPE

Kiểu NOTIFICATION-TYPE được dùng để mô tả những thông tin quản lý mạng được truyền không theo yêu cầu (ví dụ bản tin TrapPDU hoặc InformRequestPDU của SNMPv2, chúng được tự động gửi đi khi có sự kiện xảy ra mà không cần phải có request từ thiết bị khác).

Các notification phải được định nghĩa trong mib, cấu trúc của chúng bao gồm các mệnh đề sau:

    OBJECT: danh sách có thứ tự các object có liên quan đến notification, vd bản tin notification cho 4 interface của thiết bị thì OBJECT phải chứa ifIndex của 4 interface đó.

    STATUS: mang một trong 3 giá trị "current", "obsolete" hoặc "depricated".

    DESCRIPTION: dòng text mô tả ý nghĩa của notification.

    REFERENCE: mô tả các tài liệu có liên quan đến định nghĩa của notification, REFERENCE không bắt buộc phải có.

            Host-Resources-Mib (RFC2790)

RFC2790 là mib dùng cho host, nó cung cấp định nghĩa nhiều object như thông tin hệ thống, lưu trữ, device, software, performance. Dịch vụ SNMP agent trên Windows và Linux đều hỗ trợ RFC2790.

Vị trí của Host-mib trong mib như sau:
Các kiểu dữ liệu mới được định nghĩa trong host-mib gồm:

    Kbytes: kiểu INTEGER32, thể hiện kích thước của thiết bị lưu trữ, đơn vị tính là 1024 Bytes.

    ProductID: xác định nhà sản xuất, model, phiên bản của phần cứng hay phần mềm.

    AutonomousType: kiểu giá trị định danh có thể mở rộng độc lập, ví dụ nó có thể chỉ ra một cây mib con nào đó được định nghĩa bởi một tài liệu khác.

    DateAndTime: kiểu ngày và giờ, định dạng như sau :"year-mon-day,hour:min:sec.centiSec,±HourFromUCT:MinFromUTC".

Ví dụ "15/01/2010 1:30:15 PM,GMT+7" được biểu diễn là "2010-01-15,13:30:15.0,+7:0"