radius.conf - contém a configuração do servidor. Quando o servidor inicia, ele lê este arquivo e coloca seu conteúdo em um cache. Alguns dados desse cache podem ser passados para configurar variáveis e módulos. Uma vez que essa configuração foi carregada o servidor está pronto para receber, processar e enviar pacotes RADIUS. Quando o servidor é inicializado em modo de depuração (radiusd -X), essa configuração é enviada para a saída padrão e pode ser conferida.

As principais variáveis em radius.conf são:

• user - configura o usuário que executa o servidor. Normalmente radiusd. Esse usuário deve ter as permissões de leitura, mas nenhuma de gravação.
• group - configura o grupo que executa o servidor. Normalmente radiusd. Esse usuário deve ter as permissões de leitura, mas nenhuma de gravação.
• max_requests - quando o servidor recebe uma requisição, ela é inserida em uma fila para processamento. Esse valor limita o tamanho da fila evitando que o servidor entre em estado de negação de serviço. Quando esse valor é alcançado as requisições que chegam são descartadas. O valor 0 representa ilimitado e não é recomendado. A fórmula indicada pelos desenvolvedores é multiplicar o número de clientes cadastrados por 256.
• destination - essa variável controla onde o servidor deve enviar as mensagens de log. O destino pode ser um arquivo, o sistema de logs, a saída padrão ou de erro.
• file - quando usando um arquivo o padrão é ${logdir}/radius.log

Algumas configurações relacionadas ao registro de log:

• syslog_facility - os valores permitidos aqui dependem do sistema de log instalado. Consulte a documentação de syslog para detalhes. O padrão é daemon que costuma ser padrão entre diferentes sistemas operacionais.
• auth - loga um sumário para cada tentativa de autenticação com sucesso ou falha. Variáveis como auth_badpass e auth_goodpass controlam se a senha é registrada. O padrão é não registrar. Mantendo auth_badpass=yes pode ser útil em um processo de depuração.
• msg_goodpass - mantém uma mensagem customizada anexada ao sumário quando auth=yes.
• msg_badpass - mantém uma mensagem customizada anexada ao sumário quando auth=yes.

Algumas configurações relacionadas com a segurança podem controlar aspectos como permissões de arquivos e como o servidor se comporta quando percebe um ataque.

• max-attributes - normalmente cada requisição contém um pequeno número de atributos. Todavia, o formato do pacote permite que usuários maliciosos possam enviar mais de 1000 atributos em um pacote. Uma vez que cada atributo é mantido em uma estrutura de dados o servidor aloca memória criando uma condição de negação de serviço. Requisições que contém mais atributos que o valor máximo são descartadas e um log é registrado. O valor padrão é 200, que é suficiente para a maioria das operações.
• reject-delay - geralmente é útil responder rapidamente uma requisição. Todavia, quanto mais rápido seu servidor responde mais requisições são enviadas por um ataque de força bruta de dicionário. O valor padrão é 1. Cuidado, pois zero desativa essa defesa. Existem ataques que enviam dezenas de milhares de requisições por segundo! O valor definido aqui corresponde ao tempo (em segundos?) que o servidor espera antes de mandar uma resposta do tipo Access-Reject.
• status-server - alguns administradores podem achar útil uma opção que permita checar se o servidor está ativo ou não. Requisições do tipo Status-Server são respondidas com um pacote do tipo Accept-Accept ou Accounting-Request. Esse mecanismo funciona como descrito na RFC 5997. A recomendação é manter essa opção como sim (yes), caso contrário, o cliente teria dificuldade em estabelecer o estado e continuaria enviando requisições acreditando que elas foram perdidas na rede.

Alguns parâmetros são relacionados com o controle e a criação de processos (threads). O servidor usa um processo principal para receber as requisições e colocá-las em uma fila. Um pool de processos filhos é mantido para atender a fila, deste modo, FreeRADIUS é capaz de atender várias requisições simultaneamente. Muitas vezes, uma requisição fica aguardando o retorno de uma consulta a um banco de dados, neste intervalo esse processo filho fica bloqueado até que o retorno aconteça. Neste tempo outros processos filhos estão atendendo outras requisições.

A correta configuração da criação e do controle de processos filhos está diretamente ligada ao desempenho e a robustez do servidor. Como em toda otimização, existe um limite entre custo-benefício. O servidor deve ser configurado para oferecer desempenho máximo dentro de um limite de segurança aceitável. O modelo de FreeRADIUS é similar ao encontrado em Apache. Se você já configurou Apache antes, então terá um Déjà Entendu.

