O que é a autenticação RADIUS? Como funciona e por que utilizar
Published
A autenticação RADIUS usa um servidor central para decidir se um usuário ou dispositivo pode ingressar em uma rede e o que pode fazer depois de estar conectado. Assim, um ponto de acesso consulta esse servidor em vez de verificar sua própria lista de senhas. Porém, se um login for bem-sucedido, quem decide se esse dispositivo pode acessar sistemas corporativos, usar apenas o acesso de visitantes à internet ou permanecer conectado indefinidamente?
Essa é a parte que uma explicação simples de verificação de senha não aborda. O RADIUS também é um canal de políticas: o equipamento de rede recebe instruções sobre como tratar a conexão, e não apenas se deve permiti-la.
Sumário
- O que o RADIUS significa e por que foi criado
- Como funciona um login do RADIUS, passo a passo
- EAP-TLS e certificados para forte identidade de dispositivos
- Atributos do RADIUS que determinam o acesso à rede
- Casos de uso comuns do RADIUS e o que cada um determina
- Limites e equívocos a serem evitados
- Decida se o RADIUS é adequado para a sua rede
O que significa RADIUS e por que foi criado
RADIUS significa Remote Authentication Dial-In User Service. Tecnicamente, trata-se de um protocolo - um conjunto compartilhado de regras para troca de mensagens - e não do servidor em si. Um servidor RADIUS implementa essas regras e toma as decisões de acesso.
Considere uma organização com pontos de acesso sem fio, switches de escritório e um gateway de acesso remoto. Se cada dispositivo mantivesse suas próprias credenciais, os administradores teriam que atualizar listas separadas sempre que alguém entrasse ou saísse. Centralizar essas decisões dá ao equipamento um local comum para consultar.
Esse problema é anterior ao WiFi corporativo. De acordo com a história do RADIUS, a Livingston Enterprises desenvolveu o protocolo em 1991, em resposta a uma solicitação da Merit Network associada ao controle de acesso à NSFNET, um dos primeiros backbones da internet. Os servidores de acesso discado podiam consultar um servidor de autenticação compartilhado em vez de manter credenciais independentes.
A lista de convidados compartilhada
Pense em um local de eventos com várias entradas. Cada porta tem um segurança, mas todos os seguranças consultam a mesma lista de convidados. A lista também pode distinguir a entrada comum do acesso aos bastidores, enquanto o local registra quem entrou e quem saiu.
RADIUS separa essas responsabilidades em AAA:
- A autenticação estabelece quem é o usuário ou dispositivo.
- A autorização determina quais serviços e recursos de rede ele pode usar.
- A contabilização (Accounting) registra a atividade da sessão, incluindo eventos de conexão e desconexão.
A ilustração mostra a distinção entre um dispositivo solicitando acesso e o servidor decidindo se o permite.
O equipamento que impõe o resultado é chamado de Servidor de Acesso à Rede, ou NAS. Apesar do nome, ele pode ser um ponto de acesso, switch, controlador wireless ou gateway de rede privada virtual.
Para equipes que coordenam a conectividade física e os controles de identidade, a implantação e manutenção de banda larga da Southern Tier Resources é um recurso de infraestrutura relevante. Mantenha as responsabilidades distintas: instalar e manter a conectividade não é a mesma tarefa que definir quem pode usá-la.
O RADIUS continua sendo fundamental em WiFi corporativo, acesso remoto e segurança de portas cabeadas porque os administradores podem separar as decisões de identidade do equipamento que as impõe, ao mesmo tempo em que usam um protocolo comum entre diferentes fornecedores.
Como funciona o login via RADIUS, passo a passo
Comece separando os participantes:
- Dispositivo final ou suplicante significa o laptop, telefone ou software de autenticação que solicita o acesso.
- Autenticador significa o NAS que controla a conexão.
- Servidor de autenticação significa o servidor RADIUS que avalia a identidade e a política.
Há uma armadilha de nomenclatura aqui. Na documentação do protocolo, o RADIUS cliente é geralmente o NAS, e não o laptop do funcionário. O laptop é o endpoint tentando se conectar.
O diagrama fornece uma visão simplificada dessas funções.
Acompanhe a solicitação e a resposta
Para implantações UDP tradicionais, a referência do Wireshark RADIUS identifica a porta UDP 1812 para autenticação e autorização e a porta UDP 1813 para bilhetagem. O UDP, User Datagram Protocol, transporta mensagens individuais de rede sem estabelecer uma conexão de transporte persistente.
O endpoint solicita acesso. Um notebook se conecta, por exemplo, ao WiFi corporativo, e o autenticador inicia a troca de identidades. O acesso comum à rede permanece controlado enquanto a autenticação é processada.
O NAS envia um Access-Request. Ele encaminha as informações de autenticação e o contexto da conexão para o endpoint de autenticação do RADIUS. A solicitação identifica tanto a pessoa ou dispositivo que busca acesso quanto o equipamento de rede que gerencia a conexão.
O servidor verifica as evidências. Dependendo do método de autenticação, ele pode consultar um diretório, validar a confiança do certificado ou usar um serviço de token. Um diretório é um banco de dados de identidades, não necessariamente o próprio servidor RADIUS.
Um desafio dá continuidade à conversa. Um Access-Challenge solicita outra troca de autenticação quando o método exige. Isso não significa automaticamente que uma pessoa precisa digitar um código adicional.
O servidor retorna uma decisão. O Access-Accept permite o acesso e pode incluir campos de política. O Access-Reject nega a tentativa.
O autenticador aplica a resposta. Ele abre a conexão controlada e aplica as instruções compatíveis, como a alocação em um segmento de rede. Nesse fluxo, o NAS aplica a decisão do servidor em vez de aprovar a identidade de forma independente.
O accounting registra a sessão. Mensagens separadas informam o início da sessão, atualizações intermediárias e eventos de interrupção. Esses registros ajudam os administradores a diferenciar um login bem-sucedido de uma conexão que permaneceu ativa.
Regra para solução de problemas: Encontre a última troca bem-sucedida antes de alterar as credenciais. Uma solicitação que nunca chega ao servidor é um problema diferente de uma identidade rejeitada.
Use o filtro de exibição radius do Wireshark ou o log de autenticação do NAS para acompanhar a sequência. Combine a solicitação, a resposta e o contexto da sessão; verifique se o NAS aplicou a política retornada em vez de parar em uma mensagem de aceitação.
Para uma explicação visual do processo de troca, assista a este vídeo explicativo.
EAP-TLS e certificados para uma forte identidade do dispositivo
Protocolo de Autenticação Extensível, ou EAP, é uma estrutura para transportar uma conversa de autenticação. Em WiFi corporativo e 802.1X cabeado, o padrão de controle de acesso baseado em porta, o autenticador repassa essa conversa para o servidor dentro de atributos RADIUS EAP-Message.
O ponto de acesso não precisa implementar todos os métodos de autenticação por conta própria. Sua função é retransmitir a troca e aplicar o resultado.
O EAP-TLS usa Transport Layer Security com certificados para autenticação mútua. O dispositivo comprova a posse da chave privada do seu certificado, enquanto também valida o servidor. As especificações de EAP do RFC Editor descrevem a autenticação baseada em certificados e como a identidade autenticada pode orientar a autorização e a contabilização.
O diagrama mostra o endpoint, o ponto de acesso e o servidor de autenticação participando dessa troca.
Certificados precisam de um proprietário
Um certificado vincula uma identidade a uma chave criptográfica pública. A chave privada correspondente deve permanecer protegida; copiar apenas um arquivo de certificado não deve ser suficiente para personificar o dispositivo.
Ao contrário do WiFi com senha compartilhada, o EAP-TLS não exige uma senha comum para a equipe. No entanto, ele exige uma infraestrutura de chaves públicas gerenciada, ou PKI, que emita certificados e mantenha a confiança.
Incorpore o ciclo de vida à implantação:
- Emita certificados automaticamente. Use o gerenciamento de dispositivos móveis, ou MDM, com o Simple Certificate Enrollment Protocol, SCEP, ou um conector de registro compatível.
- Instale o certificado e o perfil de rede juntos para que os dispositivos saibam em qual identidade de servidor confiar.
- Renove antes do vencimento, inclusive para dispositivos que passam longos períodos fora do escritório.
- Revogue as credenciais após perda, desativação ou alteração da política de acesso, e garanta que o serviço de autenticação verifique a revogação.
- Mantenha o repositório de confiança, a lista de autoridades certificadoras confiáveis e as configurações de validação de servidor do dispositivo.
Para uma alternativa baseada em senha, compare EAP-TLS e PEAP antes de escolher um método de integração.
Certificados expirados podem causar interrupções. O mapeamento incorreto do Nome Alternativo do Sujeito do certificado, um campo de identidade, pode associar um dispositivo à política errada. Um servidor inacessível ou um plano de contingência excessivamente permissivo pode criar instabilidade ou acesso não intencional.
Uma identidade de dispositivo sólida depende do gerenciamento do ciclo de vida, e não apenas da seleção de EAP-TLS em um menu de configuração.
Atributos deRADIUS que decidem o acesso à rede
Os atributos de alocação de VLAN mostram por que o RADIUS é mais do que uma verificação de login. Uma rede local virtual, ou VLAN, é um segmento lógico de rede: funcionários e visitantes podem usar a mesma infraestrutura de acesso e, ao mesmo tempo, receber diferentes níveis de acesso à rede.
Atributos são campos rotulados dentro de mensagens do RADIUS. Eles carregam dados de autenticação, contexto de conexão e resultados de autorização; a especificação do RADIUS define o mecanismo extensível de atributos que possibilita essas trocas de políticas.
Principais atributos doRADIUS e o que eles controlam
Estes são valores de configuração ilustrativos, não padrões obrigatórios. O exemplo de sessão de visitante expressa a regra de tempo limite em vez de prescrever uma duração universal.
| Atributo | O que ele transporta | Exemplo de valor | Efeito no acesso |
|---|---|---|---|
| User-Name | Identidade apresentada | jsmith@example.com | Identifica qual política se aplica |
| EAP-Message | Pacotes de troca de autenticação | Dados de handshake do EAP-TLS | Transporta a conversa de autenticação |
| Message-Authenticator | Verificação de integridade de pacote | Valor HMAC | Ajuda a rejeitar respostas forjadas quando exigido e validado |
| Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID | Alocação de VLAN | Identificador de VLAN da equipe, Ethernet, VLAN | Aloca o dispositivo na VLAN da equipe configurada |
| Session-Timeout | Duração máxima da sessão em segundos | Duração da sessão de visitante convertida para segundos | Encerra a sessão ilustrativa de visitante de oito horas |
| Filter-Id | Nome de um filtro ou política local do dispositivo | guest-limited | Seleciona as restrições configuradas no dispositivo aplicador |
| Calling-Station-Id | Endereço MAC do cliente | AA:BB:CC:DD:EE:FF | Associa a sessão a um endereço de dispositivo informado |
| NAS-IP-Address ou NAS-Identifier | Equipamento de rede solicitante | ap-floor2 como NAS-Identifier | Fornece contexto para regras específicas do local |
| Acct-Session-Id | Identificador da sessão de bilhetagem | 1A2B3C4D | Vincular registros de início, intermediários e término |
HMAC significa código de autenticação de mensagem baseado em hash, uma verificação de integridade com chave. Não é um substituto para a criptografia do transporte.
Várias distinções são importantes ao ler esta tabela. O User-Name identifica a identidade declarada, mas o método de autenticação fornece a comprovação. O Calling-Station-Id fornece o contexto do dispositivo, mas um endereço de hardware informado não é, por si só, uma prova sólida de identidade.
Para o posicionamento de VLAN, envie a combinação completa de atributos de túnel esperada pelo equipamento. A VLAN de destino já deve existir e estar acessível por meio dos caminhos de rede relevantes; receber seu identificador não cria o segmento.
Filter-Id nomeia uma política, em vez de necessariamente carregar as restrições em si. Um limite de largura de banda só se aplica se o equipamento de aplicação der suporte e mapear essa política corretamente.
Um Access-Accept não é prova de que as restrições pretendidas foram aplicadas. Verifique a VLAN resultante, o filtro e o comportamento da sessão no NAS.
O Accounting adiciona a trilha de auditoria. Fazer a correspondência de um identificador de sessão entre eventos de conexão ajuda os investigadores a distinguir visitas separadas da mesma identidade.
Teste as definições do NAS, os segredos compartilhados, as tentativas de reconexão e a entrega de contabilização juntamente com os atributos. Uma verificação de identidade bem-sucedida com campos de autorização ausentes ou logs incompletos dá aos administradores muito menos controle do que o resultado do login sugere.
Casos de uso comuns do RADIUS e o que cada um decide
Um serviço RADIUS compartilhado pode dar suporte a diferentes implantações, desde que os administradores definam o método de autenticação e a política corretos para cada uma.
Implantações comuns do RADIUS e o que elas determinam
| Caso de uso | Dispositivo de aplicação | O que o RADIUS decide | Método típico |
|---|---|---|---|
| WiFi para colaboradores | Ponto de acesso ou controlador | Admite o dispositivo e seleciona a VLAN dos colaboradores | EAP-TLS ou PEAP-MSCHAPv2 |
| WiFi para visitantes | Ponto de acesso com portal cativo | Concede acesso após o login e aplica limites de sessão | Login web ou perfil Passpoint/OpenRoaming |
| Acesso VPN remoto | Concentrador VPN | Verifica o usuário e atribui uma política de grupo ou pool de endereços | Senha com código de uso único ou EAP |
| Porta de switch cabeada | Switch de rede | Abre a porta para dispositivos aprovados e atribui uma VLAN | EAP-TLS ou bypass de autenticação MAC para dispositivos sem um supplicant |
| Administração de dispositivos de rede | Login no roteador ou switch | Confirma privilégios de administrador e suporta accounting; controles em nível de comando exigem suporte explícito da plataforma | RADIUS ou TACACS+ com uma conta de diretório |
O PEAP-MSCHAPv2 é uma opção baseada em senha: o Protected EAP cria um túnel TLS em torno do método interno de autenticação por senha. Ele exige uma validação cuidadosa do certificado do servidor e costuma ser uma escolha de transição quando os certificados de cliente não estão implantados.
Os métodos para visitantes resolvem um problema diferente. Um portal cativo apresenta uma página de login na web, enquanto o Passpoint e o OpenRoaming usam perfis suportados e arranjos de identidade para descoberta de rede e autenticação. Nenhum dos dois deve implicar acesso em nível de funcionário.
A autenticação por desvio de MAC, ou MAB, verifica o endereço de Controle de Acesso à Mídia informado por um dispositivo quando ele não pode executar um suplicante. Como os endereços podem ser copiados, coloque esses dispositivos em segmentos restritos em vez de tratar a verificação como equivalente à autenticação por certificado.
Acesso à rede versus acesso do administrador
O TACACS+, Terminal Access Controller Access-Control System Plus, é outro protocolo AAA comumente usado para administração de equipamentos. Ele separa autenticação, autorização e contabilização, o que se adéqua a fluxos de trabalho detalhados de permissões administrativas.
O RADIUS comumente retorna autenticação e autorização juntas. O RADIUS tradicional não criptografa o pacote inteiro, enquanto o TACACS+ protege o corpo do seu pacote; nenhuma dessas distinções elimina a necessidade de um transporte seguro e de uma configuração sólida.
Comece com o caso de uso onde o acesso individual é mais crítico. Para redes com equipes distribuídas, uma migração de vários sites de senhas compartilhadas para autenticação corporativa deve incluir a prontidão dos endpoints, o mapeamento de políticas e um caminho de reversão testado.
Limites e equívocos a serem evitados
Um atacante alterando Access-Reject para Access-Accept expõe a vulnerabilidade de tratar qualquer serviço de autenticação central como automaticamente seguro. As orientações de segurança da RADIUS JumpCloud descrevem como um atacante no caminho da conexão pode explorar implantações legadas aplicáveis quando a validação do Message-Authenticator não é imposta, o risco associado ao Blast-RADIUS.
O RADIUS tradicional comumente usa UDP e mecanismos mais antigos baseados em MD5. A força das credenciais, a integridade da resposta e a confidencialidade do transporte são preocupações distintas: melhorar uma delas não corrige automaticamente as outras.
Proteja a troca de políticas
- Exija a validação do Message-Authenticator para o tráfego relevante, de acordo com as orientações atuais do fornecedor. Confirme se valores ausentes ou inválidos causam a rejeição.
- Use o RADIUS sobre TLS, também chamado de RadSec, onde houver suporte, para proteger a troca entre o servidor e o NAS.
- Alterne os segredos compartilhados e proteja seu armazenamento, ou use a confiança de transporte baseada em certificado quando o equipamento oferecer suporte.
- Aplique patches em servidores, switches, controladoras e pontos de acesso. Teste a interoperabilidade após alterar os requisitos de validação.
Ponto de controle de segurança: Verifique o que o NAS rejeita, não apenas o que o servidor envia.
O RADIUS também não fornece autenticação multifator, ou MFA, por si só. Um provedor de identidade, fluxo de trabalho de código de uso único ou outro mecanismo integrado fornece fatores adicionais; a proposta de revisão do IETF para o RADIUS discute por que as premissas operacionais e de protocolo ainda são importantes nessas integrações.
Apenas um certificado de dispositivo não é prova de que um usuário concluiu a MFA. A autenticação do dispositivo estabelece qual dispositivo com credenciais está se conectando; a MFA do usuário estabelece evidências adicionais sobre a pessoa.
Por fim, desativar uma identidade não encerra universalmente uma conexão já ativa. A reautenticação, o término da sessão ou a Mudança de Autorização suportada, conhecida como CoA, devem impor esse resultado.
Trate o controle de acesso WiFi como um sistema operacional: revogação, logs, disponibilidade do servidor e comportamento de fallback precisam de testes consistentes em todas as unidades.
Decida se o RADIUS se adapta à sua rede
RADIUS é adequado quando o acesso deve seguir identidades individuais e políticas de grupo, em vez da posse de uma senha compartilhada. Uma rede pequena e isolada pode não precisar da infraestrutura adicional, mas dispositivos gerenciados, rotatividade de funcionários e permissões distintas para convidados ou prestadores de serviços são motivos fortes para considerá-lo.
Escolha com base nos controles necessários, não no número de pontos de acesso. Uma unidade modesta com sistemas corporativos confidenciais pode precisar de decisões de acesso mais rigorosas do que uma rede muito maior exclusiva para visitantes.
Crie um plano de implantação viável
- Mapeie os grupos de acesso. Registre o que funcionários, visitantes, prestadores de serviços e dispositivos não monitorados devem acessar.
- Verifique o suporte do equipamento. Confirme os atributos compatíveis de RADIUS, autenticação enterprise, transporte protegido e comportamento de bilhetagem.
- Escolha caminhos de integração. Use acesso baseado em certificados para endpoints gerenciados e um portal adequado ou perfil de roaming para visitantes.
- Atribua a responsabilidade pelos certificados. Defina a equipe responsável pelo registro, renovação, configurações de confiança e tratamento de dispositivos perdidos.
- Defina o comportamento em caso de falha. Decida se um serviço de autenticação indisponível deve bloquear o acesso ou permitir um acesso de contingência altamente restrito.
- Teste antes de expandir. Inclua identidades rejeitadas, servidores indisponíveis, alterações de políticas e registros de bilhetagem incompletos.
Um serviço gerenciado é uma alternativa à manutenção própria de servidores de autenticação. Nosso Cloud RADIUS no Purple Access direciona dispositivos para a rede aberta, segura ou de xPSK por identidade, cada um em sua própria VLAN, e rejeita quem está saindo e teve sua conta desativada. Nosso cloud RADIUS possui um SLA de 99,9% de disponibilidade no contrato.
Em uma implantação para o setor de hotelaria, as equipes de governança, recepção e operações podem se autenticar usando certificados de EAP-TLS entregues via MDM sobre SCEP, receber o posicionamento de VLAN por grupo de diretório e perder o acesso quando sua conta for desativada.
Comece com uma unidade representativa. Confirme seus grupos, tipos de dispositivos, capacidades de aplicação e testes de falha antes de estender a configuração por toda a empresa.
Purple Access combina Cloud RADIUS gerenciado, autenticação de funcionários baseada em certificados e políticas de VLAN orientadas por identidade nos seus pontos de acesso existentes. Visite o Purple Access para discutir seus grupos de usuários, a integração de dispositivos e um plano de implantação prático para o seu primeiro local.
