Gerenciamento de Redes IP com o Protocolo SNMPv3

Transcrição

1 Série Especial de Tutoriais Gerenciamento de Redes IP com o Protocolo SNMPv3 Esta Série Especial de Tutoriais apresenta os trabalhos premiados no II Concurso Teleco de Trabalhos de Conclusão de Curso (TCC) O conteúdo deste tutorial foi obtido do artigo classificado em terceiro lugar no concurso, de autoria de Marcelo Borges dos Santos, Lucélia Rocha da Silva e Kênia Queiroz Martins Ferreira Machado. O objetivo do tutorial é apresentar um estudo sobre o gerenciamento de redes de computadores com a arquitetura TCP/IP, através do uso do protocolo SNMPv3, versão essa que possui características de segurança, tais como autenticação e privacidade, tão necessárias e exigidas no gerenciamento remoto de redes. O tutorial apresenta também um estudo de caso prático de comparação entre as versões 2 e 3 do protocolo SNMP, com a finalidade de analisar o grau de segurança obtido com a versão 3, e procura focar também no estudo prático da estrutura das mensagens SNMP. Marcelo Borges dos Santos É graduado em Redes de Comunicação pelo Centro Federal de Educação Tecnológica (Goiás, 2006). Tem também formação como Técnico Industrial em Eletrônica pelo Centro Federal de Educação Tecnológica (Goiás, 2002). Atuou como Técnico em Eletrônica Trainee na Itautec.com Serviços, executando atividades de suporte técnico, manutenção e configuração de equipamentos e redes de automação bancária, e como Técnico Trainee na Scopus Tecnologia, executando atividades de suporte técnico, manutenção e configuração de equipamentos e redes de automação bancária e de sistemas de telecomunicações. Atualmente trabalha como Técnico Industrial na CELG - Companhia Energética de Goiás, sendo o Auditor Líder do Sistema de Gestão da Qualidade (SGQ) e Consultor das áreas envolvidas no SGQ, e auxiliando na elaboração dos relatórios de Qualidade e Produtividade segundo os critérios da Fundação Nacional da Qualidade (FNQ). Já desenvolveu diversas atividades nas áreas de Telecomunicações, Informática e Eletrônica, e atualmente tem se dedicado à área de Certificação de Sistemas de Informação, com base nos critérios da norma NBR ISO 27001: marcelo_elt@yahoo.com.br 1

2 Lucélia Rocha da Silva É graduada como Tecnóloga em Redes de Comunicação pelo Centro Federal de Educação Tecnológica (Goiás, 2006). Tem também formação como Técnica em Eletrônica pelo Centro Federal de Educação Tecnológica (Goiás, 1998). Atuou como Estagiária Técnica em Eletrônica no Centro Federal de Educação Tecnológica (Goiânia, Goiás), executando atividades de controle e manutenção preventiva de equipamentos do Laboratório de Eletrônica e Telecomunicações, e como Estagiária Técnica em Eletrônica no Tribunal Regional Eleitoral de Goiás, executando atividades de instalação, configuração, identificação e manutenção de falhas em equipamento e softwares de comunicação de dados. Atualmente trabalha como Instrutora de Treinamentos Corporativos na Empresa Brasileira de Correios e Telégrafos, sendo a gestora do site de Educação Corporativa na Intranet, e participando dos projetos de treinamento de sistemas de informação da empresa, entre outros. rocha.lucelia@gmail.com 2

3 Kênia Queiroz Martins Ferreira Machado É graduada como Tecnóloga em Redes de Comunicação pelo Centro Federal de Educação Tecnológica (Goiás, 2006). Tem também formação como Técnica em Eletrônica pelo Centro Federal de Educação Tecnológica (Goiás, 1998). Atuou como Estagiária Técnica em Eletrônica no Centro Federal de Educação Tecnológica (Goiânia, Goiás), executando atividades de controle e manutenção preventiva de equipamentos do Laboratório de Eletrônica e Telecomunicações, e como Estagiária Técnica em Eletrônica no Tribunal Regional Eleitoral de Goiás, executando atividades de instalação, configuração, identificação e manutenção de falhas em equipamento e softwares de comunicação de dados. Atualmente trabalha como Instrutora de Treinamentos Corporativos na Empresa Brasileira de Correios e Telégrafos, sendo a gestora do site de Educação Corporativa na Intranet, e participando dos projetos de treinamento de sistemas de informação da empresa, entre outros. machadoluke@yahoo.com.br Duração estimada: 20 minutos Publicado em: 18/06/

