Autenticação e escalabilidade do RADIUS (Remote Dial-In User Service)

POSTADO POR Zevenet | 3 de outubro de 2017

Visão geral

RAIO or Serviço de Usuário de Discagem de Autenticação Remota é um protocolo de rede que fornece autenticação, autorização e contabilidade de usuários e dispositivos de gerenciamento centralizado. É amplamente utilizado por provedores de serviços de Internet e empresas para controlar o acesso à Internet, serviços locais, redes sem fio através de pontos de acesso WiFi, etc.

O protocolo RADIUS é implementado na camada de aplicação com uma arquitetura cliente-servidor que pode usar TCP ou UDP como camada de transporte e é comunicada com um banco de dados de usuários como Active Directory, Serviço LDAP or Sistema de contabilidade Linux. As soluções RADIUS mais populares são o FreeRadius ou o Microsoft NPS Radius Server.

Protocolo de mensagens RADIUS

O protocolo de mensagens é baseado na solicitação do cliente e na forma de resposta do servidor, conforme mostrado abaixo.

1. Cliente envia um Pedido de Acesso para o servidor para cada usuário ou dispositivo a ser autenticado na porta do servidor TCP / UDP 1812 (versões mais antigas do servidor usariam 1645 para autenticação também).
2. Respostas do servidor de acordo com a política Acesso Aceito se a autenticação for permitida, Acesso-Rejeitar se o acesso não for permitido ou Acesso-Desafio se o servidor precisar de mais informações para determinar o acesso (como uma segunda validação: PIN, senha, certificado, etc.)

Opcionalmente, o cliente e o servidor poderiam trocar mensagens de contabilidade como Pedido de Contabilidade e Contabilidade-Resposta para manter um identificador de sessão exclusivo.

3. Cliente envia um Pedido de Contabilidade para o servidor através da porta TCP / UDP 1813 para gerenciamento de sessão contábil (versões mais antigas do servidor 1646 para autenticação também).
4. Servidor responde com um Contabilidade-Resposta mensagem para confirmar a nova sessão.

Em um ambiente RADIUS, um serviço adicional para o gerenciamento de bancos de dados de usuários será necessário e importante para ser considerado em alta disponibilidade, que será tratado em outro artigo específico.

Ambiente de balanceamento de carga e alta disponibilidade do RADIUS

O problema se um serviço RADIUS ficar inativo pode gerar o risco de os usuários não conseguirem acessar a rede de servidores ou fazer login em um aplicativo, os usuários não conseguirem abrir uma sessão em um dispositivo ou conseguir a autorização para usar um direito em um processo de negócios. Para solucionar esse tipo de situação, o objetivo deste artigo é configurar o ambiente mostrado a seguir.

Zevenet irá compartilhar as mensagens do protocolo RADIUS entre todos os servidores RADIUS, sejam eles em sites diferentes ou locais. Nas seções a seguir, explicaremos a configuração desse tipo de ambiente, as verificações de integridade avançadas para serviços RADIUS e os desafios de segurança desse protocolo.

Configuração de serviço virtual RADIUS

A natureza do protocolo RADIUS é baseada em pacotes UDP, então a configuração de um ambiente RADIUS confiável é construída com um LSLB fazenda com L4xNAT perfil na camada 4, portas 1812 e 1813, tipo de protocolo UDP e preferido DTA para ter transparência e obter o IP do cliente no backend (embora NAT deve funcionar perfeitamente também).

Na série Serviços, nenhuma persistência é necessária por padrão, a menos que seja necessária alguma rigidez entre o servidor client-radius.

Se o RADIUS for usado através do TCP em vez do UDP, ele poderá ser alterado no campo de tipo de protocolo. Pode ser definido também TODOS protocolos para permitir o TCP e o UDP ao mesmo tempo do mesmo IP virtual.

Por fim, configure os back-ends sem nenhuma porta configurada (pois usará a porta de destino da conexão do cliente) e teste a conexão. Assim que o serviço virtual RADIUS for configurado com sucesso, podemos definir a verificação de integridade avançada para este serviço.

Configuração de verificação de saúde avançada do RADIUS

Um cheque avançado está incluído no Zevenet com nome check_radius sob a pasta padrão / usr / local / zenloadbalancer / app / libexec /.

A ajuda deste comando pode ser listada:

root@zevenet5# /usr/local/zenloadbalancer/app/libexec/check_radius --help
Tests to see if a RADIUS server is accepting connections.

Usage:
check_radius -H host -F config_file -u username -p password
			[-P port] [-t timeout] [-r retries] [-e expect]
			[-n nas-id] [-N nas-ip-addr]

