Guia de gestão de dispositivos de rede: SNMP, TFTP e syslog sem um NMS completo

A gestão de switches e routers sem software dispendioso depende de três protocolos leves. A combinação de polling SNMP através da porta UDP 161, transferências de ficheiros TFTP sob o RFC 1350 e recolha de syslog na porta UDP 514 proporciona visibilidade e recuperação completas. Executar estas tarefas a partir de um único utilitário cobre as tarefas diárias sem a sobrecarga de uma grande plataforma.

O que é que o SNMP, TFTP e syslog fazem realmente por si?

Cada protocolo responde a uma pergunta diferente sobre um dispositivo. Juntos, cobrem a maior parte do que faz a um switch ou router entre instalações.

O SNMP responde a "em que estado se encontra este dispositivo neste momento?" O Simple Network Management Protocol (SNMP) permite que um gestor leia valores de um dispositivo. Um pedido "get" lê um valor, como o tempo de atividade ou uma contagem de erros de interface. Um "walk" lê cada valor sob um ramo da árvore, um após o outro. Cada valor tem um identificador de objeto (OID), um número pontuado como 1.3.6.1.2.1.1.3 para sysUpTime. Uma Management Information Base (MIB) é o ficheiro de texto que atribui a esses números nomes legíveis por humanos.

O TFTP responde a "como é que coloco ou retiro um ficheiro deste dispositivo?" O Trivial File Transfer Protocol (TFTP), definido no RFC 1350, move ficheiros através da porta UDP 69 sem necessidade de início de sessão. A maioria dos switches e routers geridos pode copiar a sua configuração de execução para um servidor TFTP. Também podem descarregar imagens de firmware a partir de um.

O Syslog responde a "o que é que este dispositivo me tem estado a dizer?" Os dispositivos enviam linhas de registo para um recetor à medida que os eventos ocorrem. O formato atual é o RFC 5424, e muitos equipamentos de rede ainda enviam o formato BSD mais antigo descrito no RFC 3164. Os traps SNMP fazem o mesmo trabalho para alertas estruturados. Um trap linkDown, por exemplo, chega à porta UDP 162 no momento em que uma porta cai.

Onde cada protocolo se enquadra

Tarefa	Protocolo	Transporte e porta	Padrão	Segurança integrada
Monitorizar o estado do dispositivo a pedido	SNMP get, getnext, getbulk	UDP 161	RFC 3416 (operações), RFC 3411 a 3418 (SNMPv3)	v2c: community string em texto limpo. v3: autenticação e encriptação (RFC 3414, RFC 3826)
Receber alertas estruturados	SNMP trap ou inform	UDP 162	RFC 3416	Corresponde à versão SNMP em utilização
Fazer cópias de segurança de configurações, restaurar configurações, carregar firmware	TFTP	UDP 69, depois uma nova porta por transferência	RFC 1350, opções no RFC 2347 a 2349	Nenhuma: sem autenticação, sem encriptação
Recolher registos do dispositivo	Syslog	UDP 514, ou TLS em TCP 6514	RFC 5424, RFC 5426, RFC 5425	UDP: nenhuma. TLS: encriptação e autenticação do servidor

O que precisa antes de começar?

A configuração é leve, mas cinco coisas decidem se irá funcionar logo no primeiro dia.

• Uma rede de gestão. Coloque as interfaces de gestão dos dispositivos num VLAN de gestão. Um VLAN é uma rede lógica separada que corre nos mesmos switches físicos. Isto mantém o tráfego de SNMP, TFTP e syslog afastado do tráfego de convidados e funcionários.
• Um anfitrião de gestão fixo. Utilize um portátil ou anfitrião de salto nessa VLAN com um endereço estático. Os dispositivos enviam registos e armadilhas para um endereço fixo, pelo que uma alteração de endereço interrompe a recolha silenciosamente.
• Credenciais. Crie um utilizador SNMPv3 com autenticação e privacidade onde o seu firmware o suporte. Se tiver de utilizar v2c, altere a string de comunidade predefinida e restrinja-a ao acesso apenas de leitura a partir do seu anfitrião de gestão.
• Sincronização de hora. Aponte cada dispositivo para a mesma origem NTP. Sem isto, os carimbos de data/hora de syslog de diferentes dispositivos não podem ser alinhados durante uma falha.
• Regras de firewall. Permita UDP 161 do seu anfitrião para os dispositivos. Permita UDP 162 e UDP 514 dos dispositivos para o seu anfitrião. O TFTP necessita de UDP 69 mais as portas adicionais abrangidas abaixo.

