Protocolos de Comunicação

Uma das formas possíveis de realizar a coleta dos dados dos componentes da rede monito- rada é através do socket (RFC 147, 1971), presente na arquitetura TCP/IP. O socket é uma inter- face que fornece um mecanismo de comunicação utilizando protocolo TCP ou UDP. Dessa for- ma, diferentes aplicações podem ser implementadas para consultar dados de rede, como número de servidores com acesso via SSH liberado, número de portas abertas ou fechadas em um compu- tador, entre outros.

30

Outro protocolo importante é o SNMP (RFC 1157, 1990) que é um protocolo padrão para gerência de redes TCP/IP definido pelo IETF (Internet Engineering Task Force). O SNMP requer poucos recursos para ser implementado e utiliza o protocolo de transporte UDP para efetuar a troca de dados entre agentes e gerentes. Além disso, oferece um conjunto de operações que per- mitem um monitoramento de diversos componentes da rede, como switches, servidores, entre outros. A seguir são descritas duas operações básicas (GET e SET) e suas derivações (GET- NEXT, TRAP).

• GET: utilizada para ler o valor da variável, ou seja, o gerente realiza uma solicitação para que o agente obtenha o valor da variável.

• SET: utilizada para alterar o valor da variável, ou seja, o gerente realiza uma solicitação para que o agente faça uma alteração no valor da variável.

• GET-NEXT: utilizada para obter o valor da próxima variável ou obter valores e nomes de variáveis de uma tabela de tamanho desconhecido.

• TRAP: utilizada para comunicar um evento. Neste caso, o agente comunica ao gerente o acontecimento de um evento previamente determinado, como por exemplo, quando o en- lace de uma comunicação é interrompido, recebimento de uma mensagem SNMP do ge- rente não autenticada, entre outros.

Segundo Mauro et al. (2001), ao utilizar estas operações, é possível coletar os dados do dispositivo gerenciado. Na MIB estão contidas as variáveis, ou objetos de gerência, responsáveis por armazenar as estatísticas de funcionamento do equipamento, como por exemplo, número de interfaces de rede existentes no computador, estado atual da interface (ativada ou desativada), número de bytes recebidos pela interface, entre outros. As informações são organizadas de forma hierárquica. Para requisitar a informação contida em determinado objeto, a requisição deve conter o identificador deste objeto, o qual representa o caminho a ser percorrido na hierarquia de infor- mações da MIB. O objeto de gerência sysuptime, por exemplo, está localizado no grupo system e tem por finalidade armazenar o tempo em que o dispositivo permanece ativo. Para requisitar esta informação é necessário passar como parâmetro o identificador do objeto 1.3.6.1.2.1.1.3. A Figu- ra 4.3 apresenta a árvore de informações de uma MIB.

31

Figura 4.3: Informações da MIB dispostas de uma forma hierárquica. Extraída de (Mauro et al., 2001) Uma terceira forma de coletar os dados dos dispositivos de rede é através do protocolo NetFlow desenvolvido pela Cisco Systems (RFC 3954, 2004). Este protocolo permite que o ad- ministrador de rede exporte e colete os dados do “fluxo” de pacotes dos roteadores que suportem esta tecnologia. Dessa forma, cada interface de um roteador pode ser monitorada e os pacotes coletados e agrupados utilizando os seguintes dados presentes no cabeçalho do pacote: i) endere- ços IP de origem e destino; ii) campo protocolo do cabeçalho IP; iii) portas de origem e destino; iv) campo de tipo de serviço do cabeçalho do protocolo IP.

O roteador realiza a coleta destes dados e os mantém em sua memória. Em determinados períodos de tempo estes dados são exportados para um coletor, que realiza o armazenamento de- finitivo dos registros de fluxos IP. Além disso, os registros de fluxos contêm os timestamps do início e término do fluxo, as flags TCP observadas no monitoramento, a quantidade de bytes e a quantidade de pacotes que trafegavam neste fluxo. Dessa forma, é possível calcular, por exemplo, a taxa de transmissão em bits/s entre duas aplicações de dois nós da rede no fluxo monitorado, os serviços utilizados em cada fluxo através das portas de origem e destino e quantas conexões TCP foram estabelecidas. A correlação das informações de fluxos monitorados em diferentes roteado- res da rede pode ser importante para prover ao administrador uma visão geral de todo o sistema. A Figura 4.4 ilustra a arquitetura do protocolo NetFlow.

