A pergunta

A autenticação decide quem pode entrar, e a autorização decide o que essa pessoa pode fazer; as duas tratam do presente. O accounting (a contabilização) é o único dos três que responde a perguntas sobre o passado, e é no passado que estão todas as perguntas sérias. Depois de uma queda: qual mudança veio antes dela, feita por quem, a que horas, em qual equipamento. Depois de uma invasão: qual conta, vinda de onde, mexeu em quê. Numa auditoria: mostrar que as pessoas que podem alterar a infraestrutura são conhecidas, que as alterações delas ficam registradas e que o registro não pode ser alterado pelas próprias pessoas que ele descreve. As operadoras criaram o accounting para emitir faturas, e é por isso que os atributos do (Remote Authentication Dial-In User Service) contam octetos; as empresas precisam dele para as perguntas acima, e a maioria só descobre no dia da pergunta se ele chegou a ser ligado.

O catálogo de controles do , a SP 800-53, define o requisito sem citar protocolo nenhum. O controle AU-3, Content of Audit Records, exige que os registros estabeleçam "what type of event occurred", "when the event occurred", "where the event occurred", o "source of the event", o "outcome of the event" e a "identity of any individuals, subjects, or objects/entities associated with the event": o que aconteceu, quando, onde, a origem, o resultado e quem estava envolvido. O AU-2 pede que a organização justifique a escolha dos eventos registrados: "provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents". O AC-6(9) cabe numa linha só: "Log the execution of privileged functions." Esses três controles são a especificação; o resto deste artigo mostra como quatro fluxos de registro a cumprem numa rede.

Fluxo um: RADIUS accounting, as sessões de rede

Toda sessão admitida pelo RADIUS pode gerar registros de accounting: um login 802.1X, uma sessão de MAC Authentication Bypass, um visitante autenticado pela web, um usuário de (rede privada virtual). Quem define esses registros é a 2866, publicada por Rigney em junho de 2000. O servidor de acesso à rede, o NAS, envia pacotes Accounting-Request (código 4) para a porta UDP 1813, e o servidor RADIUS confirma cada um com um Accounting-Response (código 5). A RFC recomenda que o cliente insista até ser atendido: "the client continue attempting to send the Accounting-Request packet until it receives an acknowledgement, using some form of backoff". Assim, uma queda curta do servidor atrasa os registros em vez de perdê-los, e uma queda longa produz uma rajada de registros atrasados quando o servidor volta, o que vale saber na hora de ler os timestamps (os carimbos de data e hora).

O atributo Acct-Status-Type diz que tipo de registro é aquele: 1, Start, quando a sessão começa; 2, Stop, quando ela termina; 3, Interim-Update, no intervalo configurado no equipamento; 7, Accounting-On, e 8, Accounting-Off, quando o próprio equipamento começa ou deixa de atender, o que manda o servidor fechar todas as sessões que ele ainda considera abertas naquele equipamento; há outros valores para túneis, e o 15 para uma tentativa que falhou. As medições vêm em atributos: Acct-Session-Id, o identificador que liga o Start, os updates e o Stop de uma mesma sessão; Acct-Input-Octets, Acct-Output-Octets, Acct-Input-Packets e Acct-Output-Packets; Acct-Session-Time, em segundos; Acct-Terminate-Cause, com o motivo do encerramento; Acct-Delay-Time, quanto tempo o registro esperou antes de ser enviado, o que permite corrigir o timestamp; Acct-Multi-Session-Id, para ligar sessões relacionadas; Acct-Authentic, para dizer quem fez a autenticação. O User-Name, o Calling-Station-Id e os identificadores do NAS que vieram da autenticação se repetem, e o atributo Class que o servidor colocou no Access-Accept volta sem modificação, como a RFC 2865 recomenda; assim, uma tag que o policy engine colocou no login aparece em todos os registros da sessão.

Um par de Start e Stop responde, portanto: esta identidade, com o endereço MAC deste dispositivo, nesta porta deste switch ou neste access point, desta hora até esta hora, trafegou este volume e saiu por este motivo. Ele não diz o que a identidade fez enquanto estava conectada; é para isso que servem os outros três fluxos.

Fluxo dois: accounting de comandos no TACACS+, os administradores

