Conceitos de AAA

1. A tríade AAA

O modelo AAA (Authentication, Authorization, Accounting) é o fundamento teórico sobre o qual praticamente todos os sistemas de controle de acesso em redes se baseiam. Ele é descrito formalmente na RFC 2904 (AAA Authorization Framework) e implementado principalmente pelo protocolo RADIUS (RFC 2865/2866).

2. Fluxo de mensagens RADIUS

RADIUS opera sobre UDP (portas 1812 para autenticação, 1813 para accounting — historicamente 1645/1646). A escolha de UDP, em vez de TCP, foi deliberada: como as transações são curtas e stateless, a simplicidade do UDP reduz latência e overhead no servidor.

2.1 Fluxo de autenticação (simplificado)

1. Cliente PPPoE → NAS (Mikrotik): usuário/senha (via PAP/CHAP)
2. NAS → Servidor RADIUS: Access‑Request (User‑Name, User‑Password, NAS‑IP‑Address...)
3. Servidor RADIUS → NAS: Access‑Accept (com atributos de autorização) ou Access‑Reject
4. NAS → Cliente: acesso concedido (com os atributos aplicados) ou negado
            

2.2 Fluxo de accounting

1. NAS → Servidor RADIUS: Accounting‑Request (Start) — sessão iniciada
2. NAS → Servidor RADIUS: Accounting‑Request (Interim‑Update) — periódico (ex.: a cada 5 min)
3. NAS → Servidor RADIUS: Accounting‑Request (Stop) — sessão encerrada
4. Servidor RADIUS → NAS: Accounting‑Response (confirmação)
            

O Interim‑Update é crucial para ISPs: sem ele, se o cliente desliga o modem abruptamente (sem enviar Stop), o servidor nunca saberia que a sessão acabou — o IP ficaria preso e o consumo não seria contabilizado.

3. Atributos e dicionários (Vendor‑Specific Attributes)

Cada informação em um pacote RADIUS é um atributo, identificado por um número de 8 bits (1‑255). A RFC 2865 define atributos padrão como User‑Name (1), User‑Password (2), NAS‑IP‑Address (4), Framed‑IP‑Address (8), etc.

Fabricantes podem estender o protocolo com Vendor‑Specific Attributes (VSA), encapsulados no atributo 26. É assim que existe Mikrotik‑Rate‑Limit, Cisco‑AVPair e centenas de outros. O FreeRADIUS carrega "dicionários" (dictionary.mikrotik, dictionary.cisco) que traduzem esses códigos numéricos em nomes legíveis.

4. Segurança e vulnerabilidades do RADIUS

O RADIUS foi projetado em uma época em que a segurança de rede era menos complexa, e carrega algumas limitações importantes:

• UDP sem confirmação de entrega — pacotes podem ser perdidos sem que o servidor saiba. O RADIUS depende de retransmissão e timeout configurados no NAS.
• Segredo compartilhado estático — a segurança do RADIUS se baseia em um secret configurado manualmente no NAS e no servidor. Se esse segredo vazar, um atacante pode forjar pacotes.
• Senha ofuscada, não criptografada — o atributo User‑Password é protegido por XOR com um hash MD5 do segredo + authenticator, mas isso é ofuscamento, não criptografia forte.
• Payload dos atributos em texto claro — atributos de autorização (banda, IP, VLAN) trafegam em claro, visíveis para qualquer um que capture o tráfego UDP.
• Vulnerável a replay — sem proteção adicional, um atacante pode capturar um Access‑Accept e reenviá‑lo.

Mitigações modernas: usar RadSec (RADIUS sobre TLS, RFC 6614) para criptografar todo o tráfego; restringir o acesso ao servidor RADIUS por firewall; usar segredos fortes e rotacioná‑los periodicamente; e, para ISPs, isolar o tráfego de gerência (RADIUS) em uma VLAN separada.

5. Extensões — EAP, CoA, PoD, RadSec

5.1 EAP (Extensible Authentication Protocol)

O EAP (RFC 3748) é um framework de autenticação que permite múltiplos métodos (EAP‑TLS com certificados, EAP‑TTLS, PEAP) dentro do RADIUS. É usado em Wi‑Fi corporativo (WPA2‑Enterprise, 802.1X) e pode ser aplicado em PPPoE. O FreeRADIUS implementa EAP via módulo rlm_eap.

5.2 CoA e PoD (RFC 5176)

Change of Authorization (CoA) altera atributos de uma sessão ativa sem derrubá‑la (ex.: mudar banda). Packet of Disconnect (PoD) encerra a sessão remotamente. Ambos usam a porta 3799/UDP e são essenciais para operações como corte por inadimplência ou upgrade de plano instantâneo — ver exemplos práticos na página do FreeRADIUS.