Como o modelo de gestão do seu fornecedor altera o plano

As plataformas geridas na nuvem mantêm a configuração na sua nuvem, pelo que a cópia de segurança TFTP é menos importante aí. O SNMP e o syslog continuam a dar-lhe uma visão local do comportamento do dispositivo.

Fornecedor	Modelo de gestão	Onde reside a configuração	O que uma ferramenta local ainda faz
Cisco Meraki	Painel de controlo na nuvem Meraki	Painel de controlo Meraki	Recebe syslog, consulta SNMP onde ativado no painel de controlo
HPE Aruba	CLI em switches AOS-S e AOS-CX, ou Aruba Central	No switch, espelhado no Central onde utilizado	Consulta SNMP, syslog, cópia de configuração TFTP
Ruckus	CLI em switches ICX, ou controlador Ruckus e gestão na nuvem	No switch	Consulta SNMP, syslog, cópia de configuração TFTP
Juniper Mist	Nuvem Mist a gerir switches Junos EX	Nuvem Mist	Consulta SNMP e syslog a partir do Junos
Ubiquiti UniFi	Aplicação UniFi Network	Cópias de segurança da aplicação UniFi Network	Syslog remoto, SNMP onde ativado
Cambium	cnMaestro, ou gestão local em switches cnMatrix	cnMaestro ou o switch	Consulta SNMP e syslog
Extreme	CLI no Switch Engine (EXOS), ou ExtremeCloud IQ	No switch	Consulta SNMP, syslog, cópia de configuração TFTP
Fortinet	GUI ou CLI de FortiGate e FortiSwitch, ou FortiManager	No dispositivo	Consulta SNMP, syslog, cópia de segurança de configuração TFTP a partir da CLI

Os switches Cisco Catalyst que executam IOS ou IOS XE estão fora do modelo Meraki. A sua configuração reside no switch e é copiada para um servidor TFTP a partir da CLI.

Como configurar a consulta SNMP, cópias de segurança TFTP e um recetor syslog?

O Netforge Network Multi-Tool inclui um cliente SNMP, um servidor TFTP e um recetor syslog. Uma única instalação no seu anfitrião de gestão abrange todos os três passos abaixo. Os mesmos passos funcionam com ferramentas autónomas, caso já as execute.

Passo 1: executar um SNMP walk sem um navegador MIB

Não necessita de um navegador MIB para obter respostas úteis. Uma MIB apenas traduz números em nomes. Percorra o ramo numérico correto e os valores falam por si. Comece com estes quatro ramos padrão:

• 1.3.6.1.2.1.1 (grupo de sistema). Devolve sysDescr (modelo e string de firmware), sysUpTime, sysName e sysLocation. Definido na RFC 3418.
• 1.3.6.1.2.1.2.2 (ifTable). Devolve descrições de interface, estado operacional, erros e contadores de tráfego de 32 bits. Definido no RFC 2863.
• 1.3.6.1.2.1.31.1.1 (ifXTable). Devolve contadores de alta capacidade de 64 bits e os aliases de interface que introduziu como descrições de porta.
• 1.3.6.1.4.1 (private enterprise branch). Devolve valores específicos do fabricante sob números de empresa atribuídos pela IANA. O número da Cisco, por exemplo, é 9.

No Netforge, introduza o endereço do dispositivo, as suas credenciais SNMP e um OID inicial e, em seguida, execute um walk. Cada resultado é lido como um OID, um tipo e um valor. Uma STRING sob sysDescr é lida como texto simples. Um valor de Timeticks sob sysUpTime conta centésimos de segundo desde que o agente foi iniciado.

Se preferir a linha de comandos, o snmpwalk do Net-SNMP faz o mesmo trabalho:

snmpwalk -v3 -l authPriv -u <user> -a SHA -A <auth-passphrase> -x AES -X <priv-passphrase> <switch-address> 1.3.6.1.2.1.1

Comece de forma restrita. Um walk a partir da raiz num switch de core grande pode devolver dezenas de milhares de linhas e expirar por limite de tempo. Execute o walk num ramo, encontre o que precisa e, da próxima vez, utilize um get para esse OID único.

Leia o tráfego a partir dos contadores de 64 bits. Um contador de octetos de 32 bits reinicia por volta dos 4,29 mil milhões de bytes. Numa ligação de 1 Gbps à taxa de linha, esse reinício ocorre aproximadamente a cada 34 segundos. O RFC 2863 exige contadores de octetos de 64 bits em interfaces mais rápidas do que 20 Mbps exatamente por este motivo.

Passo 2: executar um servidor TFTP para cópias de segurança de configuração do switch

Inicie o servidor TFTP no Netforge, escolha uma pasta raiz e permita a escrita de ficheiros. Em seguida, envie a configuração do dispositivo para o seu anfitrião. O comando difere consoante o fabricante:

• Cisco IOS e IOS XE: copy running-config tftp: solicita o endereço do servidor e um nome de ficheiro.
• HPE Aruba AOS-S: copy running-config tftp seguido do endereço do servidor e do nome do ficheiro.
• Extreme Switch Engine (EXOS): tftp put com o endereço do servidor e os detalhes do ficheiro.
• Fortinet FortiGate: execute backup config tftp seguido de um nome de ficheiro e do endereço do servidor.

Consulte a referência de comandos do seu fabricante para obter a sintaxe exata na versão do seu firmware. Nomeie cada ficheiro com o nome de anfitrião e a data, para que um restauro nunca obtenha a configuração do switch errado. Mova as cópias de segurança concluídas do anfitrião TFTP para um armazenamento protegido.

Os carregamentos de firmware funcionam da mesma forma no sentido inverso. Imagens maiores do que cerca de 32 MB podem falhar em servidores limitados a blocos de 512 bytes. O contador de blocos de 16 bits esgota-se com esse tamanho. A opção de blocksize no RFC 2348 elimina o limite quando ambas as extremidades a suportam.

Desligue o servidor TFTP quando terminar. O TFTP não possui autenticação, pelo que um servidor sempre ativo é um ponto de receção de ficheiros aberto na sua rede de gestão.

Passo 3: executar um recetor de syslog e SNMP trap

Aponte o anfitrião de registo de cada dispositivo para o endereço do seu anfitrião de gestão. Em seguida, defina um limiar de gravidade. As gravidades do syslog variam de 0 (Emergency) a 7 (Debug). O envio de 0 a 5 (Notice) captura falhas e alterações de estado sem inundar o recetor. Aumente o nível de um dispositivo para Debug apenas enquanto estiver a investigar uma falha específica.

Adicione o seu host como um destino de trap SNMP com as mesmas credenciais que utiliza para a consulta (polling). Ative as notificações padrão de SNMPv2-MIB e IF-MIB: coldStart, linkDown, linkUp e authenticationFailure. Utilize informs em vez de traps onde o dispositivo os suporte. Um inform aguarda uma confirmação, pelo que um alerta perdido é reenviado.

O recetor de syslog Netforge apresenta registos e traps na mesma ferramenta que utiliza para consulta e transferência de ficheiros. Isso elimina a necessidade de executar o Kiwi Syslog Server juntamente com o Tftpd64 e um browser MIB separado.

Cenário prático: um hotel de 200 quartos recupera um switch com falha

Situação. Um hotel de 200 quartos operava 14 switches: dois centrais (core) e 12 de acesso. Uma falha de energia danificou um switch de acesso que servia dois pisos de hóspedes. Não existia cópia de segurança (config backup). O engenheiro reconstruiu as VLANs e as definições de porta a partir de fotografias e de memória, o que demorou um dia inteiro de trabalho.