Os administradores são as pessoas cujas ações mais importam, e o RADIUS accounting não descreve as sessões deles. O accounting do , definido na RFC 8907 de setembro de 2020, é o terceiro dos três tipos de pacote do protocolo, o 0x03; e, como o TACACS+ autoriza os comandos um a um, um equipamento configurado para accounting de comandos envia um registro para cada comando que o administrador executa. O REQUEST de accounting leva os mesmos argumentos nome=valor da autorização, então um registro de comando informa o serviço, o comando com os seus argumentos e a hora, mais uma flag: START (0x02) no início de uma tarefa, STOP (0x04) no fim, WATCHDOG (0x08) para avisar que uma tarefa longa ainda está rodando. O servidor responde SUCCESS (0x01), ERROR (0x02) ou FOLLOW (0x21). Uma sessão gera um START quando o administrador faz login e um STOP quando ele sai; entre os dois, cada comando gera o seu próprio registro.

Esse fluxo, guardado no servidor com o nome do usuário, o equipamento e o timestamp de cada linha, é a resposta direta para quem mudou o quê. Os limites dele são os dois que todo parque de equipamentos acaba redescobrindo: ele só existe nos equipamentos em que alguém configurou o accounting de comandos apontando para um servidor alcançável, e só pelo período que o servidor guardou. O artigo sobre o TACACS+ mostra essas trocas passo a passo.

Fluxo três: o syslog e o log de mudanças do próprio equipamento

O equipamento vê coisas que nenhum servidor fica sabendo: mudanças de estado de interface, falhas de autenticação, reinícios de processo e, nas plataformas que suportam, cada mudança de configuração no momento em que ela é aplicada. Quem leva essas informações é o syslog. A RFC 5424, publicada por Gerhards em março de 2009, que tornou obsoleta a RFC 3164, define a mensagem como um header (o cabeçalho), dados estruturados opcionais e um texto livre, também opcional. O header leva uma prioridade, "calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity" (ou seja, a facility vezes 8, mais a severity), uma versão, um timestamp derivado da RFC 3339, o hostname, o nome da aplicação, um identificador de processo e um identificador de mensagem. As severidades vão de 0, Emergency, passando por 1, Alert, 2, Critical, 3, Error, 4, Warning, 5, Notice, e 6, Informational, até 7, Debug; as facilities 4 e 10 são reservadas para mensagens de segurança e autorização, e as de 16 a 23 para uso local. A RFC especifica só a mensagem e deixa o transporte para documentos complementares (o UDP na RFC 5426, por compatibilidade, e o TLS na RFC 5425), e afirma que "all implementations of this specification MUST support a TLS-based transport", o que já indica como os dados de accounting deveriam atravessar uma rede. Os artigos sobre syslog deste site detalham a mensagem campo a campo e a configuração do lado do equipamento.

O log de mudanças de configuração do próprio equipamento é o fluxo que mais passa despercebido justamente por quem precisa dele. O recurso Configuration Change Notification and Logging, da Cisco, rastreia as mudanças de configuração por sessão e por usuário com uma função de arquivo; nas palavras do guia de gerenciamento de configuração do IOS XE, ele "allows the tracking of configuration changes entered on a per-session and per-user basis by implementing an archive function". O guia acrescenta que ele "saves configuration logs that track each configuration command that is applied, who applied the command, the parser return code (PRC) for the command, and the time the command was applied": cada comando aplicado, quem o aplicou, o código de retorno do parser e a hora. O recurso vem desabilitado por padrão, guarda um número configurável de entradas (entre 1 e 1000, com padrão de 100), pode omitir senhas do log e pode mandar cada entrada para o syslog no momento em que ela acontece; assim, o registro da mudança chega a um coletor mesmo que o equipamento seja trocado ou apagado depois. Um equipamento com esse recurso ligado e encaminhando para o syslog tem o seu próprio accounting de comandos, independente do TACACS+, e é exatamente essa redundância que uma investigação quer.

Fluxo quatro: backups de configuração, o que os comandos fizeram

O registro de comandos diz o que foi digitado; o arquivo de configurações diz como o equipamento ficou no fim, e a diferença entre duas configurações arquivadas é a própria mudança, documentada ou não. As ferramentas de backup de configuração coletam a configuração em execução (a running-config) de cada equipamento numa agenda fixa ou quando recebem uma notificação de mudança, e guardam tudo num repositório com controle de versão. O Oxidized, que se descreve como "a network device configuration backup tool" e "a RANCID replacement", suporta "over 130 operating system types" (mais de 130 sistemas operacionais), grava a saída em git, que é o armazenamento recomendado, e pode disparar hooks quando uma configuração muda, desde rodar um comando até publicar o diff num canal de chat. Um histórico git das configurações responde à pergunta para a qual ninguém habilitou o accounting: o diff entre o commit de terça e o de quarta é a mudança, e o registro do TACACS+ ou do syslog daquela janela de tempo diz quem a fez. O CM-3 do NIST, Configuration Change Control, pede duas coisas às organizações: "document configuration change decisions" e "retain records of configuration-controlled changes to the system" por um período definido. O arquivo de configurações é o jeito mais barato de esses registros existirem de verdade, e não só como intenção.