5.3 RadSec (RFC 6614)

RADIUS sobre TLS — resolve as vulnerabilidades de segurança mencionadas na seção 4. O FreeRADIUS suporta RadSec via módulo rlm_radsec. Para ISPs que precisam transportar autenticação entre PoPs via internet pública, RadSec é fortemente recomendado.

6. RADIUS vs. TACACS+ vs. Diameter

Muitos ISPs usam RADIUS para autenticação de clientes (PPPoE/Hotspot) e TACACS+ simultaneamente para controle de acesso administrativo a roteadores e switches — são propósitos complementares, não concorrentes.

7. História e evolução

RADIUS nasceu em 1991, criado pela Livingston Enterprises, para resolver o problema de autenticação centralizada de provedores de acesso discado (dial‑up). Antes dele, cada servidor de acesso (NAS) mantinha sua própria lista de usuários localmente — impossível de gerenciar em provedores com múltiplos pontos de presença. A lógica de "NAS apenas repassa a decisão a um servidor central" definida há mais de 30 anos continua sendo exatamente o mesmo modelo usado hoje em PPPoE sobre fibra óptica — a tecnologia de acesso mudou completamente, mas a arquitetura de autenticação sobreviveu praticamente intacta, prova de sua robustez conceitual.

8. O papel do NAS (Network Access Server)

O NAS é o intermediário entre o cliente final e o servidor RADIUS. No contexto brasileiro, geralmente é um roteador Mikrotik (RouterOS) ou uma BRAS dedicada. O NAS nunca toma a decisão de autenticação — apenas encapsula as credenciais do cliente em um Access‑Request e aplica o resultado (Accept/Reject + atributos). Essa separação é o que permite a um ISP trocar de fabricante de borda sem reescrever toda a lógica de autenticação: qualquer equipamento que "fale RADIUS" se integra.

9. Carga típica e dimensionamento para ISPs

Em um ISP de médio porte (~5.000 assinantes PPPoE):

• Autenticações simultâneas no pico (ex.: após queda de energia): ~200‑500 autenticações/segundo.
• Pacotes de accounting (Interim‑Update a cada 5 minutos): ~1.000 pacotes/minuto.
• Latência aceitável: < 50 ms (ideal < 10 ms em LAN).
• Requisitos de servidor: CPU moderna (4+ cores), 8 GB RAM, SSD, PostgreSQL/MariaDB otimizado.
• Replicação e alta disponibilidade: usar dois servidores RADIUS com banco replicado e IP anycast (ou balanceador).

O FreeRADIUS em hardware moderno consegue processar dezenas de milhares de autenticações/segundo — o gargalo quase sempre é o banco de dados, não o daemon.

10. Conformidade legal (LGPD e Marco Civil)

Os dados que trafegam e são armazenados pelo sistema AAA têm implicações legais diretas:

• Registros de conexão (radacct) — IP, porta, timestamps, bytes — são considerados dados pessoais pela LGPD.
• O Marco Civil da Internet (Art. 13) obriga o ISP a guardar esses registros por 1 ano, em ambiente controlado e com sigilo.
• O backup do banco RADIUS deve seguir a regra 3‑2‑1‑1‑0 e ter testes de restauração periódicos para demonstrar capacidade de recuperação (Art. 46 da LGPD).
• O acesso ao banco de dados (e ao daloRADIUS) deve ser rigidamente controlado e auditado — qualquer vazamento desses dados é um incidente de segurança reportável (Art. 48 da LGPD).

11. Glossário

12. Referências

• RFC 2865 — Remote Authentication Dial In User Service (RADIUS).
• RFC 2866 — RADIUS Accounting.
• RFC 2904 — AAA Authorization Framework.
• RFC 3748 — Extensible Authentication Protocol (EAP).
• RFC 5176 — Dynamic Authorization Extensions to RADIUS (CoA/PoD).
• RFC 6614 — Transport Layer Security (TLS) Encryption for RADIUS (RadSec).
• RFC 6733 — Diameter Base Protocol.
• NIST SP 800‑63 — Digital Identity Guidelines (framework de autenticação).
• Lei nº 12.965/2014 (Marco Civil da Internet) — Art. 13.
• Lei nº 13.709/2018 (LGPD) — Arts. 46 e 48.
• Páginas relacionadas: FreeRADIUS, daloRADIUS, LGPD, Regra 3‑2‑1‑1‑0.

Conteúdo técnico independente. Nenhum trecho é cópia literal de fonte de terceiro.