# TACACS+ na administração de equipamentos: um login e um comando, troca a troca

> Como um roteador pergunta a um servidor se um engenheiro pode fazer login, se o comando que ele acabou de digitar pode rodar, e como registra que o comando rodou: os três tipos de pacote da RFC 8907, o header de 12 bytes, o START, o REPLY e o CONTINUE da autenticação, a autorização comando a comando com argumentos nome=valor, o START, o STOP e o WATCHDOG do accounting, a ofuscação que a RFC se recusa a chamar de criptografia, o ancestral de 1993 descrito na RFC 1492 e a disciplina da method list, que mantém os equipamentos acessíveis quando os servidores não estão.

Source: https://ronutz.com/pt-BR/learn/tacacs-plus-device-administration  
Updated: 2026-10-06

---

## Um trabalho diferente de dar acesso à rede

Liberar um notebook numa porta de switch é uma decisão só: entra ou não entra, e em qual VLAN (rede local virtual). Administrar o switch são milhares de decisões: este engenheiro pode fazer login, pode entrar no modo de configuração, pode mexer nesta interface mas não naquele processo de roteamento, e tudo o que ele digitar precisa ficar registrado. O RADIUS (Remote Authentication Dial-In User Service) responde bem ao primeiro tipo de pergunta e mal ao segundo, e o próprio documento da Cisco que compara os dois protocolos explica por quê: "RADIUS combines authentication and authorization" numa troca só, e "RADIUS does not allow users to control which commands can be executed on a router". O TACACS+ foi feito para o segundo trabalho. O mesmo documento registra que a Cisco "seriously evaluated RADIUS as a security protocol before it developed TACACS+", e que o TACACS+ "uses the AAA architecture, which separates AAA", de modo que o equipamento pode pedir autorização quantas vezes quiser, inclusive uma vez por comando.

## Três nomes, uma porta só

O nome é mais antigo que o protocolo. A RFC 1492, An Access Control Protocol, Sometimes Called TACACS, publicada em julho de 1993 por Finseth, da Universidade de Minnesota, documenta um protocolo inventado na ARPANET porque "there was a desire to control who could use the dial up lines": um servidor de terminais enviava usuário e senha a um servidor na porta UDP 49, ou por TCP numa porta configurável, e recebia de volta um aceite ou uma recusa, com as credenciais em texto claro. A RFC observa que "Cisco Systems terminal servers implement an extended version of this TACACS protocol", o XTACACS, com mais tipos de pedido e de resposta. O TACACS+ manteve o nome e a porta TCP 49 e trocou todo o resto. Circulou como especificação de fabricante, conhecida como "The Draft", de 1998, e só foi documentado como RFC 8907 em setembro de 2020, por Dahm e Ota, do Google, Medway Gash, da Cisco, Carrel e Grant, num documento Informational que registra o protocolo tal como ele é usado na prática. Os três não interoperam entre si, e qualquer configuração feita hoje se refere ao terceiro.

## O header e os três tipos de pacote

Todo pacote TACACS+ começa com um header (cabeçalho) de 12 bytes: a versão, major e minor, um octeto de tipo, um número de sequência, flags, um identificador de sessão e o tamanho do corpo. O tipo é 0x01 para autenticação, 0x02 para autorização e 0x03 para accounting (a contabilização), e cada tipo é uma conversa à parte, com o seu próprio identificador de sessão. Duas flags do header importam na operação. A TAC_PLUS_UNENCRYPTED_FLAG (0x01) indica que o corpo não foi ofuscado, e a RFC diz sobre ela: "This option MUST NOT be used in production." A TAC_PLUS_SINGLE_CONNECT_FLAG (0x04) negocia o modo de conexão única, em que várias sessões são multiplexadas numa mesma conexão TCP em vez de uma conexão por sessão, o que faz diferença num servidor com muita carga.

## Primeira troca: o login

