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.
RELIANOID irá compartilhar as mensagens do protocolo RADIUS entre todos os servidores RADIUS, estejam eles em sites diferentes ou locais. Nas seções seguintes explicamos a configuração deste tipo de ambientes, as verificações avançadas de saúde dos serviços RADIUS e os desafios de segurança deste 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).
De acordo com o relatório 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 TODAS 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 #
Uma verificação avançada está incluída em RELIANOID com nome check_radius sob a pasta padrão / usr / local / zenloadbalancer / app / libexec /.
A ajuda deste comando pode ser listada:
root@noid5# /usr/local/zenloadbalancer/app/libexec/check_radius --help Testa se um servidor RADIUS está aceitando conexões. Uso: check_radius -H host -F config_file -u nome de usuário -p senha [-P porta] [-t tempo limite] [-r tentativas] [-e esperar] [-n nas-id] [-N nas-ip-addr ] Opções: -h, --help Imprime tela de ajuda detalhada -V, --version Imprime informações da versão --extra-opts=[seção][@arquivo] Lê opções de um arquivo ini. Consulte https://www.monitoring-plugins.org/doc/extra-opts.html para uso e exemplos. -H, --hostname=ADDRESS Nome do host, endereço IP ou soquete unix (deve ser um caminho absoluto) -P, --port=INTEGER Número da porta (padrão: 1645) -u, --username=STRING O usuário para authenticate -p, --password=STRING Senha para autenticação (RISCO DE SEGURANÇA) -n, --nas-id=STRING identificador NAS -N, --nas-ip-address=STRING Endereço IP NAS -F, --filename= STRING Arquivo de configuração -e, --expect=STRING String de resposta a ser esperada do servidor -r, --retries=INTEGER Número de vezes para tentar novamente uma conexão com falha -t, --timeout=INTEGER Segundos antes do tempo limite da conexão expirar (padrão: 10) Este plugin testa um servidor RADIUS para ver se ele está aceitando conexões. O servidor a ser testado deve ser especificado na chamada, bem como um nome de usuário e uma senha. Um arquivo de configuração também pode estar presente. O formato do arquivo de configuração está descrito nas fontes da biblioteca radiusclient. A opção de senha apresenta um problema de segurança substancial porque a senha pode ser determinada observando cuidadosamente a linha de comando em uma listagem de processos. Este risco é exacerbado porque o plugin normalmente será executado em intervalos regulares previsíveis. Certifique-se de que a senha usada não permite acesso a recursos confidenciais do sistema.
Primeiramente, vamos verificar se está funcionando corretamente executando o seguinte comando de exemplo (use seus próprios parâmetros de configuração do cliente radius em RELIANOID):
root@noid5# cd /usr/local/zenloadbalancer/app/libexec/ root@noid5# ./check_radius -H -P -você -p -F
A prova será feita a partir de RELIANOID dispositivo 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 RELIANOID 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 existem algumas dificuldades nesta opção, pois a camada de aplicação não tem conhecimento das políticas de segurança, pois estão implícitas na camada de rede. Para usar esta abordagem com RELIANOID é 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 RELIANOID, 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, RELIANOID não oferece suporte a 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!
