Atividade Prática 03 Gerenciamento de Servidores GNU/Linux Utilizando SNMP v3

Transcrição

1 Atividade Prática 03 Gerenciamento de Servidores GNU/Linux Utilizando SNMP v3 A versão 3 do protocolo SNMP é focada em melhorias de segurança. Conforme visto anteriormente, na versão 3 foram adotados: USM - User-based Security Model: Modelo de Segurança Baseada em Usuários; VACM - View-based Access Control Model: Modelo de controle de acesso baseado em visões; Configuração dinâmica de agentes SNMP utilizando comandos SNMP. 1. USM Até a versão 2 do protocolo SNMP, o controle de acesso era baseado em comunidades(communities) como public, private. Este é um sistema de segurança muito frágil e limitado, pois se alguém descobre o nome da comunidade, tem acesso total ao host, ainda que ele esteja configurado apenas para leitura. Disponibilizar essas informações a uma pessoa mal intencionada é o mesmo que deixá-la visitar sua rede e realizar anotações, e posteriormente montar o plano de ataque sem pressa alguma. A partir do SNMPv3, os usuários e suas respectivas senhas devem ser cadastrados na base de dados SNMP, sendo que esses dados são salvos criptografados. 2. VACM Os usuários são colocados em grupos. São criadas views que representam partes da árvore SNMP, semelhantes às views dos bancos de dados, ou compartilhamentos de diretórios em servidores de arquivos. A view é o recurso que desejamos disponibilizar, e por fim permissões são dadas para os grupos acessarem as views. 3. Modelo de Permissões VACM Este esquema demonstra como esse processo é estruturado no arquivo de configuração (snmpd.conf):

2 Figura 1 - snmpd.conf de acordo com o Modelo VACM O primeiro passo é compartilhar os recursos, ou seja, definir as views: # view nome tipo sub-árvore máscara view demowrite included view demoread included Neste caso, estamos definindo duas views, a view demowrite e a view demoread, e estamos incluindo a informação: (.iso.org.dod.internet.private.enterprises.ucdavis.ucddemomib.ucddemomibobject s. ucddemopublic); este é o recurso que estamos disponibilizando. Fazendo uma analogia com o servidor de arquivos, é como se existissem dois nomes de compartilhamento diferentes para o mesmo diretório. Esse segundo passo é opcional, pois podemos ter um host exclusivamente SNMP v3 ou um host compatível com SNMP v1, v2c e v3. Nesse caso queremos um host compatível com todas as versões, e por isso vamos informar ao servidor que quando ele receber uma solicitação em nome de uma comunidade, ele vai transformar esse nome de comunidade em um nome de usuário, essa linha faz este mapeamento: # com2sec nome origem comunidade com2sec v2cuser default demopublic Essa linha informa que toda vez que uma solicitação v1 ou v2c for realizada de qualquer endereço IP, por isso a palavra default, com a comunidade demopublic, o servidor deve interpretar isso como uma solicitação do usuário v2cuser. O próximo passo é colocar os usuários existentes em grupos: # group nome modelo segurança group demogroup v2c v2cuser

3 Essa linha indica que o usuário v2cuser será membro do grupo demogroup, e que esse grupo só responde a solicitações da versão 2c do protocolo SNMP. Por último, vamos definir qual é a permissão do grupo no recurso compartilhado, exatamente como fazemos no compartilhamento de diretórios: access nome contexto modelo nível prefixo leitura escrita notificação access demogroup any noauth prefix demoread demowrite None Essa linha indica que o grupo demogroup em qualquer contexto ( ), recebendo solicitações de qualquer versão do protocolo, pois na linha anterior já foram definidas as versões que ele vai responder, com nível de autenticação noauth e com prefixo do tipo prefix, possui direito de leitura na view demoread e escrita na view demowrite, e que não enviará notificações (Traps) para nenhum servidor. 4. Configuração Básica de um Agente SNMP v3 compatível com SNMP v1/v2c Como já dito, podemos ter um host configurado para trabalhar com o SNMP v3, mas mantendo a compatibilidade com as versões 1 e 2c. Exemplo: # cat snmpd.conf # /etc/snmp/snmpd.conf compativel com v1 e v2c (snmpd.conf.02) # # view name inc/excl tree mask view all included.1 80 #com2sec user source(ip,host...) community com2sec readonly default public com2sec readwrite default private #group name v1/v2c/usm user group compat v1 readonly group compat v2c readonly group compat1 v1 readwrite group compat1 v2c readwrite #access user context any/v1/v2c/usm level prefx read write notify access compat "" any noauth exact all none none access compat1 "" any noauth exact all all none Lembre-se que após alterar o arquivo é necessário reiniciar o serviço: # service snmpd restart

4 4.1. Disponibilizando os recursos Seção View A primeira seção a ser configurada é a das "views", ou seja, partes da árvore de OIDs que poderão ser visualizadas, e possui o seguinte formato: view nome included/excluded parte_da_árvore_mib máscara Por exemplo: view all included Seção com2sec A segunda seção trata do processo de associação entre as comunidades e os níveis de acesso são realizados através das linhas com2sec, e possui o seguinte formato: com2sec "security name" origem_da_requisição community Por exemplo: com2sec readonly default public com2sec readwrite default private Seção Group O próximo passo é realizar a associação dos grupos de acessos à versão do protocolo snmp e a um "security name", definindo acessos a informações diferentes dependendo da versão do protocolo utilizado. Estas linhas possuem o seguinte formato: group grupo versão_do_protocolo security_name Por exemplo: group compat v1 readonly group compat v2c readonly group compat1 v1 readwrite group compat1 v2c readwrite Seção Access Finalmente devem-se aplicar as permissões (visualizar/alterar) nas views pelos grupos. A configuração padrão irá permitir que compat possa visualizar qualquer configuração, enquanto compat1 poderá visualizar e alterar qualquer configuração. Possui o seguinte formato: access usuário contexto versão_do_protocolo level prefixo read write notify Por Exemplo: access compat any noauth exact all none none