Um engenheiro abre uma sessão SSH num roteador. O roteador, no papel de cliente TACACS+, envia um pacote START de autenticação. O START leva a ação, o nível de privilégio pedido, o tipo de autenticação e o serviço, além do usuário e da porta, quando são conhecidos. Os tipos de autenticação que a RFC 8907 define são o ASCII (0x01), o login interativo conduzido por prompts, e o PAP (0x02), o CHAP (0x03), o MSCHAP (0x05) e o MSCHAPV2 (0x06), para clientes que já têm em mãos a senha ou o par desafio-resposta. O servidor responde com um REPLY, e é o status desse REPLY que conduz a conversa: GETUSER (0x04) pede ao cliente que solicite o nome de usuário, GETPASS (0x05) a senha, GETDATA (0x03) alguma outra informação, e cada um deles é respondido por um CONTINUE do cliente com o que o usuário digitou; PASS (0x01) e FAIL (0x02) encerram a conversa; RESTART (0x06) pede ao cliente que recomece com outro tipo; ERROR (0x07) informa uma falha no servidor; FOLLOW (0x21) manda o cliente para outro servidor. Um login ASCII é, portanto, um pequeno roteiro interativo entre o roteador e o servidor, no qual o servidor escolhe os prompts. É assim que um servidor consegue pedir um código de uso único depois da senha sem que o roteador saiba o que é um código de uso único.

Os níveis de privilégio fazem parte do vocabulário desde o início. A RFC 8907 os define de 0 a 15, com TAC_PLUS_PRIV_LVL_USER em 0x01 e TAC_PLUS_PRIV_LVL_ROOT em 0x0f, e o nível concedido a uma sessão decide o que o equipamento chega a oferecer, antes mesmo de qualquer verificação comando a comando.

## Segunda troca: o comando

O engenheiro digita um comando de configuração. Num equipamento configurado para autorização de comandos, o roteador envia um REQUEST de autorização que descreve o que se está tentando fazer, na forma de uma lista de argumentos: nome=valor para os obrigatórios e nome*valor para os opcionais. A RFC 8907 lista os argumentos: service, "the primary service", com valores como shell, tty-server, connection, system ou firewall; cmd, "a shell (exec) command"; cmd-arg, "an argument to a shell (exec) command"; priv-lvl, "the privilege level to be assigned"; timeout e idletime, em minutos; acl, inacl e outacl, para listas de acesso; addr, para um endereço de rede; autocmd, para um comando que roda automaticamente; noescape e nohangup, como flags de sessão. Uma verificação de comando chega como service=shell com cmd=interface e cmd-arg=GigabitEthernet1/0/1, e a política do servidor decide exatamente sobre essa string.

O servidor responde com um REPLY de autorização que traz um status: PASS_ADD (0x01), o comando está liberado e os argumentos que vierem na resposta são somados aos do pedido; PASS_REPL (0x02), liberado, mas os argumentos da resposta substituem os do pedido; FAIL (0x10), negado; ERROR (0x11), o servidor não conseguiu decidir; FOLLOW (0x21), pergunte a outro servidor. Como a troca acontece a cada comando, uma política pode liberar os comandos show para todo mundo, os comandos de interface para a equipe de rede e os comandos de protocolo de roteamento para duas pessoas, citadas pelo nome. E, como os argumentos são strings, a política é escrita como padrões aplicados a linhas de comando, o que é ao mesmo tempo a força dela e a origem da maior parte das surpresas: uma abreviação, um alias ou um comando digitado a partir de outro modo gera uma string diferente.

## Terceira troca: o registro

Autorizado ou não o comando, um equipamento configurado para accounting de comandos envia um REQUEST de accounting com o mesmo tipo de argumentos, mais a hora, e uma flag: START (0x02) no início de uma tarefa, STOP (0x04) no fim, WATCHDOG (0x08) para avisar que uma tarefa longa ainda está em andamento. Para um comando isolado, o registro traz a linha de comando e a hora; para uma sessão, vem um START quando ela abre e um STOP quando ela fecha, com registros WATCHDOG no meio se ela for longa. O servidor responde com um REPLY de accounting: SUCCESS (0x01), ERROR (0x02) ou FOLLOW (0x21). A sequência desses registros, guardada no servidor, responde quem mudou o quê, em qual equipamento e quando, e é o resultado mais valioso que o TACACS+ produz; o artigo sobre accounting trata esse fluxo de registros como um projeto à parte.

## O que a ofuscação é, e o que não é

O corpo de cada pacote passa por um XOR com um pseudo-pad, uma sequência de bytes montada a partir de hashes MD5 sucessivos: o primeiro calculado sobre o identificador de sessão, a chave compartilhada, a versão e o número de sequência, e cada um dos seguintes sobre os mesmos valores mais o hash anterior. A RFC 8907 é franca de um jeito raro para um documento de protocolo. O mecanismo "is best referred to as 'obfuscation' and not 'encryption'"; o protocolo "does not include a security mechanism that would meet modern-day requirements"; e, por isso, "MUST be deployed over networks that ensure privacy and integrity", separadas do restante do tráfego. O header nunca é ofuscado, e é isso que a comparação da Cisco quer dizer com "TACACS+ encrypts the entire body of the packet but leaves a standard TACACS+ header."