Options:
 -h, --help
    Print detailed help screen
 -V, --version
    Print version information
 --extra-opts=[section][@file]
    Read options from an ini file. See
    https://www.monitoring-plugins.org/doc/extra-opts.html
    for usage and examples.
 -H, --hostname=ADDRESS
    Host name, IP Address, or unix socket (must be an absolute path)
 -P, --port=INTEGER
    Port number (default: 1645)
 -u, --username=STRING
    The user to authenticate
 -p, --password=STRING
    Password for autentication (SECURITY RISK)
 -n, --nas-id=STRING
    NAS identifier
 -N, --nas-ip-address=STRING
    NAS IP Address
 -F, --filename=STRING
    Configuration file
 -e, --expect=STRING
    Response string to expect from the server
 -r, --retries=INTEGER
    Number of times to retry a failed connection
 -t, --timeout=INTEGER
    Seconds before connection times out (default: 10)

This plugin tests a RADIUS server to see if it is accepting connections.
The server to test must be specified in the invocation, as well as a user
name and password. A configuration file may also be present. The format of
the configuration file is described in the radiusclient library sources.
The password option presents a substantial security issue because the
password can possibly be determined by careful watching of the command line
in a process listing. This risk is exacerbated because the plugin will
typically be executed at regular predictable intervals. Please be sure that
the password used does not allow access to sensitive system resources.

Em primeiro lugar, vamos verificar se está funcionando corretamente executando o seguinte comando de exemplo (por favor, use seus próprios parâmetros de configuração do cliente radius do Zevenet):

root@zevenet5# cd /usr/local/zenloadbalancer/app/libexec/
root@zevenet5# ./check_radius -H <RADIUS_SERVER_IP> -P <RADIUS_SERVER_PORT> -u <DUMMY_USER_NAME> -p <DUMMY_USER_PASSWD> -F <RADIUS_CLIENT_CONFIG_FILE>

O teste será feito a partir do dispositivo Zevenet para um determinado servidor RADIUS com uma validação de usuário fictícia e, opcionalmente, um arquivo de configuração do cliente para parâmetros específicos do cliente. Vamos testar o comando, e então, quando obtivermos o OK do servidor e do FALHA quando estiver inativo, podemos configurar a verificação de saúde avançada no Serviços seção de nosso recém-criado serviço virtual.

Não se esqueça de usar o HOST token ao configurar as verificações de integridade avançadas em Zevenet conforme abaixo.

check_radius -H HOST -P 1812 -u johndoe -p johnspass -F /etc/radius_client.cfg

Veja abaixo o Serviços configuração de seção.

Opções de segurança do RADIUS

O protocolo RADIUS tradicionalmente usa algoritmos MD5 para autenticação por pacote e verificações de integridade por UDP. Como esses dois não fornecem nenhuma criptografia de segurança e proteção, várias abordagens foram estudadas.

Implantações do RADIUS ao longo IPsec or Internet Protocol Security foram amplamente implantados, mas há algumas dificuldades dessa opção, pois a camada de aplicativo não está ciente das políticas de segurança, pois está implícita na camada de rede. Para usar esta abordagem com Zevenet, é necessária alguma configuração manual, pois ainda não está integrado.

A especificação de DTLS or Segurança da Camada de Transporte do Datagrama permite fornecer criptografia, monitorar e controlar as políticas de segurança de tal tráfego.

Outra opção seria o RADIUS TLS que fornece recursos TCP de confiabilidade e camada de transporte em ordem.

Para este tipo de abordagens, o IANA criou uma entrada oficial para RadSec (Segurança RADIUS) para usar o UDP 2083 porta para RADIUS / TLS implementações.

Outra opção seria melhorar a camada de digestão e autorização com EAP (Protocolo de Autenticação Extensível) que não é usado na camada de estabelecimento do link, mas durante a fase de autenticação da conexão, evitando o uso de resumos fracos do MD5.

Além disso, com o Zevenet, os serviços RADIUS podem ser protegidos com o módulo IPDS contra pacotes e hosts maliciosos, ataques DoS, tentativas de força bruta e muito mais.

Recursos de proxy RADIUS

Se vários servidores RADIUS forem implantados em sites diferentes, seria interessante encaminhar a conexão do cliente para o site que gerencia seus dados de autenticação, autorização e contabilidade. Atualmente, o Zevenet não suporta recursos de proxy RADIUS, mas está planejado para ser incluído em breve. Aguarde os últimos desenvolvimentos!

Aproveite os seus serviços de acesso à rede altamente disponíveis e escaláveis!

Compartilhar no:

Documentação sob os termos da Licença de Documentação Livre GNU.

Esse artigo foi útil?

Artigos Relacionados