O que foi feito. O gestor de TI configurou um host de gestão com TFTP, SNMP e syslog numa única ferramenta. A configuração de cada switch passou a ser descarregada para o TFTP semanalmente e antes de cada alteração. Uma varredura (walk) SNMP mensal do grupo de sistema registava todos os modelos e versões de firmware. Todos os 14 switches enviavam syslog e traps para o mesmo recetor.

Resultado. Quando um segundo switch de acesso falhou, o substituto chegou com o mesmo modelo. O engenheiro carregou a configuração da semana anterior a partir do servidor TFTP. Os hóspedes desses pisos voltaram a estar online em menos de uma hora, em comparação com um dia inteiro na primeira ocorrência. As equipas hoteleiras que gerem redes WiFi de hóspedes em grande escala enfrentam o mesmo padrão em todas as propriedades: consulte Hotéis.

Como verificar se funciona?

Teste cada protocolo face a um resultado conhecido antes de depender dele.

• SNMP. Obtenha o sysUpTime duas vezes, com um minuto de intervalo. O valor deve aumentar cerca de 6.000 centésimos de segundo. Confirme se o sysName coincide com o hostname esperado.
• Cópia de segurança TFTP. Abra o ficheiro guardado e leia-o. Uma configuração Cisco IOS termina com a linha end, pelo que um ficheiro truncado é detetado imediatamente. Compare o tamanho do ficheiro com a cópia de segurança anterior.
• Restauro TFTP. Restaure uma cópia de segurança num switch sobressalente ou de laboratório. Uma cópia de segurança que nunca restaurou é uma esperança, não um plano de recuperação.
• Syslog e traps. Desative e reative uma porta não utilizada. Deverá ver uma trap linkDown e outra linkUp, além das linhas de syslog correspondentes. Os carimbos de data/hora devem coincidir ao segundo se o NTP estiver a funcionar corretamente.
• Cobertura. Confirme se todos os dispositivos no seu inventário enviaram pelo menos uma linha de registo nas últimas 24 horas. Um dispositivo silencioso é, geralmente, um dispositivo mal configurado.

O que corre mal e como resolver?

A maioria das falhas deve-se a firewalls, credenciais ou interfaces de origem. Esta tabela associa os sintomas comuns às respetivas soluções.

Sintoma	Causa provável	Solução
O pedido SNMP expira (timeout)	A lista de acesso do dispositivo bloqueia o seu host ou a porta UDP 161 está filtrada	Adicione o seu host à lista de acesso SNMP e abra a porta UDP 161
O SNMPv3 falha com um erro de autenticação	Incompatibilidade do algoritmo de autenticação ou de privacidade	Faça corresponder as definições SHA e AES em ambas as extremidades e reintroduza as palavras-passe
O Walk devolve dados do sistema mas nada sob o ramo empresarial	O controlo de acessos baseado em visualização (RFC 3415) limita o que o seu utilizador pode ver	Alargue a visualização SNMP para o seu utilizador de leitura exclusiva
A transferência TFTP inicia-se e depois falha	O firewall ou NAT bloqueia a porta subsequente a partir da qual o servidor responde	Permita o intervalo de portas de transferência do servidor ou mantenha o TFTP dentro de uma única VLAN
Escrita TFTP recusada	O servidor não cria novos ficheiros ou as permissões de pasta bloqueiam as escritas	Permita a criação de ficheiros no servidor e verifique as permissões de pasta
Firmware grande falha a meio	Limite de bloco de 512 bytes atingido a cerca de 32 MB	Ative a opção de tamanho de bloco ou utilize o carregamento por SCP ou HTTP do fornecedor
Nenhum syslog chega	O dispositivo envia a partir de uma interface diferente ou o firewall do anfitrião bloqueia o UDP 514	Defina a interface de origem de registo e permita o tráfego UDP 514 de entrada
Os registos aparecem fora de ordem	Os dispositivos não estão sincronizados com o NTP	Configure a mesma origem NTP em todos os dispositivos
Os gráficos de interface estabilizam ou dão saltos	Enrolamento de contador de 32 bits	Faça sondagens a ifHCInOctets e ifHCOutOctets a partir da ifXTable