32

Figura 4.4: Arquitetura NetFlow.

Porém, em situações de tráfego intenso, a tarefa de manter todos os dados dos fluxos ocu- pa grande parte dos recursos de armazenamento e processamento dos roteadores. Na tentativa de evitar este problema, o NetFlow permite configurar a taxa de amostragem, na qual pode ser defi- nida a quantidade de pacotes que devem ser coletados em relação ao total que realmente trafegou pela interface observada. No entanto, a definição correta desta taxa de amostragem ainda é um desafio.

Em situações de sobrecarga do roteador, uma taxa de amostragem baixa pode ser interes- sante, pois preserva os recursos. Já em casos de normalidade, a taxa de amostragem baixa subuti- liza os recursos disponíveis e coleta menos dados do que realmente poderia ser coletado, diminu- indo a eficácia da análise (Estan et al., 2004), (Zarpelão, 2010).

Outra dificuldade ao utilizar este protocolo é definir o momento em que um fluxo foi con- cluído. Para atender este requisito, o NetFlow utiliza quatro regras: i) um fluxo é considerado concluído quando há o fim de uma conexão TCP identificado através de flags como FIN ou RST; ii) um fluxo é considerado concluído quando não é observado um pacote pertencente a ele a mais de 15 segundos. É importante mencionar que este valor é configurável; iii) um fluxo é considera- do concluído trinta minutos depois de ter sido criado; iv) caso não haja mais memória suficiente para novos fluxos, todos os fluxos armazenados na memória do roteador são considerados con- cluídos e são exportados. A aplicação destas regras unidas à amostragem de pacotes pode não ser eficiente, causando erros nas estatísticas levantadas sobre os fluxos monitorados.

Durante a amostragem de pacotes os pacotes de um fluxo podem não ser coletados mesmo que ele esteja ativo, fazendo com que a regra 2 seja aplicada. Na próxima vez que um pacote des-

33

te fluxo for incluído na amostragem, o fluxo será contabilizado novamente de maneira equivocada, já que o sistema o reconhecerá como um novo fluxo (Zarpelão, 2010).

Finalmente, o protocolo NetFlow está evoluindo para o padrão IETF chamado de IPFIX (Internet Protocol Flow Informatiom Export) (RFC 5101, 2008). O IPFIX aperfeiçoa a exporta- ção dos dados através de um modelo, o que permite a extensão e adaptação a diferentes cenários. Além disso, um formato de arquivo é especificado para armazenamento dos dados recebidos. Estas adaptações têm por finalidade facilitar a interoperabilidade, o armazenamento e análise dos dados (RFC 5101, 2008).

Outro protocolo que possibilita a coleta dos dados das métricas é o protocolo ICMP (In-

ternet Control Message Protocol). Este protocolo permite transmitir mensagens encapsuladas

através de datagramas IP. Além disso, através do comando ping é possível realizar tentativas de comunicação com os equipamentos de rede e verificar se o equipamento encontra-se instável ou detectar falhas de comunicação na rede.

Por fim, é importante mencionar que os protocolos de serviços de mensagens como o POP3 (Post Office Protocol), SMTP (Simple Mail Transfer Protocol) e o IMAP (Internet Messa-

ge Access Protocol) também podem ser utilizados para coletar os dados das métricas de seguran-

ça. O protocolo POP3, por exemplo, permite analisar os dados de e-mails da caixa de entrada e verificar, através de filtros, os e-mails que podem ser considerados spams.

O próximo capítulo apresenta a arquitetura de software presente na estação de gerencia- mento, os detalhes de cada camada e suas interações e como decorre todo o processo de coleta dos dados de uma forma automatizada.