4 SNMPv3: Introdução Depois de discussões sobre simplicidade e segurança do protocolo SNMP (Protocolo Simples de Gerenciamento de Redes), foi publicada a versão 2 deste protocolo (SNMPv2) como baseada em comunidade, e sem nenhuma melhoria de segurança. Logo em seguida foi proposta a versão 3 (SNMPv3) para agregar os requisitos de segurança ao gerenciamento de redes. Junto a essa característica, o SNMPv3 também possibilita desenvolvimentos futuros, com um mínimo de impacto para as especificações já existentes. Assim, uma das características chaves do SNMPv3 é a composição modular de seus documentos e arquitetura. A arquitetura integra as especificações das versões anteriores do protocolo SNMP com as desenvolvidas para nova versão. Essa integração proporciona que entidades SNMP já em uso implementem as características do SNMPv3 (STALLINGS, 1999, p. 450), considerando: O uso do trabalho existente, para o qual há uma experiência de implementação e consensos sobre sua utilização; O uso de endereçamento seguro de mensagens de requisição, que é a maior deficiência do SNMPv1 e SNMPv2; O desenho de uma arquitetura modular que permita a implementação sobre uma extensa gama de ambientes operacionais, tanto os que exigem poucos recursos e funcionalidades baratas, como os que possam suportar características adicionais para uma grande administração de redes. A composição modular possibilita, ainda, a modificação de partes da arquitetura e acomodação de modelos de segurança alternativos; A manutenção do SNMP o mais simples possível. Nesse sentido, este tutorial descreve um estudo da versão 3 do protocolo SNMP (SNMPv3), fornecendo assim um material didático para pesquisas e desenvolvimento de trabalhos relacionados ao assunto. O estudo é importante visto que o protocolo SNMPv3 possui características de segurança, tais como autenticação e privacidade, tão necessárias e exigidas no gerenciamento remoto de uma rede. Este trabalho apresenta a implementação de tal protocolo em uma pequena rede com a finalidade de gerar tráfego de informações de gerenciamento em suas versões 2 e 3 (SNMPv2 e SNMPv3). Assim, com um analisador de tráfego, foi possível coletar, analisar e estabelecer um comparativo entre essas versões, no que se refere à utilização dos recursos da rede. Outro fim desse analisador de tráfego é demonstrar, em uma abordagem mais didática, o estudo da estrutura das mensagens SNMP. 4

5 SNMPv3: Metodologia Composição da Rede Inicialmente foi configurada uma pequena rede de computadores composta de três máquinas. Essas máquinas têm um papel bem definido no layout da rede, sendo que, uma delas foi usada como gerente da comunicação SNMP, uma outra usada como agente dessa comunicação e a terceira máquina representa o analisador de tráfego (sniffer). A disposição da rede ficou como apresentado na figura 1, que mostra um hub interligando, em um mesmo domínio de colisão, os três computadores utilizados nessa experiência. Também interligado ao hub existe uma rede externa ao laboratório, que permite o acesso à Internet. Essa rede externa está representada pela nuvem da figura. Figura 1: Layout da rede do laboratório. O Sistema Operacional (SO) utilizado nas máquinas diretamente envolvidas com a troca de informações de gerenciamento (a máquina Gerente SNMP e a máquina Agente SNMP) foi o Linux em sua distribuição Red Hat, versão 8.0. Já o SO utilizado na máquina que fez o papel de Sniffer foi o Microsoft Windows XP. Não houve nenhuma motivação científica para a utilização de um sistema operacional da Microsoft na máquina Sniffer. Entretanto, imaginou-se que o ambiente do Windows XP poderia fornecer uma interface gráfica mais amigável ao se fazer a coleta dos pacotes que trafegariam pela rede. O endereço IP das máquinas envolvidas na experiência foi definido através do servidor DHCP da rede interna ao CEFET-GO (que se encontra em algum lugar na nuvem da Figura 1). Esses endereços IP encontram-se facilmente visíveis nos textos que acompanham cada uma das máquinas vistas na figura. 5