• start_servers - essa variável define o número de processos filhos (threads) que o servidor instância quando o processo principal é iniciado.
• max_servers - essa variável controla a quantidade de threads que podem ser executados ao mesmo tempo. Essa variável é um limite superior. Quando a mensagem a seguir aparece em seus arquivos de log é possível que o problema não esteja em FreeRADIUS, mas na rede ou no seu banco de dados.

Thread spawn failed. Maximum number of threads (32) already running

Isso significa que aumentar o valor de max_servers não resolverá o problema e pode até agravá-lo.

• {min,max}_spare_servers - essas variáveis controlam os números máximo e mínimo de servidores spare. Esses servidores devem estar desocupados (idle) aguardando por uma conexão. A ideia por trás desses spares é que: quando demandado para criar um thread o processo principal leva um tempo (que para humanos é ínfimo) mas que tem um impacto negativo no desempenho do servidor. Manter mais servidores spares mantém o desempenho.

É possível configurar seções relacionadas com os módulos. Nas versões maiores que 2.0 a configuração dos módulos é feita em arquivos separados e mantidos em raddb/modules. É recomendado manter essa configuração de módulo ao mínimo possível. A estrutura de uma seção é a seguinte:


O valor em módulo é o nome do módulo como pap, chap ou detail. Cada subseção contém zero ou mais variáveis. Uma definição é exclusiva para um módulo e não pode ser compartilhada entre diferentes módulos. Uma seção pode conter subseções e elas não podem ser compartilhadas.


Módulos podem conter instâncias, deste modo, uma instância é igual à outra versão do módulo, porém compartilhando as mesmas funcionalidades, mas com diferentes configurações. Por exemplo, se o servidor acessa dois bancos de dados diferentes, então, deverá manter duas instâncias do módulo sql com diferentes configurações. O primeiro módulo será identificado por mysql e o segundo por postgresql.


A subseção instantiate controla a ordem em que os módulos são carregados no servidor. Não é usual a dependência de um módulo por outro. Deste modo, eles podem ser carregados em diferentes ordem na maior parte das vezes. Se houver dependências a ordem passa a ser importante. Por exemplo, é preciso carregar o módulo sql primeiro para carregar mysql e postgresql depois.

O formato do arquivo é construído em torno de três elementos básicos: atribuição de variáveis, referência a módulos e variáveis e sessões. O formato de um arquivo de configuração é baseado na linha de texto, onde cada configuração é definida em uma linha de texto. Os comentários seguem o padrão do Unix e são configurados com o caractere hash ou cerquilha (#). O sinal de barra (\) força uma continuação na linha seguinte fazendo com que duas linhas representem somente uma. Por exemplo:


Tem o mesmo efeito que:


FreeRADIUS usualmente tem significados pré definidos para as variáveis. Por exemplo, raddbdir define o diretório onde o servidor armazena os arquivos de configuração. As atribuições podem ser um valor inteiro, uma cadeia de caracteres, uma rota completa para um arquivo, etc. A atribuição pode ser feita com múltiplos formatos. Uma cadeia de caracteres pode ser passada sem aspas, com aspas simples ou duplas. Como em:


O segundo exemplo inclui os espaços em branco entre os números da mesma forma que o terceiro. A diferença do segundo para o terceiro é que eventuais variáveis incluídas entre aspas duplas são expandidas por seus valores de conteúdo. Expansão de variáveis é um recurso útil para criar variáveis de referência quando um valor é utilizado por muitas variáveis.

Por exemplo, uma rota para um diretório de configuração pode levar a vários arquivos. Configurando a variável logdir podemos usar seu conteúdo para simplificar a criação de outras variáveis. Por exemplo:


Sessões definem grupos lógicos de variáveis. Um administrador pode dar um nome lógico para uma sessão e definir variáveis padronizadas para essa sessão.


Existem sessões padronizadas em FreeRADIUS, por exemplo, a sessão cliente (client). O conceito é parecido com objeto na programação orientada a objetos. Observe:


No exemplo anterior são criados dois clientes (foo e bar). Há uma série de nomes de sessão como client, home_server_pool, home_server e realm que são reconhecidos pelo servidor.

Os arquivos de configuração podem ser dividido em vários arquivos. Esses arquivos de configuração podem ser inseridos em tempo de carregamento com uma diretiva de inclusão ($INCLUDE).


(Continua na parte III) - Kyetoy