Qual é o custo e qual é o retorno?

O verdadeiro custo da gestão de dispositivos é o tempo do engenheiro e o tempo de inatividade, não o software. Compare as três abordagens comuns nos eixos que impulsionam ambos.

Abordagem	Ferramentas a instalar	Protocolos abrangidos	Desenvolvido para	Adequado para
Freeware de finalidade única	Três: Tftpd64, Kiwi Syslog Server, um browser MIB	TFTP e syslog, traps SNMP via Kiwi, sondagem SNMP via browser	Tarefas ad hoc, uma ferramenta por trabalho	Um engenheiro que já domina as três
Multi-ferramenta leve (Netforge Network Multi-Tool)	Uma	SNMP get e walk, servidor TFTP, recetor de syslog e trap	Sondagem a pedido, transferências e registos em tempo real	Instalações pequenas, trabalho de campo de MSP, locais únicos
NMS completo	Uma plataforma mais uma base de dados e servidor	SNMP, syslog, traps, além de deteção, gráficos e encaminhamento de alertas	Monitorização contínua e histórico de tendências a longo prazo	Instalações grandes ou multi-site com equipas de prevenção

Quando precisa realmente de um NMS completo

Uma ferramenta leve lê o estado quando o solicita. Um NMS completo monitoriza continuamente e recorda. Mude para um NMS completo quando uma destas situações se verificar:

• Precisa de semanas de histórico de interface para o planeamento de capacidade.
• Os alertas devem notificar um engenheiro de prevenção às 3 da manhã sem que ninguém esteja a olhar para um ecrã.
• A sua instalação abrange dezenas de locais, tais como estações numa rede ferroviária. Consulte Comboios.
• Os auditores esperam relatórios automatizados em vez de ficheiros exportados manualmente.

Abaixo desse limite, um NMS completo adiciona um servidor, uma base de dados e manutenção para funcionalidades que não irá utilizar.

Cenário prático: uma cadeia de retalho com 40 lojas encontra falhas de ligação ocultas

Situação. Um MSP prestava suporte a uma cadeia de 40 lojas. Cada loja operava um firewall Fortinet FortiGate e dois switches. As equipas das lojas reportavam que os terminais de pagamento perdiam a ligação várias vezes por semana. As visitas dos engenheiros não detetavam nada, pois a falha já tinha desaparecido antes de alguém chegar.

O que foi feito. O MSP direcionou o syslog e as traps SNMP de todos os 120 dispositivos para um recetor através da VPN site-to-site existente. Cada switch enviou traps linkDown e linkUp. A equipa analisou o recetor diariamente durante duas semanas.

Resultado. Os registos mostraram flaps de link repetidos em portas de uplink em três lojas, coincidindo com as horas de quebra reportadas. O pessoal das lojas substituiu três cabos de rede (patch leads) defeituosos sob orientação remota. O MSP cessou as visitas reativas para essa falha e as três lojas não registaram mais quebras de terminais. Mais informações sobre como as redes de retalho funcionam: Retail.

Conformidade e tratamento de dados

Os registos dos dispositivos têm relevância a nível de conformidade. A norma PCI-DSS exige a alteração das predefinições do fornecedor e a versão 3.2.1 nomeia explicitamente as community strings de SNMP. O requisito 10.5.1 da versão 4.0 do PCI-DSS solicita a retenção de registos de auditoria por um período mínimo de 12 meses, com três meses imediatamente disponíveis. O controlo 8.15 do Anexo A da norma ISO 27001 abrange o registo de eventos (logging).

As linhas de syslog podem conter endereços IP e MAC, que podem ser considerados dados pessoais ao abrigo do GDPR. Defina um período de retenção e limite o acesso de leitura aos ficheiros do recetor. Isto é crucial em ambientes regulados: consulte Healthcare.

Onde a Purple se enquadra

A Purple é agnóstica em termos de hardware. O nosso Guest WiFi funciona como uma sobreposição na nuvem (cloud overlay) em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet, em mais de 80.000 locais ativos (dados da Purple). Switches saudáveis e bem documentados na base tornam qualquer serviço de sobreposição mais fácil de gerir. O Netforge Network Multi-Tool oferece aos seus engenheiros a visão ao nível do dispositivo para os manter assim.