6 Criação dos Usuários e da Comunidade Para executar os comandos de gerenciamento SNMP desta pequena rede foram criados e configurados três usuários, na versão 3, e criada uma comunidade, na versão 2. É importante citar que cada um dos usuários, que foram criados para a comunicação com o protocolo SNMPv3, tinha um nível de segurança diferente. Dessa forma foi possível abranger todos os níveis de segurança possíveis para a comunicação com esse protocolo, quais sejam: Usuário que utiliza Autenticação e Privacidade para a comunicação priv; Usuário que utiliza apenas Autenticação para a comunicação auth; Usuário que não utiliza nem Autenticação e nem Privacidade para a comunicação noauth. Já a criação da comunidade para comunicação com o protocolo SNMPv2 continha apenas uma variável de segurança a ser considerada (que é o próprio nome da comunidade). Portanto, criou-se apenas uma comunidade para comunicação com esse protocolo. Coleta dos Dados Depois da criação de usuários e comunidade, iniciou-se a captura (ou coleta) dos dados que trafegariam pela rede do laboratório, cuja topologia está representada na figura 1. Como o interesse é capturar apenas os pacotes que contém o protocolo SNMP, a rede externa ao laboratório (representada pela nuvem da figura já mencionada) foi retirada, mantendo-se apenas a rede interna ao laboratório. Tanto os usuários SNMPv3 quanto a comunidade SNMPv2 foram criados no computador que figurava como Agente da comunicação. Para todos os casos abordados a seguir, serão solicitadas informações a objetos de MIB contidos nesse agente. Para haver uniformidade na coleta de dados para os diferentes usuários e a comunidade, definiu-se que os objetos, foco dessa análise, estarão concentrados na MIB II do protocolo SNMP e serão sempre os mesmos. Dessa forma, baseados na importância relativa das informações e também no uso prático dessas, para as coletas descritas a seguir, foram selecionados, da MIB II, objetos dos grupos: IP, TCP e System. A escolha de diferentes grupos de objetos se justifica pela necessidade de aumentar a confiabilidade das conclusões que poderão ser tiradas a partir da análise dos dados coletados, comprovando que as tendências relativas a essa análise não refletem o resultado de um grupo que possa ter um possível comportamento anômalo dentro da comunicação SNMP. 6

7 A Figura 2 mostra uma representação dos grupos de objetos contidos na MIB II do agente SNMP que serão alvo de gerenciamento. Figura 2: Agente SNMP contendo os grupos da MIB II que serão gerenciados. Os três usuários SNMPv3 foram criados com permissão de leitura e escrita, abrangendo as três possibilidades de segurança que dispõe esse protocolo, a saber: Usuário zeus (priv) comunicação com autenticação e privacidade; Usuário netuno (auth) comunicação apenas com autenticação; Usuário hades (noauth) comunicação sem autenticação e sem privacidade. Para a comunicação com protocolo SNMPv2, criou-se a comunidade olimpo, que não dispõe de maiores parâmetros de segurança. Definiu-se uma rotina para a captura dos pacotes que iriam trafegar pela rede. Todas as coletas seriam realizadas no período de um dia, totalizando três coletas, uma para cada turno do dia. Para tanto, foi utilizado um sniffer (representado na Figura 1) para coletar o tráfego da rede quando houvesse a utilização do protocolo SNMP. O software utilizado para a função de sniffer foi o aplicativo Ethereal. Para gerar esse tráfego com o protocolo SNMP, foram utilizadas as operações do tipo get disponíveis no pacote Net-SNMP, que contém ferramentas para consultar agentes SNMP. Uma operação de get possibilita a recuperação de informações de gerenciamento contidas nos dispositivos gerenciados. Essa operação pode ser realizada através de uma interface de linha de comando, disponível para as operações do SNMP. Dessa forma, o comando utilizado para obter as informações de gerenciamento contidas no agente SNMP foi o snmpwalk. Esse comando tem a função de executar uma operação de get para cada objeto contido dentro de um determinado grupo de objetos gerenciados. 7