Como juntar os quatro fluxos num registro só

Quatro fluxos só respondem à pergunta se for possível cruzar um com o outro, e esse cruzamento precisa ser planejado, não presumido.

Relógios. Todo registro leva um timestamp do equipamento que o gerou, no formato RFC 3339 da RFC 5424, ou a hora em que o servidor RADIUS o recebeu, e uma correlação entre equipamentos só é tão boa quanto a concordância entre os relógios deles. A sincronização de horário em todos os equipamentos de rede é, antes de tudo, um controle de accounting, e um equipamento com o relógio errado produz registros errados que parecem certos.

Chaves. Os registros do RADIUS se ligam pelo Acct-Session-Id dentro de uma sessão, pelo User-Name e pelo Calling-Station-Id entre sessões, e pelo Class até a política que admitiu a sessão. Os registros do TACACS+ se ligam pelo nome de usuário, pelo equipamento e pela hora. O syslog se liga pelo hostname e pela hora, e as entradas do log de configuração também trazem o nome de usuário. A identidade do equipamento precisa ser a mesma string nos quatro fluxos, e por padrão não é: o NAS-Identifier, o endereço do cliente TACACS+, o hostname do syslog e o nome do equipamento no inventário da ferramenta de backup são configurados em quatro lugares, por quatro pessoas.

Retenção. Cada fluxo tem uma retenção padrão, definida por quem o instalou, e a pergunta chega depois que todos esses prazos já venceram. O período de retenção é uma decisão que precisa ser documentada, fluxo por fluxo, levando em conta até onde, no passado, uma investigação ou uma regulação pode precisar olhar.

Separação. Quem administra os equipamentos de rede não deveria administrar os servidores que guardam o registro do que essas mesmas pessoas fizeram. O AC-5 do NIST descreve esse padrão na discussão sobre segregação de funções: "ensuring that security personnel who administer access control functions do not also administer audit functions". O verbete de segregação de funções deste site explica por que um controle que uma pessoa consegue burlar sozinha não é um controle. Numa equipe pequena, este é o item mais difícil da lista, e o primeiro que um auditor confere.

Transporte. O RADIUS accounting, o TACACS+ e o syslog sobre UDP atravessam a rede de formas que as próprias especificações descrevem como fracas: o RADIUS com e um segredo compartilhado, o TACACS+ com o que a RFC 8907 chama de ofuscação, o syslog sobre UDP sem proteção nenhuma. As respostas são o RadSec para o RADIUS, uma rede de gerência protegida para o TACACS+, como a RFC 8907 exige, e o syslog sobre TLS, cujo suporte a RFC 5424 torna obrigatório; e os registros valem mais do que o tráfego de autenticação que eles descrevem.

O apontamento mais antigo

A falha que torna este artigo necessário não é defeito de projeto de protocolo nenhum. É o equipamento que nunca foi configurado para enviar accounting, o servidor que ninguém configurou para guardá-lo, o log de configuração deixado no padrão, desabilitado, e o job de backup que parou de rodar quando a pessoa que o montou saiu da empresa. Cada um dos quatro fluxos precisa ser ativado no equipamento, e cada um precisa apontar para um destino que exista, seja alcançável e guarde os registros. A auditoria que encontra a lacuna é a da manhã seguinte ao incidente, e o controle que evita isso é tedioso: um inventário dos equipamentos cruzado com os quatro fluxos, conferido por um job e não por uma pessoa, com registro da própria conferência.

O que vem a seguir na série

As regulações que exigem esses registros, da Lei Sarbanes-Oxley ao , têm verbetes próprios e vão ganhar artigos próprios; este artigo é o ponto comum em que todas elas se apoiam. Os artigos sobre RADIUS e TACACS+ descrevem o lado de accounting dos dois protocolos, cada um no seu contexto; os artigos sobre syslog detalham a mensagem; e os verbetes do glossário sobre accounting, segregação de funções, privilege creep e menor privilégio trazem o vocabulário que um auditor vai usar.

Fontes