Pular para o conteúdo principal

Autenticação Multifator RADIUS para VPN e Wi-Fi: 2FA TOTP com o Servidor RADIUS do Casdoor

· Leitura de 11 min
Yang Luo
Yang Luo
Casdoor Maintainer

Para colocar autenticação multifator na frente de uma VPN com RADIUS, o gateway da VPN envia o nome de usuário e a senha para o servidor RADIUS usando PAP, o servidor verifica a senha e responde com um Access-Challenge, o cliente exibe um prompt e o usuário digita o código 2FA de um aplicativo autenticador em uma segunda solicitação. O Casdoor inclui um servidor RADIUS que faz exatamente isso para usuários que configuraram TOTP, então um gateway capaz de exibir um prompt Access-Challenge (o FortiGate SSL VPN é um cujo fabricante documenta isso) obtém uma senha mais um código 2FA sem nenhum software adicional. Wi-Fi com WPA2/WPA3-Enterprise é diferente: 802.1X roda sobre EAP, que não tem lugar para um código digitado, então o Casdoor tem uma opção para pular o código para esses clientes.

Se você quiser informações básicas sobre RADIUS e como ele se compara ao LDAP para dispositivos de rede, leia primeiro RADIUS vs LDAP. Este post trata da parte MFA: o que vai pela linha, quais clientes podem carregar um segundo fator e como ativá-lo no Casdoor.

Quais clientes podem fazer MFA RADIUS com o Casdoor​

A tabela lista o que cada fabricante documenta. "Suporte a Challenge" significa que o cliente exibe o prompt Access-Challenge ao usuário e envia a resposta de volta. Onde a página do fabricante que verificamos não diz, a tabela diz isso em vez de adivinhar.

ClienteMétodo de autenticação RADIUS a usar com o CasdoorSuporte a Access-ChallengeNotas
FortiGate SSL VPNPAP (defina o método para PAP, ou deixe Default, que tenta PAP primeiro)Sim, conforme a FortinetA Fortinet diz que o SSL VPN encaminha o challenge ao cliente e aguarda a resposta
FortiGate IPsec VPN (incluindo FortiClient)PAPNão encaminhado por padrãoA correção da Fortinet requer MS-CHAP no servidor RADIUS, que o Casdoor não suporta; use SSL VPN ou pule o MFA
Cisco ASA (AnyConnect / Secure Client)PAP, o padrão do ASA para todos os tipos de conexãoNão declarado no guia de configuração RADIUS do ASANão habilite password-management no tunnel group: isso muda o ASA para MS-CHAPv2
OpenVPN Access ServerPAP (ele também oferece CHAP e MS-CHAPv2)Não declarado na página de configurações RADIUSAccounting é um toggle separado, porta padrão 1813
pfSense (servidor de autenticação RADIUS, usado pelo seu OpenVPN)PAP (também MD5-CHAP, MS-CHAPv1, MS-CHAPv2)Não declarado nos docs da NetgateOs exemplos OTP da Netgate colocam o código dentro do campo de senha, que o Casdoor não aceita
WireGuardNenhumNão aplicávelPeers autenticam apenas com chaves públicas, então não há login para o RADIUS verificar
Wi-Fi, WPA2/WPA3-Enterprise (802.1X)EAP (PEAP, EAP-TTLS etc.)Sem prompt de código digitadoO Casdoor não implementa EAP; veja a seção Wi-Fi

Onde uma célula diz "não declarado", teste com o cliente VPN real antes de implantar, e verifique se o prompt aparece e se o código passa.

Por que apenas PAP pode transportar a senha que o Casdoor verifica​

RADIUS tem várias formas de enviar uma senha, e elas decidem o que o servidor é capaz de verificar.

Com PAP, o cliente coloca a senha no atributo User-Password, oculta com um hash MD5 do segredo compartilhado e do autenticador da solicitação (RFC 2865, seção 5.2). O servidor reverte isso com o mesmo segredo, obtém a senha em texto claro e pode verificá-la contra um hash armazenado ou um bind LDAP. O Casdoor lê User-Password e executa a mesma verificação de senha que sua página de login.