8 A fim de fazer uma demonstração mais didática, segue abaixo a descrição dos comandos de gerenciamento SNMP realizado para cada um dos casos: Comunidade olimpo: [root@serv1 root]# snmpwalk v 2c c olimpo IP Usuário hades: [root@serv1 root]# snmpwalk v 3 l noauthnopriv u hades IP Usuário netuno: [root@serv1 root]# snmpwalk v 3 l authnopriv u netuno A deusdosmares IP Usuário zeus: [root@serv1 root]# snmpwalk v 3 l authpriv u zeus A deusdotrovão X reidosdeuses IP Esses comandos podem ser entendidos com o uso da legenda apresentada a seguir: snmpwalk possibilita a varredura de todos os objetos de um grupo de MIB; -v Versão representa a versão do protocolo SNMP (Versão deverá ser substituída por 2c ou 3); -c olimpo refere-se à comunidade em que se buscam os dados gerenciados; -l Nível_Segurança refere-se ao nível de segurança do usuário (Nível_Segurança poderá ser noauthnopriv sem autenticação nem privacidade, authnopriv com autenticação e sem privacidade ou authpriv com autenticação e com privacidade); -u Usuário identifica o usuário SNMPv3 (Usuário deverá ser substituído por hades, netuno ou zeus); -A Chave_Autenticação representando a senha que será utilizada como chave de autenticação; -X reidosdeuses representando a senha que será utilizada como chave de privacidade; endereço IP do agente que está sendo gerenciado por esse comando; IP da MIB II que será gerenciado (é o objeto do comando snmpwalk). Os comandos acima foram mostrados apenas para o grupo IP da MIB II. Entretanto, esses mesmos comandos também foram realizados para os grupos TCP e SYSTEM, para cada um dos usuários SNMPv3, assim como para comunidade SNMPv2. Tais comandos e capturas de pacotes pelo Ethereal foram realizados por três vezes ao longo do dia, como dito anteriormente. Essas capturas foram gravadas em arquivos para análises e separadas de forma a identificá-las em arquivos, possibilitando a organização dos dados conforme mostra a figura

9 Figura 3: Arquivos das coletas realizadas pelo Sniffer. Sendo assim, as três capturas realizadas para cada um dos usuários e para a comunidade SNMP ficaram gravadas de forma inequívoca, identificadas através dos nomes de arquivo. Em cada um desses arquivos é possível visualizar, utilizando o aplicativo Ethereal, as informações de gerenciamento realizadas entre o Gerente e o Agente da comunicação SNMP. A figura 4 mostra o resultado da captura dos dados que trafegavam pela rede ao se executar as funções de gerenciamento com destaque para o campo de informações do protocolo SNMP. Figura 4: Destaque do campo de informação SNMPv3 do pacote coletado pelo Ethereal. 9

10 SNMPv3: Resultados e Discussões A partir de toda a coleta de dados realizada pelo sniffer, representado na Figura 1, foi possível submeter a comunicação com o protocolo SNMP a uma análise mais detalhada no que diz respeito a sua utilização de recursos da rede e ao conteúdo de seus pacotes. Cada arquivo referenciado na Figura 3 possui as informações de gerenciamento dos três grupos de objetos gerenciáveis que estão sendo foco desse trabalho (grupos IP, TCP e System). Dessa forma, a partir desses arquivos, foi possível relacionar a quantidade total de bytes contida em cada um dos pacotes que trafegavam pela rede. Essa quantificação possibilitou mensurar, para cada usuário SNMPv3 e para a comunidade SNMPv2, uma relação entre o pacote SNMP que foi coletado e a quantidade de bytes de informação que ele continha. Para demonstrar essa relação, foram esboçados gráficos cujos eixos das abscissas representam o número do pacote coletado e os eixos das ordenadas representam a quantidade de bytes contida em cada pacote. Dessa forma, a figura 5 representa os gráficos do tipo: número do pacote coletado X quantidade de bytes do pacote. Além disso, para que o gráfico não se prolongasse indefinidamente no eixo das abscissas, foram selecionados os vinte primeiros pacotes de cada um dos grupos de objetos gerenciáveis. Sendo assim, os gráficos relacionados na figura 5 demonstram a quantidade de bytes contidos até o vigésimo pacote coletado da rede, para cada grupo. Figura 5: Quantidade de bytes por pacote coletado dos usuários/comunidade SNMP. 10

