O que é a autenticação RADIUS? Como funciona e porquê
Published
A autenticação RADIUS utiliza um servidor central para decidir se um utilizador ou dispositivo pode aderir a uma rede e o que pode fazer assim que estiver dentro dela, pelo que um ponto de acesso consulta esse servidor em vez de verificar a sua própria lista de palavras-passe. No entanto, se um início de sessão for bem-sucedido, quem decide se esse dispositivo pode aceder aos sistemas dos colaboradores, utilizar apenas o acesso WiFi de convidados ou permanecer ligado indefinidamente?
Essa é a parte que uma explicação simples baseada em verificação de palavra-passe omite. O RADIUS é também um canal de políticas: o equipamento de rede recebe instruções sobre como tratar a ligação, e não apenas se a deve permitir.
Índice
- O que significa RADIUS e por que razão foi criado
- Como funciona um início de sessão RADIUS, passo a passo
- EAP-TLS e certificados para uma identidade de dispositivo forte
- Atributos RADIUS que determinam o acesso à rede
- Casos de utilização comuns do RADIUS e o que cada um determina
- Limites e equívocos a evitar
- Decida se o RADIUS se adequa à sua rede
O que significa RADIUS e por que razão foi criado
RADIUS significa Remote Authentication Dial-In User Service. Tecnicamente, é um protocolo - um conjunto partilhado de regras para a troca de mensagens - e não o próprio servidor. Um servidor RADIUS implementa essas regras e toma decisões de acesso.
Considere uma organização com pontos de acesso sem fios, switches de escritório e um gateway de acesso remoto. Se cada dispositivo mantivesse as suas próprias credenciais, os administradores teriam de atualizar listas separadas sempre que alguém entrasse ou saísse. Centralizar essas decisões disponibiliza aos equipamentos um local comum para consulta.
Esse problema é anterior ao WiFi empresarial. De acordo com a história do RADIUS, a Livingston Enterprises desenvolveu o protocolo em 1991, respondendo a um pedido da Merit Network associado ao controlo de acesso à NSFNET, uma das primeiras redes estruturais da Internet. Os servidores Dial-up podiam consultar um servidor de autenticação partilhado em vez de manterem credenciais independentes.
A lista de convidados partilhada
Pense num 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 normal do acesso aos bastidores, enquanto o local regista quem entrou e saiu.
RADIUS separa essas responsabilidades em AAA:
- A autenticação estabelece quem é o utilizador ou dispositivo.
- A autorização determina quais os serviços e recursos de rede que este pode utilizar.
- A contabilização (Accounting) regista a atividade da sessão, incluindo eventos de ligação e desligação.
A ilustração mostra a diferença entre um dispositivo que solicita acesso e o servidor que decide se o permite.
O equipamento que impõe o resultado é designado por Servidor de Acesso à Rede, ou NAS. Apesar do nome, pode ser um ponto de acesso, um comutador, um controlador sem fios ou um gateway de rede privada virtual.
Para equipas que coordenam a conetividade física e os controlos de identidade, a implementação e manutenção de banda larga da Southern Tier Resources é um recurso de infraestrutura relevante. Mantenha as responsabilidades bem distintas: instalar e manter a conetividade não é a mesma tarefa que definir quem a pode utilizar.
O RADIUS continua a ser fundamental em WiFi empresarial, acesso remoto e segurança de portas com fios porque os administradores podem separar as decisões de identidade dos equipamentos que as impõem, utilizando simultaneamente um protocolo comum entre vários fornecedores.
Como funciona um início de sessão no RADIUS, passo a passo
Comece por separar os participantes:
- Dispositivo final ou suplicante refere-se ao portátil, telemóvel ou software de autenticação que solicita acesso.
- Autenticador refere-se ao NAS que controla a ligação.
- Servidor de autenticação refere-se ao servidor RADIUS que avalia a identidade e a política.
Existe aqui uma armadilha de nomenclatura. Na documentação do protocolo, o cliente RADIUS é habitualmente o NAS, e não o portátil do colaborador. O portátil é o dispositivo final que está a tentar ligar-se.
O diagrama oferece uma vista simplificada dessas funções.
Siga o pedido e a resposta
Para implementações UDP tradicionais, a referência Wireshark RADIUS identifica o UDP 1812 para autenticação e autorização e o UDP 1813 para accounting. O UDP, User Datagram Protocol, transporta mensagens de rede individuais sem estabelecer uma ligação de transporte persistente.
O ponto de extremidade solicita acesso. Um computador portátil liga-se a WiFi empresarial, por exemplo, e o autenticador inicia a troca de identidades. O acesso normal à rede permanece controlado enquanto a autenticação prossegue.
O NAS envia um Access-Request. Encaminha as informações de autenticação e o contexto da ligação para o ponto de extremidade de autenticação RADIUS. O pedido identifica tanto a pessoa ou dispositivo que solicita o acesso como o equipamento de rede que gere a ligação.
O servidor verifica as evidências. Consoante o método de autenticação, pode consultar um diretório, validar a confiança do certificado ou utilizar um serviço de tokens. Um diretório é uma base de dados de identidades, não necessariamente o próprio servidor RADIUS.
Um desafio dá continuidade à conversação. Um Access-Challenge solicita outra troca de autenticação quando o método assim o exige. Isso não significa automaticamente que uma pessoa tenha de introduzir um código adicional.
O servidor devolve uma decisão. O Access-Accept permite o acesso e pode incluir campos de política. O Access-Reject recusa a tentativa.
O autenticador aplica a resposta. Abre a ligação controlada e aplica as instruções suportadas, tais como a colocação na segmentação de rede. Neste fluxo, o NAS aplica a decisão do servidor em vez de aprovar a identidade de forma independente.
A contabilização (accounting) regista a sessão. Mensagens separadas comunicam o início da sessão, atualizações intermédias e eventos de paragem. Estes registos ajudam os administradores a distinguir um início de sessão bem-sucedido de uma ligação que permaneceu ativa.
Regra de resolução de problemas: Localize a última troca efetuada com sucesso antes de alterar as credenciais. Um pedido que nunca chega ao servidor é um problema diferente de uma identidade rejeitada.
Utilize o filtro de visualização radius do Wireshark ou o registo de autenticação do NAS para acompanhar a sequência. Corresponda o pedido, a resposta e o contexto da sessão; verifique se o NAS aplicou a política devolvida em vez de parar numa mensagem de aceitação.
Para uma demonstração visual do processo de troca, utilize o vídeo de apoio.
EAP-TLS e certificados para uma identidade de dispositivo forte
Extensible Authentication Protocol, ou EAP, é uma estrutura para gerir uma troca de mensagens de autenticação. Na WiFi empresarial e na rede com fios WiFi 802.1X, o padrão de controlo de acesso baseado em portas, o autenticador retransmite essa troca de mensagens para o servidor dentro dos atributos RADIUS EAP-Message.
O ponto de acesso não precisa de implementar todos os métodos de autenticação por si próprio. A sua função é retransmitir a troca e aplicar o resultado.
O EAP-TLS utiliza o Transport Layer Security com certificados para autenticação mútua. O dispositivo prova a posse da chave privada do seu certificado, enquanto o dispositivo também valida o servidor. As especificações EAP do RFC Editor descrevem a autenticação baseada em certificados e como a identidade autenticada pode fundamentar a autorização e a contabilidade.
O diagrama mostra o ponto de extremidade, o ponto de acesso e o servidor de autenticação a participar nessa troca.
Os 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 ficheiro de certificado não deve ser suficiente para falsificar a identidade do dispositivo.
Ao contrário do WiFi com palavra-passe partilhada, o EAP-TLS não exige uma palavra-passe comum para os funcionários. No entanto, exige uma infraestrutura de chaves públicas gerida, ou PKI, que emita certificados e mantenha a confiança.
Incorpore o ciclo de vida na implementação:
- Emita certificados automaticamente. Utilize a gestão de dispositivos móveis, ou MDM, com o Protocolo SCEP (Simple Certificate Enrollment Protocol), ou um conector de inscrição suportado.
- Instale o certificado e o perfil de rede em conjunto para que os dispositivos saibam em que identidade de servidor confiar.
- Renove antes da expiração, incluindo para dispositivos que passem longos períodos fora do escritório.
- Revogue credenciais após perda, abate ou alteração da política de acesso, e garanta que o serviço de autenticação verifica a revogação.
- Mantenha o repositório de confiança, a lista de autoridades de certificação fidedignas e as definições de validação do servidor do dispositivo.
Para uma alternativa baseada em palavra-passe, compare o EAP-TLS e o PEAP antes de escolher um método de integração.
Certificados expirados podem causar interrupções de serviço. O mapeamento incorreto do Subject Alternative Name do certificado, um campo de identidade, pode associar um dispositivo à política errada. Um servidor inacessível ou uma alternativa com permissões excessivas pode criar perturbações ou acessos não pretendidos.
Uma identidade forte do dispositivo depende da gestão do ciclo de vida, e não apenas da seleção do EAP-TLS num menu de configuração.
Atributos do RADIUS que determinam o Acesso à rede
Os atributos de atribuição de VLAN mostram por que motivo o RADIUS é mais do que uma verificação de início de sessão. Uma rede de área local virtual, ou VLAN, é um segmento de rede lógico: os colaboradores e os convidados podem utilizar a mesma infraestrutura de acesso, recebendo acessos à rede diferentes.
Os atributos são campos identificados dentro das mensagens RADIUS. Transportam dados de autenticação, contexto de ligação e resultados de autorização; a especificação RADIUS define o mecanismo extensível de atributos que torna possíveis essas trocas de políticas.
Principais atributos do RADIUS e o que eles controlam
Estes são valores de configuração ilustrativos e não predefinições obrigatórias. O exemplo de sessão de convidado expressa a regra de tempo limite em vez de prescrever uma duração universal.
| Atributo | O que transporta | Exemplo de valor | Efeito no acesso |
|---|---|---|---|
| User-Name | Identidade apresentada | jsmith@example.com | Identifica de quem é a política aplicável |
| EAP-Message | Pacotes da troca de autenticação | dados de handshake EAP-TLS | Transporta a conversação de autenticação |
| Message-Authenticator | Verificação de integridade do pacote | Valor HMAC | Ajuda a rejeitar respostas forjadas quando necessário e validado |
| Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID | colocação de VLAN | VLAN, Ethernet, identificador de VLAN de funcionários | Coloca o dispositivo na VLAN de funcionários configurada |
| Session-Timeout | Duração máxima da sessão em segundos | Duração da sessão de visitante convertida para segundos | Termina 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 de aplicação |
| Calling-Station-Id | Endereço MAC do cliente | AA:BB:CC:DD:EE:FF | Associa a sessão a um endereço de dispositivo comunicado |
| 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 de sessão de accounting | 1A2B3C4D | Associa registos de início, intermédios e de fim |
HMAC significa código de autenticação de mensagens baseado em hash, uma verificação de integridade com chave. Não é um substituto para a encriptação do transporte.
Existem várias distinções importantes ao analisar esta tabela. O User-Name identifica a identidade declarada, mas é o método de autenticação que fornece a prova. O Calling-Station-Id fornece o contexto do dispositivo, mas um endereço de hardware comunicado não é, por si só, uma prova de identidade forte.
Para a atribuição 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 através dos caminhos de rede relevantes; a receção do seu identificador não cria o segmento.
Filter-Id nomeia uma política, em vez de transportar necessariamente as restrições em si. Um limite de largura de banda aplica-se apenas se o equipamento de aplicação suportar e mapear corretamente essa política.
Um Access-Accept não é prova de que as restrições pretendidas foram aplicadas. Verifique a VLAN, o filtro e o comportamento da sessão resultantes no NAS.
A contabilização (Accounting) adiciona a pista de auditoria. Fazer a correspondência de um identificador de sessão entre eventos de ligação ajuda os investigadores a distinguir visitas separadas da mesma identidade.
Testes as definições do NAS, segredos partilhados, retentativas e a entrega de accounting a par dos atributos. Uma verificação de identidade bem-sucedida com campos de autorização em falta ou registos incompletos concede aos administradores muito menos controlo do que o resultado do início de sessão sugere.
Casos de utilização RADIUS comuns e o que cada um decide
Um serviço RADIUS partilhado pode suportar diferentes implementações, desde que os administradores definam o método de autenticação e a política corretos para cada uma.
Implementações comuns de RADIUS e o que determinam
| Caso de utilização | Dispositivo de aplicação | O que o RADIUS decide | Método típico |
|---|---|---|---|
| WiFi para colaboradoresWiFi | Ponto de acesso ou controlador | Admite o dispositivo e seleciona a VLAN de colaboradores | EAP-TLS ou PEAP-MSCHAPv2 |
| WiFi para visitantesWiFi | Ponto de acesso com portal cativo | Concede acesso após o início de sessão e aplica limites de sessão | Início de sessão web ou perfil Passpoint/OpenRoaming |
| Acesso VPN remoto | Concentrador VPN | Verifica o utilizador e atribui uma política de grupo ou conjunto de endereços | Palavra-passe com código de utilização única ou EAP |
| Porta de switch com fios | Switch de rede | Abre a porta para dispositivos aprovados e atribui uma VLAN | EAP-TLS, ou desvio de autenticação MAC para dispositivos sem suplicante |
| Administração de dispositivos de rede | Início de sessão no router ou switch | Confirma os privilégios de administrador e suporta a contabilização; os controlos ao nível dos comandos necessitam de suporte explícito da plataforma | RADIUS ou TACACS+ com uma conta de diretório |
O PEAP-MSCHAPv2 é uma opção baseada em palavra-passe: o EAP Protegido cria um túnel TLS em torno do método interno de autenticação por palavra-passe. Requer uma validação cuidadosa do certificado do servidor e é frequentemente uma escolha de transição quando os certificados de cliente não estão implementados.
Os métodos para convidados resolvem um problema diferente. Um portal cativo apresenta uma página de início de sessão na web, enquanto o Passpoint e o OpenRoaming utilizam perfis suportados e acordos de identidade para a descoberta de rede e autenticação. Nenhum deles deve implicar um acesso ao nível dos colaboradores.
A opção de ignorar a autenticação MAC, ou MAB, verifica o endereço Media Access Control comunicado por um dispositivo quando este não consegue executar um suplicante. Como os endereços podem ser copiados, coloque estes dispositivos em segmentos restritos em vez de tratar essa verificação como equivalente à autenticação por certificado.
Acesso à rede versus acesso de administrador
O TACACS+, Terminal Access Controller Access-Control System Plus, é outro protocolo AAA comumente utilizado para a administração de equipamentos. Separa a autenticação, a autorização e a contabilização (accounting), o que se adequa a fluxos de trabalho detalhados de permissões administrativas.
O RADIUS costuma devolver a autenticação e a autorização em conjunto. O RADIUS tradicional não encripta a totalidade do pacote, enquanto o TACACS+ protege o corpo do seu pacote; nenhuma das distinções elimina a necessidade de um transporte seguro e de uma configuração sólida.
Comece pelo caso de utilização em que o acesso individual é mais crítico. Para redes de colaboradores distribuídos, uma migração multilocal de palavras-passe partilhadas para autenticação empresarial deve incluir a preparação dos pontos finais, o mapeamento de políticas e um plano de reversão testado.
Limites e equívocos a evitar
Um atacante que altere Access-Reject para Access-Accept expõe a fraqueza de tratar qualquer serviço de autenticação central como automaticamente seguro. O guia de segurança da RADIUS JumpCloud descreve como um atacante "on-path" pode explorar implementações legadas aplicáveis quando a validação do Message-Authenticator não é imposta, o risco associado ao Blast-RADIUS.
O RADIUS tradicional utiliza habitualmente UDP e mecanismos mais antigos baseados em MD5. A robustez das credenciais, a integridade da resposta e a confidencialidade do transporte são preocupações distintas: melhorar uma não resolve 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 que valores ausentes ou inválidos causam a rejeição.
- Utilize RADIUS sobre TLS, também designado por RadSec, onde for suportado, para proteger a troca entre o servidor e o NAS.
- Efetue a rotação dos segredos partilhados e proteja o seu armazenamento, ou utilize a confiança de transporte baseada em certificados quando o equipamento o suportar.
- Aplique correções (patches) nos servidores, switches, controladores e pontos de acesso. Teste a interoperabilidade após alterar os requisitos de validação.
Ponto de controlo de segurança: Verifique o que o NAS rejeita, e não apenas o que o servidor envia.
O RADIUS também não fornece autenticação multifator, ou MFA, por si só. Um fornecedor de identidades, um fluxo de trabalho de código de utilização única ou outro mecanismo integrado fornece fatores adicionais; a proposta de revisão do RADIUS da IETF discute a razão pela qual as pressuposições operacionais e de protocolo ainda são importantes nestas integrações.
Um certificado de dispositivo isoladamente não é prova de que um utilizador concluiu a MFA. A autenticação do dispositivo estabelece qual o dispositivo com credenciais que se está a ligar; a MFA do utilizador estabelece evidências adicionais sobre a pessoa.
Por fim, desativar uma identidade não termina universalmente uma ligação já ativa. A reautenticação, o término da sessão ou a Alteração de Autorização suportada, conhecida como CoA, devem impor esse resultado.
Trate o controlo de acesso WiFi como um sistema operacional: a revogação, os registos, a disponibilidade do servidor e o comportamento de contingência necessitam de testes consistentes em todos os locais.
Decida se o RADIUS se adequa à sua rede
RADIUS adequa-se quando o acesso deve seguir identidades individuais e políticas de grupo, em vez da posse de uma palavra-passe partilhada. Uma rede pequena e isolada pode não precisar da infraestrutura adicional, mas dispositivos geridos, rotatividade de pessoal e permissões distintas para convidados ou prestadores de serviços são motivos fortes para considerar esta opção.
Escolha com base nos controlos de que necessita e não no número de pontos de acesso. Um local modesto com sistemas confidenciais de colaboradores pode precisar de decisões de acesso mais rigorosas do que uma rede muito maior exclusiva para convidados.
Crie um plano de implementação viável
- Mapear grupos de acesso. Registe o que funcionários, visitantes, prestadores de serviços e dispositivos não monitorizados devem aceder.
- Verificar suporte do equipamento. Confirme atributos de RADIUS compatíveis, autenticação empresarial, transporte protegido e comportamento de accounting.
- Escolher caminhos de integração. Utilize acesso baseado em certificados para endpoints geridos e um portal adequado ou perfil de roaming para visitantes.
- Atribuir responsabilidade pelos certificados. Indique a equipa responsável por registo, renovação, definições de confiança e gestão de dispositivos perdidos.
- Definir comportamento em caso de falha. Decida se um serviço de autenticação indisponível deve bloquear o acesso ou permitir uma alternativa estritamente limitada.
- Testar antes de expandir. Inclua identidades rejeitadas, servidores indisponíveis, alterações de políticas e registos de accounting incompletos.
Um serviço gerido é uma alternativa à manutenção própria de servidores de autenticação. O nosso Cloud RADIUS em Purple Access encaminha os dispositivos para a rede aberta, segura ou de xPSK por identidade, cada um na sua própria VLAN, e rejeita um utilizador cessante cuja conta esteja desativada. O nosso cloud RADIUS inclui um SLA de disponibilidade de 99,9% no contrato.
Numa implementação para a hotelaria, a governança, a receção e a equipa de operações podem autenticar-se utilizando certificados EAP-TLS fornecidos por MDM via SCEP, receber a atribuição de VLAN por grupo de diretório e perder o acesso quando a sua conta for desativada.
Comece com um local representativo. Confirme os seus grupos, tipos de dispositivos, capacidades de aplicação e testes de falha antes de alargar a configuração a toda a infraestrutura.
O Purple Access combina Cloud RADIUS gerido, autenticação de colaboradores baseada em certificados e políticas de VLAN baseadas em identidade nos seus pontos de acesso existentes. Visite o Purple Access para debater os seus grupos de utilizadores, a integração de dispositivos e um plano prático de implementação para o seu primeiro local.