Para quem opera, isso tem consequências bem concretas. O TACACS+ deve ficar numa rede de gerência ou dentro de um túnel, nunca atravessar um caminho não confiável; a chave compartilhada é um segredo tão crítico quanto o shared secret do RADIUS e deve ser trocada periodicamente, com o mesmo rigor; e a flag de corpo não ofuscado existe para debug em bancada, e para nada mais. Comparado ao RADIUS, ofuscar o corpo ainda é um avanço, já que o RADIUS esconde só o atributo de senha e manda todo o resto em claro, mas ninguém deveria dormir tranquilo confiando na criptografia própria de qualquer um dos dois protocolos.

## O problema da disponibilidade e a method list

Todo engenheiro que já operou TACACS+ se lembra do dia em que os servidores ficaram inacessíveis. Um equipamento configurado para autenticar administradores no TACACS+ recorre ao que estiver na sua method list (a lista de métodos), na ordem. Se a lista termina nos servidores, ou numa conta local que ninguém criou, ou numa conta local cuja senha foi definida há três reestruturações e nunca foi testada, ninguém consegue fazer login para consertar o que derrubou o caminho até os servidores. A disciplina é chata e não admite exceção: uma method list que termine numa credencial local testada, guardada num lugar que a pessoa de plantão consiga acessar; servidores alcançáveis por mais de uma rota, e mais de um servidor; e um exercício periódico, com os servidores propositalmente inacessíveis a partir de um equipamento de teste, em que o fallback (a alternativa de contingência) seja de fato usado. O modo de conexão única e o status FOLLOW são as contribuições do próprio protocolo para a resiliência; o resto é configuração.

## TACACS+ e RADIUS: quem faz o quê

Na maioria dos ambientes, os dois protocolos rodam a partir dos mesmos servidores de política, e a divisão hoje é regra, não discussão. O RADIUS cuida do acesso à rede: 802.1X na porta e no SSID, MAC Authentication Bypass, autenticação web, logins de VPN (rede privada virtual), tudo em que um usuário ou um dispositivo está sendo admitido e em que os métodos EAP são necessários, já que o EAP só é transportado pelo RADIUS. O TACACS+ cuida da administração de equipamentos: quem pode fazer login na infraestrutura, com que nível de privilégio, quais comandos pode rodar e o registro do que rodou. O documento da Cisco resume a diferença final numa linha, "RADIUS uses UDP while TACACS+ uses TCP", e uma conexão TCP é o formato certo para uma conversa que pode precisar de várias trocas a cada tecla digitada. O artigo sobre o RADIUS acompanha um login no outro protocolo com o mesmo cuidado.

## Fontes

- [RFC 8907, The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol, Dahm, Ota, Medway Gash, Carrel, Grant, setembro de 2020: o cabeçalho e as flags, os três tipos de pacote, o START, REPLY e CONTINUE da autenticação e os valores de status, os tipos de autenticação, os níveis de privilégio, os argumentos e status de autorização, as flags e status de contabilização, a ofuscação e a exigência de implantação, o Draft de 1998 (lida em 06/10/2026)](https://www.rfc-editor.org/rfc/rfc8907)
- [RFC 1492, An Access Control Protocol, Sometimes Called TACACS, Finseth, julho de 1993: a origem nas linhas discadas da ARPANET, a porta 49 na codificação UDP e uma porta configurável na TCP, a versão estendida da Cisco, as credenciais em texto claro (lida em 07/10/2026)](https://www.rfc-editor.org/rfc/rfc1492)
- [Cisco, TACACS+ and RADIUS Comparison, documento 13838: UDP contra TCP, o corpo cifrado e o cabeçalho padrão, o AAA separado, a autorização por comando, a avaliação do RADIUS pela Cisco antes de desenvolver o TACACS+ (lido em 06/10/2026)](https://www.cisco.com/c/en/us/support/docs/security-vpn/remote-authentication-dial-user-service-radius/13838-10.html)
- [Guia de gerenciamento de configuração do Cisco IOS XE 16, Configuration Change Notification and Logging: o registro no próprio equipamento de cada comando, quem o aplicou e quando, como complemento à contabilização de comandos (lido em 06/10/2026)](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/config-mgmt/configuration/xe-16/config-mgmt-xe-16-book/cm-config-logger.html)