11 Cada gráfico confeccionado, por usuário/comunidade SNMP, apresenta os três grupos de objetos gerenciáveis: IP, TCP e System. Como a coleta de dados era realizada por três vezes para cada usuário/comunidade SNMP, os valores referentes a quantidade de bytes que estão demonstrados nos gráficos representam uma média aritmética simples entre essas três coletas, visto que foram verificadas alterações de, no máximo, 2 bytes em tais coletas. Em termos percentuais, isso representa uma alteração de, aproximadamente, 1%. Os dados coletados que geraram cada um desses gráficos podem ser vistos na Tabela 1 (A e B). Essa tabela demonstra o valor médio (em bytes) de cada pacote coletado no gerenciamento SNMP. Os gráficos que representam os pacotes coletados no gerenciamento dos usuários zeus, netuno e hades, do protocolo SNMPv3, mostram um crescimento abrupto na quantidade de bytes do primeiro para o segundo pacote coletado. Esse crescimento se justifica em função do primeiro pacote ainda não conter as informações referentes ao usuário que será gerenciado, ou seja, ainda não contém os valores dos campos de identificação do usuário, como os campos referentes ao EngineID, ao EngineBoots e ao EngineTime (SUBRAMANIAN, 2000, p. 308). Esses campos agregam informações de autenticação e privacidade aos usuários do SNMPv3. Dessa forma, o primeiro pacote de uma comunicação SNMPv3 acaba sendo relativamente menor que os demais devido ao processo inicial de negociação dos parâmetros de segurança da mensagem, chamado de Descoberta (STALLINGS, 1999, p. 519). 11

12 Tabela 1A: Quantidade de Bytes por Pacote e Usuário/Comunidade. Número do Pacote Usuário hades Bytes Coletados IP TCP SYSTEM Comunidade olimpo Bytes Coletados IP TCP SYSTEM 1 106,00 106,00 106,00 106,00 106,00 106, ,00 150,00 150,00 150,00 150,00 150, ,00 173,00 173,00 163,00 163,00 163, ,00 181,00 254,00 166,00 166,00 239, ,00 181,00 181,00 165,00 165,00 165, ,00 181,00 189,00 166,00 166,00 175, ,00 181,00 181,00 165,00 165,00 165, ,00 181,00 181,00 167,67 166,00 168, ,00 181,00 181,00 165,00 165,00 165, ,00 181,00 181,00 166,00 166,00 173, ,00 181,00 181,00 165,00 165,00 165, ,00 181,00 197,00 166,00 166,00 187, ,00 181,00 181,00 165,00 165,00 165, ,00 181,00 197,00 166,00 166,00 182, ,00 181,00 181,00 165,00 165,00 165, ,00 181,00 181,00 166,00 166,00 166, ,00 181,00 181,00 165,00 165,00 165, ,00 181,00 189,00 166,00 166,00 174, ,00 181,00 181,00 165,00 165,00 167, ,00 181,00 189,00 167,67 166,00 174,00 Totais 3.506, , , , , , , ,

