RADIUS no MikroTik RouterOS v7
Autenticação AAA para Acesso Administrativo via User Manager 

INTRODUÇÃO E ARQUITETURA DE REFERÊNCIA

Hoje vamos falar um pouco sobre autenticação em dispositivos de rede via servidor RADIUS.

A gestão descentralizada de credenciais administrativas em ambientes de Provedores de Internet (ISPs), Data Centers e redes corporativas representa uma das falhas mais críticas em arquiteturas de segurança da informação. A manutenção de contas locais espalhadas em múltiplos roteadores de borda incrementa a superfície de ataque, inviabiliza políticas eficientes de complexidade de senha e compromete a rastreabilidade e a auditoria de comandos.

A implementação de uma arquitetura centralizada baseada no protocolo RADIUS (Remote Authentication Dial-In User Service), em conformidade com as diretrizes das RFC 2865 e RFC 2866, estabelece o pilar de Autenticação, Autorização e Accounting (AAA).

Neste cenário de laboratório e validação, abordamos a integração nativa entre dois roteadores MikroTik rodando RouterOS v7:

• ROUTER BORDA (Cliente RADIUS / NAS - Network Access Server): Roteador responsável por interceptar as solicitações de acesso administrativo via WinBox, SSH ou Web e delegar a autenticação ao servidor centralizado.

• RADIUS SERVER (Servidor RADIUS / User Manager v7): Roteador dedicado executando o pacote User Manager, responsável pelo banco de credenciais, validação de regras e injeção de atributos específicos do fabricante (VSA - Vendor-Specific Attributes).

• Segmento de Rede de Interconexão: 100.65.0.0/30 (RFC 6598 - Carrier-Grade NAT / Infrastructure Block)

• IP do Cliente RADIUS (ROUTER BORDA): 100.65.0.1/30

• IP do Servidor RADIUS (RADIUS SERVER): 100.65.0.2/30

PRE-REQUISITOS E PREPARAÇÃO DO AMBIENTE (ROUTEROS V7)

No RouterOS v7, a arquitetura do User Manager foi completamente redesenhada em relação ao RouterOS v6, operando de forma integrada à CLI sob o diretório /user-manager.

Certifique-se de que o pacote user-manager esteja devidamente instalado na caixa que atuará como servidor AAA. A verificação pode ser feita via terminal:

/system/package/print where name~"user-manager"

Se o pacote não estiver instalado, instale-o via "SYSTEM>PACKAGES" ou faça o download do pacote "Extra packages" no site oficial da MikroTik correspondente à arquitetura do seu hardware/processador (x86, CHR, ARM64, etc.) e realize o upload para o armazenamento interno antes de reiniciar o equipamento.

ROUTER BORDA - CONFIGURAÇÃO DO CLIENTE RADIUS

CRIAÇÃO DE USUÁRIOS E GRUPOS E HABILITAR AUTENTICAÇÃO VIA RADIUS

Vamos criar grupos, usuários, habilitar autenticação via Radius para que a autenticação funcione corretamente.

No Winbox, vá em "SYSTEM > USERS" e na aba Groups faça a criação dos grupos conforme abaixo.Lembre-se de personalizar as permissões de acordo com cada grupo. Vou deixar um exemplo de como configurei o N1 e você faz os demais ok! O grupo "Administrators" eu preenchi com todas as permissões. Os grupos que vem por padrão("full", "write" e "read") são grupos locais, e não queremos que a autenticação procure nada localmente, portanto vamos criar grupos para serem usados com a autenticação RADIUS.

Agora com os grupos criados, com suas devidas permissões, no roteador cliente, precisamos instruir a pilha de autenticação local (módulo AAA) a consultar o servidor RADIUS para solicitações de login no equipamento.

Na aba "Users", clique na opção "AAA". Na janela que se abrirá, marque a opção "Use RADIUS". Em "Default Group" coloque o N1, que é a permissão com menos privilégios, e em "Exclude Groups", coloque o "Full", "Read" e "Write" que são os grupos locais que não usaremos.

Observe que não criamos nenhum usuário. Existe apenas o usuário administrador padrão.

Nota de Hardening e Resiliência:

Ao configurar o módulo AAA local, mantenha uma conta administrativa local de emergência gravada diretamente no roteador, protegida por cofre de senhas. Não utilize o usuário que veio de fábrica, crie um usuário com nome diferente e exclua o usuário Admin. Ao colocar o grupo N1 (flag default-group=read) garante que, se um usuário autenticar no RADIUS mas não receber o atributo VSA correto, o acesso será rebaixado para leitura, evitando a concessão indevida de privilégios de escrita.

Apontamento do Servidor RADIUS para o serviço "login"

Agora vamos Configurar o apontamento para o servidor RADIUS, ou seja, apontar o servidor onde o roteador deve buscar os usuários e validar as senhas para quem irá se autenticar via RADIUS.

No Winbox, no menu lateral, clique em "RADIUS" e na janela que se abrir, clique em "New" para adicionar o servidor de autenticação.

Se abrirá uma janelinha e preencha conforme abaixo

• Name: RADIUS - Administrators (Nome de facil leitura)

• Outer Auths: MSCHAP2 (pode ser necessário habilitar outros métodos de autenticação como o PAP, CHAP, MSCHAP etc. )

• Atributos: Mikrotik-Group:Administrators (depois do : deve ser o nome exato do grupo que você criou no outro roteador)

Agora vamos criar os usuários que se autenticarão

Na aba "Users" clique em "New" e coloque as informações do login e senha que serão utilizadas para autenticação do usuário. Em "Group", selecione o grupo que criou no passo anterior, para cada usuário conforme permissão. Como os atributos foram definidos no grupo, não é necessário configurar aqui para o usuário ok.

Agora vamos cadastrar o Roteador que utilizará os usuários que acabamos de criar.

Na aba "Routers", clique em "New". Na janela que se abrir vamos configurar da seguinte maneira:

• Name: ROUTER BORDA (Nome amigável ou hostname do roteador)

• Address: 100.65.0.1 (IP do roteador cliente)

• Shared Secret: "MikroTikRadius2026" (a mesma Secret cadastrada no roteador cliente no momento de configurar o Radius.)

PROCEDIMENTO DE TESTE E MATRIZ TÉCNICA DE TROUBLESHOOTING

Agora basta efetuar os testes. Com essas configurações você terá a ativação do serviço RADIUS em seus roteadores e um ambiente mais seguro. Caso algo tenha falhado, revise as configurações. 

A validação de um ambiente AAA em nível de engenharia exige a verificação dos pacotes em trânsito e o acompanhamento dos contadores da sessão RADIUS.

Captura de Pacotes na Interface de Interconexão (CLI)

Execute a captura rápida no cliente ou no servidor para validar a troca de mensagens UDP/1812:

/tool/sniffer/quick interface=ether2-EDGE-RT port=1812

Fluxo esperado no sniffer:

Entrada/Saída: Envio do pacote Access-Request (tamanho ~210 bytes) contendo o nome do usuário e o hash de senha do cliente para o servidor.

Saída/Entrada: Retorno do pacote Access-Accept (tamanho ~115 a 247 bytes) vindo do servidor, carregando a resposta de autorização e o atributo Mikrotik-Group.

Monitoramento de Métricas RADIUS

No roteador cliente (ROUTER BORDA), monitore o status do cliente RADIUS em tempo real:

/radius/monitor numbers=0

Observe o incremento correto dos campos "accepts" e a ausência de "timeouts" ou "resends".

Erros Comuns

Se a autenticação falhar, aqui estão alguns passos de troobleshooting a serem verificados para ajustes com os cenários de falha mais comuns encontrados durante a homologação do User Manager no RouterOS v7, acompanhada dos respectivos comandos de diagnóstico e soluções definitivas.

[CENÁRIO DE DIAGNÓSTICO 1]

Sintoma: Login failure para usuário no log do cliente sem resposta.

Causa Raiz: Divergência na chave secreta (shared secret), falta de protocolo de criptografia ou regra de firewall bloqueando tráfego UDP/1812.

Comandos de Diagnóstico(troque o nome da interface para a que fala com o Radius):

  /tool/sniffer/quick interface=ether2-EDGE-RT port=1812

  /radius monitor numbers=0