Com CHAP, o cliente nunca envia a senha. Ele envia um hash da senha e um desafio aleatório. A RFC 2865 afirma claramente que o CHAP precisa da senha do usuário em texto claro no servidor para recalcular esse hash. O MS-CHAPv2 tem a mesma estrutura com um hash NT. Um provedor de identidade que armazena senhas como hashes unidirecionais (a organização integrada do Casdoor usa bcrypt) não consegue verificar nenhum dos dois. O servidor RADIUS do Casdoor só lê User-Password, então uma solicitação CHAP ou MS-CHAPv2 chega sem senha e é rejeitada.

Como a ocultação do PAP é apenas MD5 com o segredo compartilhado, use um segredo aleatório longo, mantenha o RADIUS em uma rede privada ou VPN entre o gateway e o Casdoor, e ative o atributo Message-Authenticator no cliente. O Casdoor verifica Message-Authenticator quando uma solicitação o contém e assina sua resposta nesse caso, o que é a mitigação para Blast-RADIUS (CVE-2024-3596). Os detalhes estão na documentação do servidor RADIUS.

Access-Challenge vs anexar o código à senha​

Existem duas maneiras comuns de obter um código 2FA através do RADIUS.

  1. Access-Challenge. O servidor verifica a senha, depois responde com Access-Challenge, um atributo State e um Reply-Message. O cliente mostra a mensagem, o usuário digita o código e o cliente envia uma nova Access-Request com o código em User-Password e o mesmo State. A seção 4.4 da RFC 2865 também diz o que acontece em um cliente sem suporte a desafios: ele DEVE tratar o Access-Challenge como um Access-Reject.
  2. Código anexado à senha. O usuário digita password123456 no único campo de senha, e o servidor separa os últimos seis dígitos. Isso funciona com qualquer cliente, motivo pelo qual produtos criados para gateways mais antigos oferecem essa opção.

O Casdoor implementa apenas a primeira opção. Aqui está o fluxo no seu servidor RADIUS (radius/server.go):

  • A primeira Access-Request deve conter a senha correta. Um usuário com MFA ativada recebe Access-Challenge, um State aleatório e o Reply-Message please enter OTP.
  • O State é válido por 120 segundos e pode ser usado uma vez. Ele está vinculado à organização e ao nome de usuário da primeira solicitação.
  • A segunda Access-Request deve conter aquele State e o código TOTP de seis dígitos do aplicativo autenticador do usuário em User-Password. O Casdoor verifica o código contra o segredo TOTP do usuário e responde Access-Accept ou Access-Reject.
  • Códigos incorretos contam para o limite de tentativas de login fracassadas da aplicação do usuário (5 tentativas e congelamento de 15 minutos por padrão), separadamente das senhas incorretas.

Duas consequências se seguem. Um cliente que só pode fazer "senha mais código em um campo" falhará, porque o Casdoor verifica toda a string como a senha. E apenas TOTP funciona via RADIUS: códigos SMS e e-mail exigem que o Casdoor envie uma mensagem após a etapa da senha, o que o servidor RADIUS não faz. Um usuário cujo único método MFA é SMS ou e-mail recebe o desafio e depois uma rejeição, então faça com que usuários RADIUS configurem um aplicativo autenticador.

Wi-Fi: 802.1X e WPA-Enterprise​

Em Wi-Fi com WPA2-Enterprise ou WPA3-Enterprise, o ponto de acesso não coleta uma senha por si só. Ele retransmite uma conversa EAP entre o dispositivo (o supplicant) e o servidor RADIUS, e o RADIUS transporta os pacotes EAP em atributos EAP-Message. Nessa configuração, Access-Challenge já está em uso: cada ida e volta da troca EAP é um par Access-Request e Access-Challenge (RFC 3579). A RFC 3579 também diz que uma mensagem contendo EAP-Message não deve incluir Reply-Message, então não há campo para "please enter OTP" e nenhum diálogo no celular ou laptop para digitar um código.