13 Tabela 1B: Quantidade de Bytes por Pacote e Usuário/Comunidade. Número do Pacote Usuário hades Bytes Coletados IP TCP SYSTEM Comunidade olimpo Bytes Coletados IP TCP SYSTEM 1 106,00 106,00 106,00 83,00 83,00 83, ,00 150,00 150,00 86,00 86,00 158, ,00 150,00 150,00 85,00 85,00 85, ,00 153,00 226,00 86,00 86,00 94, ,00 152,00 152,00 85,00 85,00 85, ,00 153,00 161,00 87,67 86,00 88, ,00 152,00 152,00 85,00 85,00 85, ,67 153,00 155,00 86,00 86,00 92, ,00 152,00 152,00 85,00 85,00 85, ,00 153,00 159,00 86,00 86,00 106, ,00 152,00 152,00 85,00 85,00 85, ,00 153,00 174,00 86,00 86,00 101, ,00 152,00 152,00 85,00 85,00 85, ,00 153,00 168,00 86,00 86,00 86, ,00 152,00 152,00 85,00 85,00 85, ,00 153,00 153,00 86,00 86,00 93, ,00 152,00 152,00 85,00 85,00 87, ,00 153,00 160,00 87,67 86,00 93, ,00 152,00 154,00 85,00 85,00 87, ,67 153,00 160,00 87,33 87,33 93,00 Totais 3.002, , , , , , , ,00 Um dos pacotes iniciais do grupo System, em todos os gráficos, mostra uma quantidade de bytes bem superior em relação aos demais pacotes coletados. Isso ocorre em função desse pacote específico fornecer uma grande quantidade de informações de uma única vez. Mas nota-se, pela disposição dos demais pacotes de cada um dos gráficos, que esse comportamento não volta a ocorrer para esse intervalo de coleta. 13

14 Fazendo uma análise dos gráficos relacionados nesta figura, é possível notar que a quantidade média de bytes utilizados para o gerenciamento SNMP com a comunidade olimpo (que é uma comunidade SNMPv2) é bem inferior à quantidade média de bytes utilizados para o gerenciamento com os demais usuários, que utilizam a versão 3 do protocolo SNMP (SNMPv3). Isso ocorre em função do protocolo SNMPv2 não utilizar informações referentes à autenticação e privacidade utilizadas pelo protocolo SNMPv3. Em função dessa comparação, foi possível traçar uma relação sobre o teor das informações contidas nos pacotes responsáveis pelo gerenciamento SNMP. Para tanto, foi necessário dividir, de forma conceitual, o conteúdo de cada pacote coletado na rede em três informações distintas. Sendo a Figura 6 a representação de um pacote (ou frame) coletado da rede durante o gerenciamento SNMP, é possível distinguir as informações contidas nesse pacote através das cores que o compõe. Figura 6: Campos de um pacote completo de gerenciamento SNMP. Na figura 6, fica claro a representação do conteúdo de um pacote que trafega pela rede que é objeto de estudo desse trabalho. A Parte I (azul) da figura representa a pilha de protocolos TCP/IP, responsável por transportar as informações contidas nas camadas superiores. O papel de camada superior está representado aqui pelo protocolo SNMP, que na figura é mostrado na Parte II (verde). Este, por sua vez, deve transportar as informações de gerenciamento propriamente ditas, ou seja, as informações que serão úteis à tomada de decisão. Estas informações úteis são representadas na Parte III (amarela) da figura. Com base nessa divisão conceitual das informações contidas nos pacotes que trafegam pela rede e levando em consideração os pacotes coletados e representados pelos gráficos da Figura 5, foi possível relacionar, para cada usuário/comunidade SNMP, em que proporção, em média, cada uma das informações mencionadas acima ocupa nos pacotes. Dessa forma, foi necessário excluir dessa relação os pacotes que se mostram com um comportamento bruscamente diferenciado dos demais e que, portanto, alteram de forma indevida os valores médios contidos no intervalo representado pelos gráficos da Figura 5. Para tanto, utilizou-se um conceito matemático definido como Distribuição Normal com três desvios padrões (ESTATÍSTICA, 2006, p. 11). O resultado desse conteúdo médio de informações, já segmentadas, do pacote SNMP para cada um dos usuários/comunidade pode ser visto na Figura 7. A partir da Figura 7, pode-se perceber um crescimento na quantidade média de bytes por pacote na medida em que aumentam os requisitos de segurança de cada usuário a ser gerenciado. Então, fica fácil perceber que esse aumento ocorre em função da necessidade que o pacote tem em transportar um maior número de informações de segurança. 14