Resolução Técnica:

  1. Alinhar a chave secreta no cliente e no servidor:

    Cliente:  /radius set secret=SUA_CHAVE

    Servidor: /user-manager router set secret=SUA_CHAVE

  2. Validar se as regras em /ip firewall filter permitem o tráfego de interconexão RADIUS.

[CENÁRIO DE DIAGNÓSTICO 2]

Sintoma: Autenticação aceita (accepts: 1), mas o usuário recebe Access Denied ao conectar via Winbox/CLI.

Causa Raiz: Ausência do envio do atributo VSA Mikrotik-Group retornado pelo User Manager.

Comandos de Diagnóstico:

  /log/print where topics~"system"

Resolução Técnica:

  1. No User Manager, ajustar os atributos do grupo do usuário:

     /user-manager user group set [find] attributes="Mikrotik-Group:Administrators"

  2. Garantir que o valor do atributo corresponda exatamente ao nome do grupo local configurado no roteador (ex: Administrators).

[CENÁRIO DE DIAGNÓSTICO 3]

Sintoma: Disparo excessivo de retransmissões (resends) e timeouts no monitoramento RADIUS.

Causa Raiz: Janela de timeout padrão (300ms) insuficiente para o tempo de processamento/resposta do User Manager.

Comandos de Diagnóstico:

  /radius monitor numbers=0 (analisar contadores de retransmissão)

Resolução Técnica:

  1. No Cliente, ajustar a janela de timeout do cliente RADIUS para 2 segundos(2000ms):

     /radius set [find] timeout=2s

[CENÁRIO DE DIAGNÓSTICO 4]

Sintoma: Mensagem de log "user-manager is unscheduled" e descarte de requisições.

Causa Raiz: Serviço do User Manager desabilitado ou falha na inicialização do pacote após boot/upgrade.

Comandos de Diagnóstico:

  /user-manager/print

Resolução Técnica:

  1. Ativar explicitamente o serviço do User Manager:

     /user-manager/set enabled=yes

Debug do RADIUS e controle de sessões simultâneas

Durante o diagnóstico de autenticação RADIUS no MikroTik, o recurso de debug do RouterOS permite acompanhar as requisições enviadas ao servidor RADIUS e as respostas recebidas.

Além de auxiliar na identificação de problemas de autenticação, o debug permite identificar situações em que o usuário foi recusado porque atingiu o limite de sessões simultâneas configurado no User Manager.

Habilitando o debug do RADIUS

Para habilitar o registro detalhado das operações RADIUS:

/system logging add topics=radius,debug action=memory

Em seguida, acompanhe os eventos em tempo real:

/log print follow where topics~"radius"

Realize a tentativa de autenticação enquanto o comando estiver em execução.

Para interromper o acompanhamento dos logs:

Ctrl + C

Exemplo de uma requisição RADIUS

Durante uma autenticação, podem ser exibidas informações semelhantes a:

radius,debug new request code=Access-Request service=login

radius,debug tx to 127.0.0.1:1812 code=Access-Request id=9 service=login

radius,debug,packet tx Access-Request with id 9 to 127.0.0.1:1812

radius,debug,packet     Service-Type = 1

radius,debug,packet     User-Name = "felipe"

radius,debug,packet     MS-CHAP-Challenge = 0x...

radius,debug,packet     MS-CHAP2-Response = 0x...

radius,debug,packet     Calling-Station-Id = "10.24.20.100"

radius,debug,packet     NAS-Identifier = "SRV-RADIUS"

radius,debug,packet     NAS-IP-Address = 127.0.0.1

Essas informações mostram que o RouterOS gerou uma requisição Access-Request e a enviou para o servidor RADIUS configurado.

Identificando o limite de sessões simultâneas

O User Manager permite controlar quantas sessões simultâneas podem ser utilizadas por cada usuário.

Quando o limite configurado é atingido, o servidor pode retornar um Access-Reject acompanhado da mensagem:

simultaneous user session limit reached

Exemplo:

radius,debug rx reply code=Access-Reject service=login