5 Compreendendo os Parâmetros Seção View View: Comando para definir uma nova view; Name: Nome da view; Included/Excluded: Partes da árvore MIB que serão incluídas ou excluídas na view; Tree: As informações referentes à opção anterior, o que eu estou incluindo ou excluindo da view; posso, por exemplo, excluir a árvore toda (.1) e depois disponibilizar apenas galhos da árvore, como por exemplo, as informações referentes ao protocolo IP (.iso.org.dod.internet.mgmt.mib- 2.ip). Nesse caso essa view só apresentará essas informações; Mask: Máscara no formato hexadecimal; permite criar filtros avançados dentro do galho disponibilizado Seção Com2sec: Com2sec: Comando para definir uma nova associação entre nome de comunidade (v1/v2c) e nível de acesso (v3); Name: Nome do usuário; Source: Origem da requisição, indica a máquina que pode realizar requisições nesse host. Pode ser informado no formato ip/prefixo ou pode-se utilizar a palavra "default", que indica qualquer origem. Community: Nome da comunidade no modelo v1/v2c; esse nome será passado no momento da requisição Seção Group: Group: Comando para definir um novo grupo; Name: Nome do grupo; Model: Versão do protocolo que o host aceita ao receber requisições: o Qualquer versão: any; o Requisições v1: v1; o Requisições v2c: v2c; o Requisições v3: usm. User: Nome do usuário que pertence ao grupo Seção Access: Access: Comando para definir um novo acesso; Group: Nome do grupo ao qual será liberado acesso; Context: Contexto ou escopo; é uma maneira de se criar filtros de acesso para determinadas situações. Pode ser contexto em um dispositivo, contexto em um conjunto de dispositivos, etc. Por exemplo: o Ler as informações de espaço em disco de todos os meus dispositivos; o Ler as informações de tráfego de portas do switch1;

6 o Ler as informações de tráfego de rede de entrada da porta 24 (... iftable.ifentry.ifinoctets.24 ) do switch 2. Security Model: Versão do protocolo que o host aceita ao receber requisições: o Qualquer versão: any; o Requisições v1: v1; o Requisições v2c: v2c; o Requisições v3: usm. Level: Nível de segurança da autenticação: o NoAuth: Sem autenticação; o Auth: Com autenticação; o Priv: Autenticação com Criptografia. Prefix: Define o que será analisado no momento da requisição: o Exact: A correspondência exata de prefixo e contexto; o Prefix: Apenas o prefixo, que é o OID numérico ou identificação do objeto como, por exemplo, sysname. Read: Qual view o grupo tem direito de leitura; Write: Qual view o grupo tem direito de escrita; Notify: Qual host receberá as notificações em caso de situações anormais (Traps). 5. Acessando um Agente SNMP v3 compatível com SNMP v1/v2c: # snmpget -v 1 -c public localhost syscontact.0 SNMPv2-MIB::sysContact.0 = STRING: aulas # snmpset -v 2c -c private localhost syscontact.0 s Curso SNMPv2-MIB::sysContact.0 = STRING: Curso # snmpgetnext -v 1 -c public localhost syscontact.0 SNMPv2-MIB::sysName.0 = STRING: aulas # snmpwalk -v 2c -c public localhost system SNMPv2-MIB::sysDescr.0 = STRING: Linux aulas el6.i686 #1 SMP Mon Jun 27 18:07:00 BST 2011 i686 SNMPv2- MIB::sysObjectID.0 = OID: NET-SNMP- MIB::netSnmpAgentOIDs.10 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (12017) 0:02:00.17 SNMPv2-MIB::sysContact.0 = STRING: Curso SNMPv2-MIB::sysName.0 = STRING: aulas SNMPv2-MIB::sysLocation.0 = STRING: Unknown

7 # snmpbulkget -v 2c -c public localhost system SNMPv2-MIB::sysDescr.0 = STRING: Linux aulas el6.i686 #1 SMP Mon Jun 27 18:07:00 BST 2011 i686 SNMPv2- MIB::sysObjectID.0 = OID: NET-SNMP- MIB::netSnmpAgentOIDs.10 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (12831) 0:02:08.31 SNMPv2-MIB::sysContact.0 = STRING: Curso SNMPv2-MIB::sysName.0 = STRING: aulas SNMPv2-MIB::sysLocation.0 = STRING: Unknown SNMPv2-MIB::sysORLastChange.0 = Timeticks: (24) 0:00:00.24 SNMPv2-MIB::sysORID.1 = OID: SNMP-MPD- MIB::snmpMPDMIBObjects SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SM- MIB::usmMIBCompliance SNMPv2-MIB::sysORID.3 = OID: SNMP-FRAMEWORK- MIB::snmpFrameworkMIBCompliance Como pode ser observado realizamos várias requisições v1 e v2c, utilizando tanto a comunidade public quanto a private e o host respondeu perfeitamente às requisições, ou seja, podemos ter um host configurado para SNMP v3, mas mantendo a compatibilidade com as versões anteriores se isso for uma necessidade do ambiente.