15 De forma clara, vê-se que a quantidade média de informações contidas na parte do pacote relacionada à pilha de protocolos TCP/IP mantêm-se constante. A maior variação realmente ocorre no próprio corpo do protocolo SNMP, representado pela cor verde, que agrega mais informações na medida em que aumentam os critérios de segurança. Figura 7: Média do conteúdo dos pacotes (segmentados conforme a figura 6). Também é possível notar uma variação na quantidade média de bytes contidos no campo da PDU SNMP, plenamente justificável ao se comparar com a estrutura do pacote SNMP. Na medida em que se confirma que os campos contextengineid e contextname (que são identificadores dos objetos a serem gerenciados) também entram no conteúdo da PDU SNMP, para a versão 3, admite-se que um aumento nos requisitos de segurança irá agregar informações a este campo e, conseqüentemente, aumentar a quantidade de bytes que o compõe. 15

16 SNMPv3: Considerações Finais A estrutura modular do protocolo SNMPv3 permite implementar, se for desejado, apenas algumas de suas partes constituintes, reduzindo custo humano, material de estudo e testes preliminares, já que é possível trabalhar especificamente com o módulo que é de interesse. Assim, se o objetivo é prover segurança no tráfego, pode-se configurar e testar o Modelo de Segurança baseado no Usuário USM (RFC 3414, 2002, p ), que é o modelo disponível até o momento para prover essa característica. Já se o interesse é o controle de acesso, pode-se trabalhar com o Modelo de Acesso baseado na Visão VACM (RFC 3415, 2002, p ) ou qualquer outro modelo que venha a se tornar disponível para esse fim. Essa característica se torna particularmente interessante na medida em que se possui uma rede de comunicação com elementos que demandam diferentes níveis de segurança em seu gerenciamento. Outra vantagem da composição modular remete a sua abertura em usar comandos e características de distintas versões de um mesmo protocolo. Nesse sentido, se uma rede não possui elementos que tenham condições de suportar comandos SNMPv3, ainda vale possuir Gerentes que suportem essa versão do protocolo, já que é possível haver interação entre as diferentes versões do SNMP. Dessa forma, caso torne-se necessário, por qualquer motivo, melhorar as características de gerenciamento dos elementos da rede, não será preciso preocupar-se com o impacto na mudança de versão do protocolo de gerenciamento, já que serão necessários apenas alguns ajustes, que variam conforme o módulo que será implantado. Sendo assim, quando se fala dos entraves de tornar novos equipamentos e softwares compatíveis com o restante da rede, o SNMPv3 se mostra uma alternativa no que se refere ao gerenciamento. No que tange a necessidade de recursos da rede, outras informações interessantes foram demonstradas com o protocolo SNMP: Os pacotes da versão 2 transportam uma mesma quantidade de informações de gerenciamento utilizando uma quantidade de bytes muito inferior à quantidade de bytes utilizados pelos pacotes da versão 3; Os pacotes da versão 3 em sua forma menos segura (sem autenticação e sem privacidade) são pouco menores (em bytes) que os pacotes da versão 3 em sua forma mais segura (com autenticação e com privacidade). Desse resultado obtém-se duas conclusões complementares: Se a segurança da informação não for essencial, é mais interessante optar pela versão 2, pois a versão 3 sem autenticação e sem privacidade oferece os mesmos serviços, mas exige bem mais da rede, já que necessita de uma quantidade bem maior de bytes para transmitir a mesma informação; Se a segurança é um requisito, é melhor usar os serviços de autenticação e privacidade oferecidos pela versão 3, pois não há redução significativa da quantidade de bytes transportados na rede entre um pacote que transporta dados de autenticação de outro que transporta dados de autenticação e privacidade. Assim, se a opção for limitar os recursos de segurança, sob a justificativa de que a rede não suporta tráfego de gerenciamento seguro, vale ressaltar que para o SNMPv3 utilizar nenhum como todos os recursos de segurança é quase irrelevante do ponto de vista do aumento de bytes que circulariam nessa rede. 16