radius,debug,packet rx Access-Reject with id 9 from 127.0.0.1:1812

radius,debug,packet     Reply-Message = "simultaneous user session limit reached"

A mensagem indica que o limite de sessões simultâneas configurado para o usuário foi atingido.

Verificando o limite configurado

O parâmetro responsável pelo controle é o shared-users.

Para visualizar os usuários cadastrados:

/user-manager user print detail

Um usuário configurado para apenas uma sessão simultânea pode aparecer, por exemplo, como:

name="felipe"

group=RADIUS-Administrators

shared-users=1

Nesse caso:

shared-users=1

significa que apenas uma sessão simultânea será permitida para esse usuário.

Uma segunda tentativa de autenticação enquanto a primeira sessão ainda estiver registrada poderá resultar em:

simultaneous user session limit reached

Verificando as sessões existentes

As sessões registradas no User Manager podem ser consultadas com:

/user-manager session print

Para obter informações detalhadas:

/user-manager session print detail

Esse procedimento é especialmente útil quando o limite de sessões é atingido inesperadamente. Pode existir uma sessão ainda registrada no User Manager mesmo depois de uma desconexão.

Aumentando o número de sessões simultâneas

Para permitir, por exemplo, até cinco sessões simultâneas para um usuário:

/user-manager user set [find name="felipe"] shared-users=5

A configuração pode ser confirmada com:

/user-manager user print detail where name="felipe"

O resultado deverá apresentar:

name="felipe"

group=RADIUS-Administrators

shared-users=5

Nesse exemplo, o usuário poderá manter até cinco sessões simultâneas.

Observação: o valor deve ser definido de acordo com a política de segurança e o objetivo da conta. Contas administrativas normalmente devem possuir um limite de sessões compatível com a necessidade operacional.

Retornando ao limite de uma sessão

Para limitar novamente o usuário a uma única sessão:

/user-manager user set [find name="felipe"] shared-users=1

A configuração pode ser conferida com:

/user-manager user print detail where name="felipe"

Exemplo do funcionamento

Com:

shared-users=1

o comportamento pode ser representado da seguinte maneira:

                   Usuário

                      │

                shared-users=1

                      │

              ┌───────┴───────┐

              │               │

           Sessão 1         Sessão 2

              │               │

           Permitida        Rejeitada

                              │

                              ▼

             simultaneous user session

                    limit reached

Ao alterar para:

shared-users=5

o usuário poderá manter até cinco sessões simultaneamente:

                   Usuário

                      │

                shared-users=5

                      │

       ┌──────────────┼──────────────┐

       │              │              │

    Sessão 1       Sessão 2       Sessão 3

       │              │              │

    Permitida      Permitida      Permitida

       ... até o limite configurado

Desabilitando o debug

Após concluir o diagnóstico, é recomendável remover a regra de debug para evitar a geração desnecessária de logs.

Se a regra foi criada exclusivamente para o diagnóstico:

/system logging remove [find topics~"radius"]

Depois, confirme as regras de logging:

/system logging print

Remoção seletiva

Caso existam outras regras relacionadas ao RADIUS que devam ser mantidas, é preferível identificar primeiro a regra criada para o debug:

/system logging print detail

Localize:

topics=radius,debug

action=memory

e remova somente a regra correspondente:

/system logging remove <ID>

Dessa forma, o debug pode ser habilitado somente durante o diagnóstico e desativado imediatamente após a conclusão dos testes.

CONCLUSÃO

A implementação de controle de acesso centralizado via RADIUS no RouterOS v7 atende aos requisitos rigorosos de governança e segurança em redes de grande porte. A utilização do User Manager v7 em um ativo dedicado proporciona total controle sobre as sessões administrativas, garantindo a aplicação correta de políticas de RBAC (Role-Based Access Control) por meio de atributos VSA.

Recomenda-se como boa prática de arquitetura a implementação de um servidor RADIUS secundário (redundância com prioridade alterada no /radius do cliente), além da exportação contínua de logs via Syslog (RFC 5424) para um ambiente de SIEM/Observabilidade (como Graylog ou Zabbix), assegurando conformidade com normas de auditoria e resposta a incidentes.