Nghiên cứu & triển khai ManageEngine OpManager 9.0

i thì Manager vẫ không thể biết được những gì đã xảy ra. Chỉ cần cài đặt Manager để trỏ đến tất cả các Device. Có thể dễ dàng thay đổi một Manager khác. Phải cài đặt tại từng Device để trỏ đến Manager. Khi thay đổi Manager thì phải cài đặt lại trên tất cả Device để trỏ về Manager mới. Nếu tần suất poll thấp, thời gian chờ giữa 2 chu kì poll dài sẽ làm Manager chậm cập nhật các thay đổi của Device. Nghĩa là nếu thông tin Device đã thay đổi nhưng vẫn chưa đến lượt poll kế tiếp thì Manager vẫn chưa đến lượt poll kế tiếp thì Manager vẫn giữ thông tin cũ. Ngay khi có sự kiện xảy ra thì Device sẽ gửi Alert đến Manager, do đó Manager Có thể bỏ sót các sự kiện: khi Device có thay đổi, sau đó thay đổi trở lại như ban đầu trước khi đến poll kế tiếp thì Manager sẽ không phát hiện được. Manager sẽ được thông báo mỗi khi có sự kiện xảy ra ở Device, do đó Manager không bỏ sót bất kỳ sự kiện nào. Giới thiệu về giao thức SNMP: SNMP – giao thức quản lý mạng đơn giản. SNMP là “giao thức quản lý mạng đơn giản”, dịch từ cụm từ “Simple Network Management Protocol”. Giao thức là một tập hợp các thủ tục mà các bên tham gia cần tuân theo để có thể giao tiếp được với nhau. Trong lĩnh vực thông tin, một giao thức quy định cấu trúc, định dạng (format) của dòng dữ liệu trao đổi với nhau và quy định trình tự, thủ tục để trao đổi dòng dữ liệu đó. Nếu một bên tham gia gửi dữ liệu không đúng định dạng hoặc không theo trình tự thì các bên khác sẽ không hiểu hoặc từ chối trao đổi thông tin. SNMP là một giao thức, do đó nó có những quy định riêng mà các thành phần trong mạng phải tuân theo. Một thiết bị hiểu được và hoạt động tuân theo giao thức SNMP được gọi là “có hỗ trợ SNMP” (SNMP supported) hoặc “tương thích SNMP” (SNMP compartible). SNMP dùng để quản lý, nghĩa là có thể theo dõi, có thể lấy thông tin, có thể được thông báo, và có thể tác động để hệ thống hoạt động như ý muốn. VD một số khả năng của phần mềm SNMP: Theo dõi tốc độ đường truyền của một router, biết được tổng số byte đã truyền/nhận. Lấy thông tin máy chủ đang có bao nhiêu ổ cứng, mỗi ổ cứng còn trống bao nhiêu. Tự động nhận cảnh báo khi switch có một port bị down. Điều khiển tắt (shutdown) các port trên switch. SNMP dùng để quản lý mạng, nghĩa là nó được thiết kế để chạy trên nền TCP/IP và quản lý các thiết bị có nối mạng TCP/IP. Các thiết bị mạng không nhất thiết phải là máy tính mà có thể là switch, router, firewall, adsl gateway, và cả một số phần mềm cho phép quản trị bằng SNMP. Giả sử bạn có một cái máy giặt có thể nối mạng IP và nó hỗ trợ SNMP thì bạn có thể quản lý nó từ xa bằng SNMP. SNMP là giao thức đơn giản, do nó được thiết kế đơn giản trong cấu trúc bản tin và thủ tục hoạt động, và còn đơn giản trong bảo mật (ngoại trừ SNMP version 3). Sử dụng phần mềm SNMP, người quản trị mạng có thể quản lý, giám sát tập trung từ xa toàn mạng của mình. Ưu điểm trong thiết kế SNMP SNMP được thiết kế để đơn giản hóa quá trình quản lý các thành phần trong mạng. Nhờ đó các phần mềm SNMP có thể được phát triển nhanh và tốn ít chi phí. SNMP được thiết kế để có thể mở rộng các chức năng quản lý, giám sát. Không có giới hạn rằng SNMP có thể quản lý được cái gì. Khi có một thiết bị mới với các thuộc tính, tính năng mới thì người ta có thể thiết kế “custom” SNMP để phục vụ cho riêng mình. SNMP được thiết kế để có thể hoạt động độc lập với các kiến trúc và cơ chế của các thiết bị hỗ trợ SNMP. Các thiết bị khác nhau có hoạt động khác nhau nhưng đáp ứng SNMP là giống nhau. VD bạn có thể dùng 1 phần mềm để theo dõi dung lượng ổ cứng còn trống của các máy chủ chạy HĐH Windows và Linux; trong khi nếu không dùng SNMP mà làm trực tiếp trên các HĐH này thì bạn phải thực hiện theo các cách khác nhau. Các phiên bản của SNMP SNMP có 4 phiên bản: SNMPv1, SNMPv2c, SNMPv2u và SNMPv3. Các phiên bản này khác nhau một chút ở định dạng bản tin và phương thức hoạt động. Hiện tại SNMPv1 là phổ biến nhất do có nhiều thiết bị tương thích nhất và có nhiều phần mềm hỗ trợ nhất. Trong khi đó chỉ có một số thiết bị và phần mềm hỗ trợ SNMPv3. SNMP version 1: chuẩn của giao thức SNMP được định nghĩa trong RFC 1157 và là một chuẩn đầy đủ của IETF. Vấn đề bảo mật của SNMPv1 dựa trên nguyên tắc cộng đồng, không có nhiều password, chuỗi văn bản thuần và cho phép bất kỳ một ứng dụng nào đó dựa trên SNMP có thể hiểu các chuỗi này để có thể truy cập vào các thiết bị quản lý. Có 3 tiêu chuẩn trong: read-only, read-write và trap. SNMP version 2: phiên bản này dựa trên các chuỗi “community”. Do đó phiên bản này được gọi là SNMPv2c, được định nghĩa trong RFC 1905, 1906, 1907 và đây chỉ là bản thử nghiệm của IETF. Mặc dù chỉ là thử nghiệm nhưng nhiều nhà sản xuất đã đưa nó vào thực nghiệm. SNMP version 3: là phiên bản tiếp theo được IETF đưa ra bản đầy đủ (phiên bản gần đây của SNMP), đóng vai trò an ninh cao trong quản trị mạng và đóng vai trò mạnh trong vấn đề thẩm quyền, quản lý kênh truyền riêng giữa các thực thể. Nó được khuyến nghị làm bản chuẩn, được định nghĩa trong RFC 1905, RFC 1906, RFC 1907, RFC 2271 RFC 2571, RFC 2572, RFC 2573, RFC 2574 và RFC 257a5. Nó hỗ trợ các loại truyền thông riêng tư và có xác nhận giữa các thực thể. Các khái niệm nền tảng của SNMP: Các thành phần trong SNMP Theo RFC1157 ((Request for Comments) là các tài liệu mô tả các giao thức, thủ tục hoạt động trên internet. RFC do các cá nhân, tổ chức đưa ra như là các chuẩn, nhà phát triển sản phẩm có thể tuân theo hoặc không theo một RFC nào đó. Khi một RFC tốt được nhiều nhà phát triển tuân theo thì các nhà phát triển khác cũng nên hỗ trợ để có thể tương thích tốt với cộng đồng ), kiến trúc của SNMP bao gồm 2 thành phần: các trạm quản lý mạng (network management station) và các thành tố mạng (network element). Network management station thường là một máy tính chạy phần mềm quản lý SNMP (SNMP management application), dùng để giám sát và điều khiển tập trung các network element. Network management station Network element là các thiết bị, máy tính, hoặc phần mềm tương thích SNMP và được quản lý bởi network management station. Như vậy element bao gồm device, host và application. Một management station có thể quản lý nhiều element, một element cũng có thể được quản lý bởi nhiều management station. Vậy nếu một element được quản lý bởi 2 station thì điều gì sẽ xảy ra? Nếu station lấy thông tin từ element thì cả 2 station sẽ có thông tin giống nhau. Nếu 2 station tác động đến cùng một element thì element sẽ đáp ứng cả 2 tác động theo thứ tự cái nào đến trước. Ngoài ra còn có khái niệm SNMP agent. SNMP agent là một tiến trình (process) chạy trên network element, có nhiệm vụ cung cấp thông tin của element cho station, nhờ đó station có thể quản lý được element. Chính xác hơn là application chạy trên station và agent chạy trên element mới là 2 tiến trình SNMP trực tiếp liên hệ với nhau. Các ví dụ minh họa sau đây sẽ làm rõ hơn các khái niệm này: Để dùng một máy chủ (= station) quản lý các máy con (= element) chạy HĐH Windows thông qua SNMP thì bạn phải: cài đặt một phần mềm quản lý SNMP (= application) trên máy chủ, bật SNMP service (= agent) trên máy con. Để dùng một máy chủ (= station) giám sát lưu lượng của một router (= element) thì bạn phải: cài phần mềm quản lý SNMP (= application) trên máy chủ, bật tính năng SNMP (= agent) trên router. giám sát lưu lượng của một router Object ID Một thiết bị hỗ trợ SNMP có thể cung cấp nhiều thông tin khác nhau, mỗi thông tin đó gọi là một object. Ví dụ: - Máy tính có thể cung cấp các thông tin: tổng số ổ cứng, tổng số port nối mạng, tổng số byte đã truyền/nhận, tên máy tính, tên các process đang chạy, …. - Router có thể cung cấp các thông tin: tổng số card, tổng số port, tổng số byte đã truyền/nhận, tên router, tình trạng các port của router, ….Mỗi object có một tên gọi và một mã số để nhận dạng object đó, mã số gọi là Object ID (OID). VD: - Tên thiết bị được gọi là sysName, OID là 1.3.6.1.2.1.1.5 ( RFC1213 mô tả sysName đầy đủ là “An administratively-assigned name for this managed node. By convention, this is the node’s fully-qualified domain name”). - Tổng số port giao tiếp (interface) được gọi là ifNumber, OID là 1.3.6.1.2.1.2.1. - Địa chỉ Mac Address của một port được gọi là ifPhysAddress, OID là 1.3.6.1.2.1.2.2.1.6. - Số byte đã nhận trên một port được gọi là ifInOctets, OID là 1.3.6.1.2.1.2.2.1.10. Bạn hãy khoan thắc mắc ý nghĩa của từng chữ số trong OID, chúng sẽ được giải thích trong phần sau. Một object chỉ có một OID, chẳng hạn tên của thiết bị là một object. Tuy nhiên nếu một thiết bị lại có nhiều tên thì làm thế nào để phân biệt? Lúc này người ta dùng thêm 1 chỉ số gọi là “scalar instance index” (cũng có thể gọi là “sub-id”) đặt ngay sau OID. Ví dụ: - Tên thiết bị được gọi là sysName, OID là 1.3.6.1.2.1.1.5; nếu thiết bị có 2 tên thì chúng sẽ được gọi là sysName.0 & sysName.1 và có OID lần lượt là 1.3.6.1.2.1.1.5.0 & 1.3.6.1.2.1.1.5.1. - Địa chỉ Mac address được gọi là ifPhysAddress, OID là 1.3.6.1.2.1.2.2.1.6; nếu thiết bị có 2 mac address thì chúng sẽ được gọi là ifPhysAddress.0 & ifPhysAddress.1 và có OID lần lượt là 1.3.6.1.2.1.2.2.1.6.0 & 1.3.6.1.2.1.2.2.1.6.1. - Tổng số port được gọi là ifNumber, giá trị này chỉ có 1 (duy nhất) nên OID của nó không có phân cấp con và vẫn là 1.3.6.1.2.1.2.1. Ở hầu hết các thiết bị, các object có thể có nhiều giá trị thì thường được viết dưới dạng có sub-id. VD một thiết bị dù chỉ có 1 tên thì nó vẫn phải có OID là sysName.0 hay 1.3.6.1.2.1.1.5.0. Bạn cần nhớ quy tắc này để ứng dụng trong lập trình phần mềm SNMP manager. Sub-id không nhất thiết phải liên tục hay bắt đầu từ 0. VD một thiết bị có 2 mac address thì có thể chúng được gọi là ifPhysAddress.23 và ifPhysAddress.125645. OID của các object phổ biến có thể được chuẩn hóa, OID của các object do bạn tạo ra thì bạn phải tự mô tả chúng. Để lấy một thông tin có OID đã chuẩn hóa thì SNMP application phải gửi một bản tin SNMP có chứa OID của object đó cho SNMP agent, SNMP agent khi nhận được thì nó phải trả lời bằng thông tin ứng với OID đó. VD: Muốn lấy tên của một PC chạy Windows, tên của một PC chạy Linux hoặc tên của một router thì SNMP application chỉ cần gửi bản tin có chứa OID là 1.3.6.1.2.1.1.5.0. Khi SNMP agent chạy trên PC Windows, PC Linux hay router nhận được bản tin có chứa OID 1.3.6.1.2.1.1.5.0, agent lập tức hiểu rằng đây là bản tin hỏi sysName.0, và agent sẽ trả lời bằng tên của hệ thống. Nếu SNMP agent nhận được một OID mà nó không hiểu (không hỗ trợ) thì nó sẽ không trả lời. Hình minh họa quá trình lấy sysName Một trong các ưu điểm của SNMP là nó được thiết kế để chạy độc lập với các thiết bị khác nhau. Chính nhờ việc chuẩn hóa OID mà ta có thể dùng một SNMP application để lấy thông tin các loại device của các hãng khác nhau. Object Access Mỗi object có quyền truy cập là READ_ONLY hoặc READ_WRITE. Mọi object đều có thể đọc được nhưng chỉ những object có quyền READ_WRITE mới có thể thay đổi được giá trị. VD: Tên của một thiết bị (sysName) là READ_WRITE, ta có thể thay đổi tên của thiết bị thông qua giao thức SNMP. Tổng số port của thiết bị (ifNumber) là READ_ONLY, dĩ nhiên ta không thể thay đổi số port của nó. Management Information Base: MIB (cơ sở thông tin quản lý) là một cấu trúc dữ liệu gồm các đối tượng được quản lý (managed object), được dùng cho việc quản lý các thiết bị chạy trên nền TCP/IP. MIB là kiến trúc chung mà các giao thức quản lý trên TCP/IP nên tuân theo, trong đó có SNMP. MIB được thể hiện thành 1 file (MIB file), và có thể biểu diễn thành 1 cây (MIB tree). MIB có thể được chuẩn hóa hoặc tự tạo. Hình sau minh họa MIB tree: Minh họa MIB tree Một node trong cây là một object, có thể được gọi bằng tên hoặc id. Ví dụ: Node iso.org.dod.internet.mgmt.mib-2.system có OID là 1.3.6.1.2.1.1, chứa tất cả các object lien quan đến thông tin của một hệ thống như tên của thiết bị (iso.org.dod.internet.mgmt.mib-2.system.sysNam hay .3.6.1.2.1.1.5). Các OID của các hãng tự thiết kế nằm dưới iso.org.dod.internet.private. enterprise. Ví dụ : Cisco nằm dưới iso.org.dod.internet.private.enterprise.cisco hay 1.3.6.1.4.1.9, Microsoft nằm dưới iso.org.dod.internet.private.enterprise.microsoft hay 1.3.6.1.4.1.311. Số 9 (Cisco) hay 311 (Microsoft) là số dành riêng cho các công ty do IANA cấp 5. Nếu Cisco hay Microsoft chế tạo ra một thiết bị nào đó, thì thiết bị này có thể hỗ trợ các MIB chuẩn đã được định nghĩa sẵn (như mib-2) hay hỗ trợ MIB được thiết kế riêng. Các MIB được công ty nào thiết kế riêng thì phải nằm bên dưới OID của công ty đó. Các objectID trong MIB được sắp xếp thứ tự nhưng không phải là liên tục, khi biết một OID thì không chắc chắn có thể xác định được OID tiếp theo trong MIB. VD trong chuẩn mib-2 (MIB-2 được mô tả trong “RFC1213 - Management Information Base for Network Management of TCP/IP-based internets: MIB-II”) thì object ifSpecific và object atIfIndex nằm kề nhau nhưng OID lần lượt là 1.3.6.1.2.1.2.2.1.22 và 1.3.6.1.2.1.3.1.1.1. Muốn hiểu được một OID nào đó thì bạn cần có file MIB mô tả OID đó. Một MIB file không nhất thiết phải chứa toàn bộ cây ở trên mà có thể chỉ chứa mô tả cho một nhánh con. Bất cứ nhánh con nào và tất cả lá của nó đều có thể gọi là một mib. Một manager có thể quản lý được một device chỉ khi ứng dụng SNMP manager và ứng dụng SNMP agent cùng hỗ trợ một MIB. Các ứng dụng này cũng có thể hỗ trợ cùng lúc nhiều MIB. Các phương thức của SNMP: Giao thức SNMPv1 có 5 phương thức hoạt động, tương ứng với 5 loại bản tin như sau: Bản tin/phương thức Mô tả tác dụng GetRequest Manager gửi GetRequest cho agent để yêu cầu agent cung cấp thông tin nào đó dựa vào ObjectID (trong GetRequest có chứa OID) GetNextRequest Manager gửi GetNextRequest có chứa một ObjectID cho agent để yêu cầu cung cấp thông tin nằm kế tiếp ObjectID đó trong MIB. SetRequest Manager gửi SetRequest cho agent để đặt giá trị cho đối tượng của agent dựa vào ObjectID. GetResponse Agent gửi GetResponse cho Manager để trả lời khi nhận được Trap Agent tự động gửi Trap cho Manager khi có một sự kiện xảy ra đối với một object nào đó trong agent. Mỗi bản tin đều có chứa OID để cho biết object mang trong nó là gì. OID trong GetRequest cho biết nó muốn lấy thông tin của object nào. OID trong GetResponse cho biết nó mang giá trị của object nào. OID trong SetRequest chỉ ra nó muốn thiết lập giá trị cho object nào. OID trong Trap chỉ ra nó thông báo sự kiện xảy ra đối với object nào. GetRequest Bản tin GetRequest được manager gửi đến agent để lấy một thông tin nào đó. Trong GetRequest có chứa OID của object muốn lấy. VD: Muốn lấy thông tin tên của Device1 thì manager gửi bản tin GetRequest OID = 1.3.6.1.2.1.1.5 đến Device1, tiến trình SNMP agent trên Device1 sẽ nhận được bản tin và tạo bản tin trả lời. Trong một bản tin GetRequest có thể chứa nhiều OID, nghĩa là dùng một GetRequest có thể lấy về cùng lúc nhiều thông tin. GetNextRequest Bản tin GetNextRequest cũng dùng để lấy thông tin và cũng có chứa OID, tuy nhiên nó dùng để lấy thông tin của object nằm kế tiếp object được chỉ ra trong bản tin. Tại sao phải có phương thức GetNextRequest ? Như bạn đã biết khi đọc qua những phần trên: một MIB bao gồm nhiều OID được sắp xếp thứ tự nhưng không liên tục, nếu biết một OID thì không xác định được OID kế tiếp. Do đó ta cần GetNextRequest để lấy về giá trị của OID kế tiếp. Nếu thực hiện GetNextRequest liên tục thì ta sẽ lấy được toàn bộ thông tin của agent. SetRequest Bản tin SetRequest được manager gửi cho agent để thiết lập giá trị cho một object nào đó. Ví dụ: - Có thể đặt lại tên của một máy tính hay router bằng phần mềm SNMP manager, bằng cách gửi bản tin SetRequest có OID là 1.3.6.1.2.1.1.5.0 (sysName.0) và có giá trị là tên mới cần đặt. - Có thể shutdown một port trên switch bằng phần mềm SNMP manager, bằng cách gửi bản tin có OID là 1.3.6.1.2.1.2.2.1.7 (ifAdminStatus) và có giá trị là 2 (ifAdminStatus có thể mang 3 giá trị là UP (1), DOWN (2) và TESTING (3)). Chỉ những object có quyền READ_WRITE mới có thể thay đổi được giá trị. GetResponse: Mỗi khi SNMP agent nhận được các bản tin GetRequest, GetNextRequest hay SetRequest thì nó sẽ gửi lại bản tin GetResponse để trả lời. Trong bản tin GetResponse có chứa OID của object được request và giá trị của object đó. Trap: Bản tin Trap được agent tự động gửi cho manager mỗi khi có sự kiện xảy ra bên trong agent, các sự kiện này không phải là các hoạt động thường xuyên của agent mà là các sự kiện mang tính biến cố. Ví dụ: Khi có một port down, khi có một người dùng login không thành công, hoặc khi thiết bị khởi động lại, agent sẽ gửi trap cho manager. Tuy nhiên không phải mọi biến cố đều được agent gửi trap, cũng không phải mọi agent đều gửi trap khi xảy ra cùng một biến cố. Việc agent gửi hay không gửi trap cho biến cố nào là do hãng sản xuất device/agent quy định. Phương thức trap là độc lập với các phương thức request/response. SNMP request/response dùng để quản lý còn SNMP trap dùng để cảnh báo. Nguồn gửi trap gọi là Trap Sender và nơi nhận trap gọi là Trap Receiver. Một trap sender có thể được cấu hình để gửi trap đến nhiều trap receiver cùng lúc. Có 2 loại trap: trap phổ biến (generic trap) và trap đặc thù (specific trap). Generic trap được quy định trong các chuẩn SNMP, còn specific trap do người dùng tự định nghĩa (người dùng ở đây là hãng sản xuất SNMP device). Loại trap là một số nguyên chứa trong bản tin trap, dựa vào đó mà phía nhận trap biết bản tin trap có nghĩa gì. Theo SNMPv1, generic trap có 7 loại sau: coldStart(0), warmStart(1), linkDown(2), linkUp(3), authenticationFailure(4), egpNeighborloss(5), enterpriseSpecific(6). Giá trị trong ngoặc là mã số của các loại trap. Ý nghĩa của các bản tin generic-trap như sau: ColdStart: thông báo rằng thiết bị gửi bản tin này đang khởi động lại (reinitialize) và cấu hình của nó có thể bị thay đổi sau khi khởi động. WarmStart: thông báo rằng thiết bị gửi bản tin này đang khởi động lại và giữ nguyên cấu hình cũ. LinkDown: thông báo rằng thiết bị gửi bản tin 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 bản tin trap có tham số chỉ ra ifIndex của kết nối bị lỗi. LinkUp: thông báo rằng thiết bị gửi bản tin 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 bản tin trap có tham số chỉ ra ifIndex của kết nối được khôi phục. AuthenticationFailure: thông báo rằng thiết bị gửi bản tin này đã nhận được một bản tin không được chứng thực thành công (bản tin 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: thông báo rằng một trong số những “EGP neighbor” (EGP : Exterior Gateway Protocol ) 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ì. EnterpriseSpecific: thông báo rằng bản tin trap này không thuộc các kiểu generic như trên mà nó là một loại bản tin do người dùng tự định nghĩa. Người dùng có thể tự định nghĩa thêm các loại trap để làm phong phú thêm khả năng cảnh báo của thiết bị như: boardFailed, configChanged, powerLoss, cpuTooHigh, v.v…. Người dùng tự quy định ý nghĩa và giá trị của các specific trap này, và dĩ nhiên chỉ những trap receiver và trap sender hỗ trợ cùng một MIB mới có thể hiểu ý nghĩa của specific trap. Do đó nếu bạn dùng một phần mềm trap receiver bất kỳ để nhận trap của các trap sender bất kỳ, bạn có thể đọc và hiểu các generic trap khi chúng xảy ra; nhưng bạn sẽ không hiểu ý nghĩa các specific trap khi chúng hiện lên màn hình vì bản tin trap chỉ chứa những con số. Hình minh họa các phương thức của SNMPv1 Đối với các phương thức Get/Set/Response thì SNMP Agent lắng nghe ở port UDP 161, còn phương thức trap thì SNMP Trap Receiver lắng nghe ở port UDP 162. 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: SNMP chạy trên nền UDP. Cấu trúc của một bản tin SNMP bao gồm: version, community và data. 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 private.enterprises. Hình 1.9. SMIv1 (RFC1155) 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. Mib-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. Vị trí của MIB-2 trong mib 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: host OBJECT IDENTIFIER ::= { mib-2 25 } Tức là .iso.org.dod.internet.mgmt.mib-2.host hay .1.3.6.1.2.1.25. Vị trí của Host-mib trong mib 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” CHƯƠNG 2: PHẦN MỀM QUẢN LÝ MANAGEENGINE OPMANAGER 9.0 2.1. Giải pháp Tích hợp hệ thống - AdventNet ManageEngine 9.0: Công ty, tổ chức của bạn rất mong muốn quản lý toàn bộ và hiệu quả hệ thống IT đang ngày càng mở rộng và trở nên rối rắm, nhưng đang bị bối rối giữa một bên những giải pháp phức tạp, đòi hỏi trình độ cao cấp của CIO cùng với lượng vốn đầu tư khổng lồ và một bên những giải pháp đơn giản nhưng mang tính chắp vá, không mang lại nhiều hiệu quả và thậm chí gây tác động xấu đến hệ thống. Giải pháp ManageEngine của ZOHO Corp (Mỹ) nằm giữa 2 phân khúc trên. Với chi phí thấp và cho phép đầu tư dần dần theo kế hoạch cho từng giai đoạn mở rộng (purchase-as-you-grow), ManageEngine quản lý tình trạng của từng thiết bị đầu cuối, hệ thống mạng, các ứng dụng, khả năng bảo mật... một cách chi tiết, trực quan và thông minh theo cách mà bạn mong muốn, với chế độ làm việc 24x7 và giao diện được Việt hóa hoàn toàn. ManageEngine - Một cách tiếp cận hoàn toán mới đến việc Quản trị Doanh nghiệp. Trong quá trình vận hành hệ thống, để tìm ra một cách chính xác 'nguyên nhân gốc của vấn đề' và áp dụng phương pháp Quản lý chủ động, các Nhà quản lý CNTT chuyên nghiệp cần một Giải pháp tích hợp có thể làm việc với toàn bộ các Hệ thống Mạng, Máy chủ và các ứng dụng khác nhau. Tuy nhiên, tính phức tạp, chi phí và thời gian triển khai liên quan bị áp dụng theo khung làm việc thông thường sẽ là các nhân tố tác động khiến họ phải tìm các giải pháp xen kẽ thay thế, tập trung vào việc hiện đang cần giải quyết ngay. Do chưa thể tìm một giải pháp hoàn chỉnh, phù hợp trên thị trường hiện nay, nên khi cần tìm chính xác nguyên nhân gốc thực sự của vấn đề, những giải pháp hiện tại thường sẽ gặp các vấn đề không lường trước khác; và kết quả là các Nhà Quản trị Hệ thống luôn gặp các vấn đề mà họ luôn phải chống trả. Việc tìm một Giải pháp Chủ động - đối với họ - có vẻ như một giấc mơ xa xôi. ManageEngine có mục đích tạo ra một cầu nối cho khoảng cách này bằng cách cung cấp đến Doanh nghiệp một khả năng thay thế - giải pháp tích hợp làm việc với mọi Hệ thống Mạng, Máy chủ hay các ứng dụng, mà không làm tăng các chi phí và tính phức tạp. Hình 2.1. Giải pháp cho ManageEngine OpManager Các giải pháp ManageEngine: PasswordManager Pro – Giải pháp Quản lý Mật khẩu chạy trên nền Web Password Management for Shared and Service Accounts. PatchQuest – Giải pháp Quản lý lỗi trong toàn bộ hệ thống Patch Management Software. FacilitiesDesk – Giải pháp Quản lý Tài nguyên hệ thống Intergrated Facilities Management Software. Firewall Analyzer – Giải pháp Phân tích và Quản lý tưởng lửa Firewall Log Analysis & Reporting Tool. EventLog Analyzer – Giải pháp ghi chép & phân tích thông tin hệ thống chạy trên nền Web Host-based Security Information Management & Compliance Reporting. Desktop Central – Giải pháp quản lý Windows trên nền Web Windows Desktop Management Sofware. DeviceExpert – Giải pháp quản lý thay đổi và cấu hình Mạng chạy trên nền Web Networks Change & Configuration Management. VQManager – Công cụ giám sát Chất lượng VoIP chạy trên nền Web VoiP Quality Monitoring. WiFi Manager – Giải pháp tích hợp Quản lý và Bảo mật Wifi WLAN Management & Security. OpManager – Giải pháp giám sát đầy đủ Hệ thống Mạng chạy trên nền Web Bring Business Perspective to Network Management. OpManager MSP Edition – Giải pháp cho các ISP giám sát các Dịch vụ mình cung cấp Managed Network Services. ServiceDesk Plus – Giải pháp hoàn thiện về Quản lý Bàn trợ giúp và Quản lý Tài sản chạy trên nền Web IT Help Desk & Asset Management Software. ServiceDesk Plus Enterprise Edition – Giải pháp sẵn sàng với ITIL cho Bàn trợ giúp và Quản lý tài sản The tool that understands ITIL. OpUtils – Bộ công cụ giám sát Mạng và Hệ thống chạy trên nền Web System & Network Monitoring Toolset. Security Manager Plus – Giải pháp quét bảo mật trên Mạng. Network Vulnerability Scanner with Patch Management. ADSelfService Plus – Giải pháp bảo mật cho Bàn trợ giúp chạy trên nền Web. Self Reset Password. Self Unlock Account Self Directory Update. ADManager Plus – Giải pháp quản lý Active Directory chuyên sâu chạy trên nền Web Windows Active Directory Management. AssetExplorer – Giải pháp quản lý Tài sản chuyên sâu trên nền Web Asset Management Software. SupportCenter Plus – Giải pháp về Hỗ trợ và Dịch vụ khách hàng chạy trên nền Web Customer Service and Support. NetFlow Analyzer – Công cụ giám sát Băng thông chạy trên nền Web Simplified Bandwidth Monitoring. NetFlow Analyzer Enterprise Edition – Giải pháp nhằm tối ưu hóa Hệ thống một cách tốt nhất When it comes to network troubleshooting. Applications Manager – Giải pháp giám sát Máy chủ ứng dụng và Cơ sở dữ liệu Intergrated Applications Server and Database Monitoring Software. OpStor – Công cụ Giám sát và Quản lý Cơ sở hạ tầng đa Nhà cung cấp và đa Thiết bị Multi-vendor Storage Infrastructure Monitoring. Tổng quan về các tính năng cơ bản: Manage Engine Opmanager 9.0 là gì? ManageEngine OpManager là giải pháp giám sát đầy đủ Hệ thống Mạng chạy trên nền Web, cung cấp cái nhìn chuyên sâu về các lỗi và hiệu suất trong toàn bộ hệ thống LAN/WAN, các máy chủ và các ứng dụng. Bằng cách cung cấp một cái nhìn đầu đủ và tập trung về dịch vụ CNTT, OpManager giúp Bạn một cách tiếp cận chủ động để quản lý hệ thống mạng. OpManager mang lại một tập hợp chức năng quan trọng chỉ có trong các giải pháp đắt tiền, đáp ứng yêu cầu kinh doanh khắt khe và liên tục hiện nay với mức giá thành hợp lý và dễ sử dụng hơn. Hình 2.2. Hệ thống mạng chạy trên nền Web Các tính năng chính: Quản trị Hệ thống Mạng với cái nhìn đầy đủ về tính sẵn sàng, hiệu suất và giám sát Lỗi. Quản lý Trung tâm Dữ liệu bằng công cụ giám sát Máy chủ, Exchange, Cơ sở Dữ liệu, Active Directory, UPS Quản lý chung về hệ thống CNTT như giám sát địa chỉ URL, bộ nhớ CPU, thống kê sử dụng đĩa cứng, giám sát các dịch vụ hay ứng dụng và EventLogs, Cung cấp Bảng Đồng hồ Tổng hợp và nhiều mức độ xem dữ liệu theo yêu cầu Kinh doanh Quản lý SLA và kiểm soát các dịch vụ cụ thể theo thời gian thực về thông tin tính sẵn sàng. Tăng cường khả năng tự dò tìm bằng sự kết hợp NMAP, WMI, SNMP và CLI. Chỉ một lần cấu hình được định nghĩa trước bởi Mẫu Thiết bị. Đơn giản hoá quản lý các giao diện bằng các báo cáo chuyên sâu hay xem tổng quát. Đơn giản hoá quản lý các giao diện bằng các báo cáo chuyên sâu hay xem tổng quát. Các phiên bản: Professional: Phiên bản cơ bản không bao gồm các phần Add-ons. Premium: Phiên bản đầy đủ với mọi tính năng của Professional cùng Giám sát Active Directory, Exchange, MS SQL và Bộ công cụ Nhắn tin SMS. Trang thông tin chi tiết : www.opmanager.com Trang giới thiệu : Email hỗ trợ : support@opmanager.com CHƯƠNG 3: TRIỂN KHAI THỰC NGHIỆM ỨNG DỤNG Hướng dẫn sử dụng phần mềm. Demo: Cài đặt: ManageEngine OpManager 8 là phần mềm quản lý mạng thương mại nên chúng ta phải mua bản quyền sử dụng tại tảng chủ của công ty AdventNet hoặc có download và sử dụng trong 30 ngày tại. Trang chủ của ManageEngine OpManager 9.0 Tiến hành cài đặt: Hình 3.1. Bắt đầu tiến trình cài đặt Hình 3.2. Đồng ý thỏa thuận bản quyền Sử dụng phiên bản ManageEngnie OpManager 9.0. Hình 3.3. Lựa chọn phiên bản phần mềm Sử dụng phiên bản miễn phí sẽ giới hạn 10 thiết bị. Trong đồ án này, sử dụng phiên bản dùng thử 30 ngày. Hình 3.4. Lựa chọn ngôn ngữ sử dụng Thông dụng nhất là: English. Hình 3.5. Lựa chọn nơi lưu trữ cài đặt Hình 3.6. Cài đặt như một dịch vụ Hình 3.7. Chọn nơi hiển thị Hình 3.8. Tùy chỉnh Port hiển thị ở Web Server Hình 3.9. Điền thông tin chi tiết vào bảng Đăng ký hỗ trợ. Hình 3.10. Hiển thị lại những tùy chọn đã chỉnh. Hình 3.11. Tiến trình cài đặt bắt đầu Hình 3.12. Lựa chọn chế độ Server ManageEngine OpManager 9.0 sử dụng giao diện Web để quản lý. Trong khi cài đặt chúng ta cần lưu ý một vài đặt điểm như sau : Lựa chọn chế độ Server: Standalone or Primary Server (Server chính) hoặc Stanby Server (Server dự phòng). Hình 3.13. Chọn cơ sở dữ liệu tương ứng Hình 3.14. Kết thúc tiến trình cài đặt Demo: Sử dụng giao diện - Thiết lập các thông số cơ bản: Sau khi cài đặt phần mềm hoàn tất. Ta kích hoạt phần mềm, phần mềm OpManager là phần mềm chạy trên trình duyệt web. Để chạy được trên trình duyệt web thì trình duyệt web phải tương thích với OpManager. Để vào trong chương trình quản lý ban đầu ta sử dụng tài khoản mặc định của nhà sản xuất là admin sau đó ta có thể đổi và tốt nhất nên đổi mật khẩu hoặc thay mới tài khoản này để tăng tính bảo mật cho hệ thống. Hình 3.15. Giao diện đăng nhập Trang truy cập đến ManageEngine OpManager 8 là địa chỉ IP máy chủ và port tùy chỉnh là 8081 ( ) User Name và Password mặc định là admin Hình 3.16. Xác nhận quản lý. Hình 3.17. Hướng dẫn cấu hình ban đầu Hình 3.18. Quản lý kiểu chứng nhận Chọn kiểu chứng nhận là: SNMP v1/v2, Tên: HTV (Tên Nhóm), Cổng 161. Hình 3.19. Chọn tất cả loại dịch vụ cần thiết. Dịch vụ chính là SMTP (Simple Mail Transfer Protocol). Hình 3.20. Lựa chọn cấu hình dãy địa chỉ IP. Dãy IP lựa chọn là 192.168.1.1 à 192.168.1.254. Hình 3.21. Tìm kiếm các thiết bị có IP nằm trong dãy IP đã cho. Hình 3.22. Hiển thị các thiết bị đã tìm thấy. Hình 3.23. Các thiết bị đã thêm vào thành công. Quản lý hệ thống mạng: Phần mềm ManageEngine OpManager 9.0 Giới thiệu các tính năng chính trong ManageEngine OpManager 9.0: Tab Home: Hình 3.24. Tab Home (Trang Chủ) Tab Network: Hình 3.25. Tab Network (Mạng) Tab Server: Hình 3.26. Tab Server (Máy chủ) Tab Virtualization: Hình 3.27. Tab Virtualization (Ảo hóa) Tab Alarms: Hình 3.28. Tab Alarms (Báo động) Chức năng hiển thị các cảnh báo liên quan đến các thiết bị trong mạng Tab Maps: Hình 3.29. Tab Maps (Bản đồ) Chức năng hiển thị giám sát các thiết bị, tạo và hiển thị sơ đồ mạng, đây là tab chính giúp người quản trị theo dõi thông tin cụ thể của mạng Tab Workflows: Hình 3.30. Tab Workflows (Quy trình công việc) Tab Admin: Hình 3.31. Tab Admin (Quản Trị) Chức năng là tab thiết lập và quản lý toàn bộ những tính năng trong OpManager 8 với các mục chính như sau : + Discovery : Khám phá mạng mới, thêm thiết bị vào mạng, quản lý các dịch vụ được giám sát, quản lý các thư viện + Configuration : Cấu hình mở rộng các thiết bị + Monitoring : Cấu hình giám sát, theo dõi hệ thống mạng + Alerts : Cấu hình cho các cảnh báo trong mạng, các thông tin cảnh báo được gởi đến người quản trị + Tools : Quản lý các ad-on mở rộng để hỗ trợ quản lý và giám sát Tab Reports: Hình 3.32. Tab Report (Báo cáo) Chức năng hiển thị các Reports của hệ thống giúp người quản trị tìm được nguyên nhân khi có sự cố xảy ra Thiết lập nâng cao trong ManageEngine OpManager 9.0: Thêm, xóa, chỉnh sửa một Credential: Thêm một Credential: ManageEngine OpManager 9.0 sử dụng giao thức SNMP v1/2 để giám sát các thiết bị trong mạng. Một vào thông số như Credential Type, SNMP Community, Port, Timeout, Retries,… có thể khác nhau giữa các thiết bị. Vì vậy ta nên cấu hình Credential để lưu các thông tin này giúp cho OpManager dễ dàng thêm các thiết bị vào mạng Ta vào Tab Admin chọn mục Discovery, chọn Credential Settings sau đó tiến hành thiết lập các thông số như: tên Credential, Giao thức, chế độ, cổng dịch vụ, SNMP TimeOut, SNMP Retries. Hình 3.33. Tab Admin – Credential Settings. Click chọn Credential Settings. Hình 3.34. New Credential. Vào Actions à New Credential để thêm một Credential mới. Hình 3.35. Thiết lập Credential Điền đầy đủ thông tin trong bảng Add Credential. Bấm nút Add để thêm thông tin vừa điền để tạo thêm Credential. Khám phá các thiết bị mới trong mạng: Hình 3.36. Discover (Khám phá các thiết bị trong mạng). Chúng ta vào mục Admin ở mục Discovery chọn Discover Device nhập các thông số IP Subnet của mạng, chọn Credentials rồi bấm Discover. Hình 3.37. Tiến trình Discover các thiết bị. Hình 3.38. Import Devices. Xuất các thiết bị để quản lý nó. Thêm một thiết bị vào mạng: Để thêm một Thiết bị (Devices), chúng ta vào Tab Admin à Add Devices. Hình 3.39. Thêm 01 thiết bị vào mạng. Điền địa chỉ IP hoặc tên thiết bị muốn thêm vào ô Device Name/IP Address, Netmask (Mặc định). Nhấn Add Device để thêm Thiết bị. KẾT LUẬN & ĐỊNH HƯỚNG PHÁT TRIỂN Kết luận: Sau một thời gian thực hiện, nhóm đã hoàn thành đồ án và đạt được một số kết quả nhất định. Trong đồ án này, chúng tôi đã trình bày những kiến thức cơ bản về an ninh trong kiến trúc quản trị mạng SNMP. Đồ án tập trung chủ yếu vào vấn đề: Tổng quan về quản trị và an ninh thông tin trên Internet, nghiên cứu giải pháp an ninh trong kiến trúc mạng SNMP. Kết quả đạt được: Về lý thuyết: Nhóm đã tìm hiểu được tổng quan về giao thức giám sát mạng SNMP. các phương thức giám sát mạng. Ưu nhược điểm trong thiết kế của SNMP. Tìm hiểu lý thuyết về phần mềm quản trị mạng OpManager. Về thực hành: Triển khai hệ thống giám sát và quản trị mạng với OpManager trên mô hình giả lập, thực hiện một số tiện ích giám sát và quản trị mạng cơ bản. Hướng phát triển: Hoàn thành luận văn với kết quả đạt được tương đối theo yêu cầu của đề tài đưa ra. Tuy nhiên trong quá trình thực hiện đề tài, em nhận thấy vẫn còn nhiều vấn đề liên quan cần được tìm hiểu nghiên cứu. Em xin đưa ra một số vấn đề cần tìm hiểu và nghiên cứu phát triển đề tài như sau: + Dựa vào kết quả nghiên cứu trên có thể xây dựng phần mềm quản trị hệ thống mạng thông qua giao thức SNMP. + Kết hợp với việc nghiên cứu một số giải pháp an ninh cả về phần cứng và phần mềm khác để có thể xây dựng một hệ thống mạng với an toàn về dữ liệu và an ninh cao. TÀI LIỆU THAM KHẢO [1] Computer Security Art And Science, By Matt Bishop, Publisher: Addition Wesley, 2002 [2] Essential SNMP, 2nd Edition, By Douglas Mauro, Kevin Schmidt, Publisher: O'Reilly, Pub Date: September 2005 [2] How to Configure SNMP Community Strings of Cisco [3] SNMP Toàn tập Diệp Thanh Nguyên [4] Nghiên cứu & triển khai hệ thống mạng ManageEngine OpManager 8 – Nguyễn Học – Nguyễn Thanh Tâm Khóa 03 – 03/2012. [5] Tìm Hiểu Giao Thức SNMP & triển khai quản trị mạng với phần mềm ManageEngine OpManager 8 - Võ Quốc Hảo - Huỳnh Thanh Cảnh - Nguyễn Phước Cẩm – Khóa 2 – 04/2011. [6] [7]