Perguntas frequentes

Preciso de um NMS completo para gerir um pequeno grupo de switches?

Não. Para um único local ou uma pequena infraestrutura, a consulta (polling) SNMP, as cópias de segurança TFTP e um recetor syslog cobrem a maior parte da gestão diária. Um NMS completo justifica o seu custo quando necessita de monitorização contínua, semanas de histórico de tendências, alertas automáticos para engenheiros de prevenção ou gestão em dezenas de locais. Abaixo desse patamar, apenas adiciona um servidor, uma base de dados e custos de manutenção para funcionalidades que não irá utilizar.

Posso realizar um SNMP walk sem um MIB browser?

Sim. Uma MIB apenas traduz OIDs numéricos em nomes, pelo que pode percorrer os ramos numéricos diretamente. Comece com 1.3.6.1.2.1.1 para modelo, firmware e tempo de atividade (uptime), e 1.3.6.1.2.1.31.1.1 para nomes de interfaces e contadores de tráfego de 64 bits. O Netforge Network Multi-Tool executa operações get e walk a partir de um OID inicial. O snmpwalk do Net-SNMP faz o mesmo a partir da linha de comandos.

O TFTP é seguro para realizar cópias de segurança de configurações de switches?

Sim, desde que o mantenha isolado. O TFTP não possui autenticação ou encriptação ao abrigo do RFC 1350, pelo que qualquer pessoa no percurso da rede pode ler uma configuração em trânsito. Execute o servidor TFTP apenas numa VLAN de gestão e apenas durante uma cópia de segurança ou restauro. Mova os ficheiros concluídos para um armazenamento protegido. Sempre que o seu fornecedor suporte SCP ou SFTP, utilize estes protocolos para cópias de segurança agendadas.

Isto irá funcionar com o meu hardware Cisco, Aruba ou Fortinet existente?

Sim. O SNMP, TFTP e syslog são padrões abertos suportados pelo Cisco IOS, HPE Aruba AOS-S e AOS-CX, Ruckus ICX, Extreme Switch Engine e Fortinet FortiGate. Plataformas geridas na nuvem, como o Cisco Meraki, Juniper Mist e Ubiquiti UniFi, mantêm a configuração na sua própria nuvem. Nelas, utiliza-se o SNMP e o syslog localmente e faz-se a cópia de segurança da configuração através da própria plataforma do fabricante.

Pode uma única ferramenta substituir o Tftpd64 e o Kiwi Syslog Server?

Sim. O Netforge Network Multi-Tool inclui um servidor TFTP, um recetor de syslog e SNMP trap, e SNMP get e walk numa única aplicação. Isso substitui o Tftpd64 para transferências de ficheiros e o Kiwi Syslog Server para registos, eliminando a necessidade de um navegador MIB separado. Se precisar de armazenamento de registos a longo prazo ou encaminhamento automatizado de alertas, combine-o com uma plataforma de registos ou um NMS completo.

Os registos de dispositivos estão abrangidos pelo PCI-DSS e GDPR?

Sim, na maioria dos locais. O requisito 10.5.1 da versão 4.0 do PCI-DSS exige que os registos de auditoria sejam retidos por pelo menos 12 meses, com três meses imediatamente disponíveis para sistemas abrangidos. As linhas de syslog podem incluir endereços IP e MAC, que podem ser dados pessoais ao abrigo do GDPR. Defina um período de retenção, restrinja o acesso aos ficheiros de registo e documente ambos.

Quanto tempo demora a configuração para um parque de dispositivos pequeno?

A maior parte do esforço reside na configuração do lado do dispositivo e não na própria ferramenta. Definir um anfitrião de registo, um destino de trap e um utilizador SNMPv3 demora escassos minutos por switch a partir da CLI. Para um local com 14 switches, conte com uma tarde de trabalho, incluindo regras de firewall e verificação. O trabalho de NTP e VLAN de gestão, caso ainda não esteja implementado, costuma demorar mais tempo do que a configuração da ferramenta.