Dois pontos práticos para o Casdoor:

  • O servidor RADIUS do Casdoor não implementa EAP. Um ponto de acesso não pode falar diretamente com ele para WPA-Enterprise. Você precisa de um servidor EAP na frente que termine o túnel TLS e encaminhe uma solicitação PAP simples. O FreeRADIUS pode fazer isso com EAP-TTLS e PAP como método interno, encaminhando a solicitação interna para outro servidor RADIUS, e os dispositivos devem ser configurados para TTLS com PAP dentro. PEAP com MS-CHAPv2, o padrão em muitos dispositivos, não funcionará contra o Casdoor pela razão mencionada na seção PAP.
  • Para esses usuários, ative Skip MFA for RADIUS na organização. O Casdoor então aceita usuários que têm MFA após a verificação da senha sozinha. A MFA na página de login web não é afetada.

Portas, segredo compartilhado e contabilização​

A RFC 2865 atribui a porta UDP 1812 à autenticação RADIUS, e a RFC 2866 atribui a 1813 à contabilização. O Casdoor escuta em uma porta UDP, radiusServerPort, e trata tanto Access-Request quanto Accounting-Request lá. Portanto, aponte a contabilização do gateway para a mesma porta da autenticação (1812 por padrão), não para 1813, ou os pacotes de contabilização não chegarão a lugar nenhum. Se o Casdoor estiver rodando em um container, publique a porta como UDP, por exemplo -p 1812:1812/udp.

O segredo compartilhado é um valor para todos os clientes, radiusSecret. Todos os gateways que falam com o Casdoor usam-no.

Para a contabilização, o Casdoor registra mensagens Start, Interim-Update e Stop em seu banco de dados (tabela radius_accounting), com o ID da sessão, tempo de sessão, endereço NAS, IP enquadrado e contadores de bytes e pacotes. Ele só faz isso para organizações com RADIUS ativado.

Configurar o Casdoor​

1. Configure as opções do RADIUS. Em conf/app.conf, ou como variáveis de ambiente com os mesmos nomes:

radiusServerPort = 1812
radiusDefaultOrganization = "my-company"
radiusSecret = "a-long-random-string-shared-with-the-gateway"

radiusDefaultOrganization é a organização que o Casdoor usa quando uma solicitação não tem o atributo Class. Se o seu gateway não puder adicionar um atributo Class às suas solicitações, essa configuração decide quais usuários da organização fazem login via RADIUS. Todas as chaves estão listadas na referência de configuração.

2. Ative o RADIUS para a organização. Na página de edição da organização, ative Enable RADIUS. Está desativado por padrão e apenas administradores globais podem alterá-lo. Enquanto estiver desativado, o Casdoor rejeita todas as Access-Request para essa organização e ignora sua contabilidade.

3. Decida sobre MFA para RADIUS. Deixe Skip MFA for RADIUS desativado para gateways VPN que suportam Access-Challenge. Ative-o para uma organização cujos clientes RADIUS não conseguem responder a um desafio, como Wi-Fi WPA-Enterprise.

4. Coloque os usuários no TOTP. Os usuários configuram um aplicativo autenticador em sua página de perfil, conforme descrito em autenticação multifator. Para torná-lo obrigatório, adicione o item TOTP com a regra Required nos itens MFA da organização. Observe a ordem: um usuário que ainda precisa configurar o MFA obrigatório ou alterar a senha primeiro é rejeitado via RADIUS até concluir isso na página de login do Casdoor.

5. Teste pela linha de comando. O radclient do FreeRADIUS envia solicitações PAP e imprime a resposta:

echo 'User-Name = "alice", User-Password = "her-password"' \
  | radclient -x casdoor.example.com:1812 auth a-long-random-string-shared-with-the-gateway

Para um usuário com TOTP, você deve ver Access-Challenge com um State e o Reply-Message. Envie o código de volta com esse State dentro de 120 segundos:

echo 'User-Name = "alice", User-Password = "123456", State = 0x...' \
  | radclient -x casdoor.example.com:1812 auth a-long-random-string-shared-with-the-gateway

Cole o valor State da primeira resposta no lugar de 0x.... Um Access-Accept significa que a configuração está correta, e o gateway é o próximo passo.

Se você também quiser que o Casdoor use um servidor RADIUS externo como segundo fator para seu próprio login web, isso é a direção oposta e é coberto pelo provedor MFA RADIUS.

Referências​