17 Finalmente, vale destacar a confrontação teórico-prática da estrutura da mensagem SNMPv3. Partindo do pressuposto que entender o funcionamento de sistemas de informação exige alguma abstração em transpor para a prática a forma de tráfego de bytes, encapsulamento de protocolos etc, comparar um pacote capturado com o modelo teórico é uma motivação para acadêmicos, professores e analistas da área de Redes de Comunicação, pois esclarece e amplia a visão sobre o assunto. A fim de aprofundar os estudos aqui abordados, é possível desenvolver algumas linhas de raciocínio que poderão influenciar a confecção de trabalhos futuros, a saber: 1. Isolar as variáveis computacionais para determinar o tempo de processamento de uma mensagem SNMPv3 com relação a uma mensagem SNMPv2. Isso poderia gerar valores precisos de taxa de ocupação da rede; 2. Realizar a coleta de dados com outros grupos de objetos gerenciáveis, além dos grupos TCP, IP e System, com a finalidade de confirmar a tendência de crescimento dos frames na medida em que os níveis de segurança aumentam; 3. Utilizar sniffers para a coleta de frames contendo o protocolo SNMP em uma rede que utiliza diferentes suítes SNMP, fazendo uma análise de performance entre eles; 4. Fazer implementação e análise abordando as características de controle de acesso definidas pelo modelo VACM, simulando diferentes níveis de permissão para conjuntos de usuários de uma mesma rede; 5. Traçar um comparativo entre o protocolo SNMPv3 e este mesmo protocolo associado à arquitetura móvel para o modelo DISMAN - Distribuição de Gestão. Nesse sentido, vale traçar o custo-benefício das propostas da arquitetura móvel DISMAN em relação às lacunas do SNMPv3 inerentes a extensibilidade, escalonabilidade, eficiência no transporte da informação, mobilidade, monitoramento centralizado etc. Referências STALLINGS, William. SNMP, SNMPV2, SNMPV3, and 1 RMON and 1 and 2. Massachusetts: Addison Wesley, SUBRAMANIAN, Mani. NETWORK MANAGEMENT, - Principles and Practice. Georgia: Addison Wesley, RFC 3411 Disponível em: ftp://ftp.rfc-editor.org/in-notes/rfc3411.txt Acessado em Junho/2006. RFC 3413 Disponível em: ftp://ftp.rfc-editor.org/in-notes/rfc3413.txt Acessado em Junho/2006. RFC 3414 Disponível em: ftp://ftp.rfc-editor.org/in-notes/rfc3414.txt Acessado em Junho/2006. RFC 3415 Disponível em: ftp://ftp.rfc-editor.org/in-notes/rfc3415.txt Acessado em Junho/2006. Estatística Distribuição Normal Disponível em: Acessado em Junho/

18 SNMPv3: Teste seu Entendimento 1. Quais foram alguns dos avanços introduzidos no protocolo SNMP versão 3? Atendimentos aos requisitos de segurança, e composição integral da arquitetura. Atendimentos aos requisitos de velocidade, e composição modular da arquitetura. Atendimentos aos requisitos de segurança, e composição linear da arquitetura. Atendimentos aos requisitos de segurança, e composição modular da arquitetura. 2. A partir dos testes apresentados, pode-se concluir que o uso da rede de gerência considerando as versões 2 e 3 teve o seguinte resultado: O número de bytes usados na versão 2 é bem menor que o número de bytes usados na versão 3 sem autenticação e privacidade, que equivale à versão 2. O número de bytes usados na versão 2 é bem maior que o número de bytes usados na versão 3 sem autenticação e privacidade, que equivale à versão 2. O número de bytes usados na versão 2 é bem maior que o número de bytes usados na versão 3 com autenticação e privacidade, que equivale à versão 2. O número de bytes usados na versão 3 é bem menor que o número de bytes usados na versão 2 sem autenticação e privacidade, que equivale à versão Por que o primeiro pacote de uma comunicação SNMPv3 é maior que os demais pacotes trocados pelos computadores da rede no teste? Devido ao processo inicial de negociação dos parâmetros de privacidade da mensagem, chamado de Privacy. Devido ao processo inicial de negociação dos parâmetros de versão da mensagem, chamado de Version. Devido ao processo inicial de negociação dos parâmetros de segurança da mensagem, chamado de Descoberta. Todas as anteriores. 18