Configurar TACACS+ para administradores na Sophos Firewall

O TACACS+ permite verificar o início de sessão de administradores identificados na Sophos Firewall através de um servidor central. Isto simplifica as regras de palavras-passe e a desativação de acessos, mas não transforma automaticamente a firewall num dispositivo de rede totalmente controlado por TACACS+: a atribuição efetiva do Device access profile permanece local no SFOS.

Por isso, o procedimento seguro separa três níveis: ligação e credenciais do servidor TACACS+, início de sessão bem-sucedido no serviço SFOS pretendido e função de administrador local na firewall. Test connection confirma apenas a ligação ao servidor e as credenciais, não o acesso posterior ao WebAdmin.

Importante: Antes da alteração, têm de estar disponíveis a conta de superadministrador local admin, um segundo caminho de gestão funcional e uma sessão de administrador local aberta. O TACACS+ não é ativado como único método antes de funcionarem o início de sessão-piloto, o teste negativo e o caminho de recuperação.

TACACS+ em dez passos

1. Testar com êxito o admin local, o MFA ou caminho de recuperação e o acesso de gestão.
2. Documentar o servidor TACACS+, o endereço de origem da firewall, a porta TCP e a conta-piloto; guardar o Shared Secret apenas no repositório de segredos aprovado, não no ticket de implementação.
3. Permitir o caminho TACACS+ apenas através de uma rede de gestão fidedigna ou de um túnel protegido.
4. Criar um TACACS+ server em Authentication > Servers > Add.
5. Verificar as credenciais e a conectividade com Test connection e depois guardar.
6. Autenticar externamente o utilizador-piloto uma vez num serviço da firewall já autorizado, para criar o respetivo objeto de utilizador.
7. Em Authentication > Users, converter de forma controlada o utilizador-piloto em administrador e atribuir um perfil mínimo de acesso ao dispositivo.
8. Em Authentication > Services > Administrator authentication methods, adicionar TACACS+, definir a ordem e manter Local como fallback consciente.
9. Testar positivamente o WebAdmin numa janela privada do navegador e negativamente com um utilizador não autorizado.
10. Só depois adicionar mais administradores, verificar os logs e testar de forma controlada uma falha do caminho TACACS+.

O que o SFOS controla com TACACS+

A Sophos Firewall utiliza o servidor TACACS+ configurado como método de autenticação para os serviços selecionados. A ajuda do SFOS 22 indica expressamente PAP e CHAP para TACACS+ na matriz de protocolos de VPN (IPsec/dial-in/L2TP/PPTP) authentication methods. Isto não significa que exista uma opção PAP ou CHAP para o WebAdmin; para administradores, selecionam-se o servidor e a ordem em Administrator authentication methods.

A ajuda atual do SFOS 22 não documenta a transferência automática de um atributo TACACS+ para um perfil de administrador da Sophos. Um utilizador de um servidor externo aparece como utilizador padrão no primeiro início de sessão e só recebe direitos de administrador após uma atribuição local. O Microsoft Entra ID SSO é uma exceção expressamente documentada, com mapeamento de funções ou grupos.

Da mesma forma, a capacidade geral do protocolo TACACS+ para Authorization e Accounting não equivale a uma SFOS Command Authorization documentada. Para este runbook, aplicam-se portanto estes limites:

• O TACACS+ verifica a identidade externa e a palavra-passe.
• O SFOS define localmente o tipo de utilizador e o perfil de acesso ao dispositivo.
• O configuration-audit.log continua a ser a prova das alterações de configuração na firewall.
• Uma autorização TACACS+ isolada não dá acesso ao WebAdmin.

Para o planeamento local de funções, consulte configurar administradores e perfis da Sophos Firewall com segurança.

Exemplo e requisitos

O exemplo utiliza:

• Server name: TACACS-HQ
• Server IP: 10.20.30.15
• Port: 49
• Utilizador-piloto: fw-noc-pilot
• Perfil de acesso ao dispositivo: NOC-ReadOnly
• Rede de gestão: 10.20.40.0/24

10.20.30.15 e 10.20.40.0/24 são valores de exemplo privados e têm de ser substituídos pelo endereço real do servidor e pela rede de gestão autorizada. TCP 49 é a porta de servidor atribuída pela IANA ao TACACS+, mas a porta introduzida no SFOS tem de corresponder exatamente à do servidor remoto. O Shared Secret não é documentado em capturas de ecrã, tickets ou neste exemplo.

Antes da configuração, é necessário esclarecer estes pontos:

• O servidor TACACS+ conhece como cliente ou Network Access Server o endereço de origem real da firewall.
• O routing e o caminho de firewall entre a firewall e o servidor funcionam nos dois sentidos.
• A conta-piloto está ativa no servidor TACACS+ e autorizada para o tipo de autenticação pretendido.
• Está preparado um perfil de acesso ao dispositivo próprio com None, Read-only e apenas o Read-write necessário.
• O WebAdmin só está acessível a partir da rede de gestão prevista.
• A conta local admin funciona de forma independente do TACACS+.
• O backup, a janela de manutenção e o caminho de recuperação estão documentados.

O perfil mínimo é criado em Profiles > Device access > Add. Cada área do menu recebe None, Read-only ou Read-write; Expand permite definir permissões mais precisas nos submenus. NOC-ReadOnly é apenas um nome de exemplo. O que conta é a matriz de permissões guardada, depois atribuída ao utilizador com User type Administrator.

O formulário atual do SFOS documenta endereço IP, porta e Shared Secret para TACACS+, mas não um seletor TLS. O RFC 8907 descreve a proteção clássica dos pacotes TACACS+ como ofuscação sem integridade, privacidade ou proteção contra repetição modernas. O caminho do servidor deve usar uma rede de gestão separada e fidedigna ou um túnel protegido, nunca a Internet sem proteção. Se só estiver disponível um transporte inseguro, a entrada em produção é interrompida.

Criar o servidor TACACS+ na firewall

Caminho do menu:

Authentication > Servers > Add

Procedimento:

1. Definir Server type como TACACS+ server.
2. Introduzir um Server name inequívoco, por exemplo TACACS-HQ.
3. Introduzir o Server IP real e o Port configurado no servidor.
4. Guardar o mesmo Shared secret utilizado no servidor TACACS+ remoto. Esta cadeia de caracteres é a palavra-passe partilhada entre a firewall, enquanto cliente, e o servidor, não a palavra-passe do utilizador-piloto.
5. Utilizar a conta-piloto autorizada em Test connection.
6. Guardar apenas se o teste for bem-sucedido.

O teste de ligação verifica as credenciais do utilizador e a ligação ao servidor. Não comprova isoladamente que o Shared Secret esteja correto, que o utilizador já tenha um perfil de administrador, que o WebAdmin esteja acessível a partir da sua rede ou que um início de sessão administrativo real funcione.

Se o teste falhar, verificar primeiro o endereço do servidor, a rota, a porta, o Shared Secret, a definição do cliente e o log do servidor. Os métodos de autenticação ou as funções de administrador não são alterados por tentativa.

Automação com a API XML: interpretar respostas de configuração por versão do SFOS

Esclarecer a contradição documental antes de escrever: Os exemplos XML para SFOS 22 e 23 mostram AuthenticationServer/TACACSServer/Port com 49 e AuthenticationServer/TACACSServer/ServerAddress. As tabelas de parâmetros indicam, pelo contrário, AuthenticationPort com o valor predefinido 1812 e ServerIP. Trata-se de uma contradição entre o exemplo e a tabela, não de uma prova de que os nomes das etiquetas sejam aliases intercambiáveis nem de um valor predefinido realmente utilizado pelo TACACS+.

Antes de qualquer escrita autorizada, verificar a referência da API da build instalada e o estado guardado do servidor. Se o esquema continuar pouco claro, esclarecê-lo primeiro com a Sophos Support; não deduzir destas entradas um pedido XML pronto a copiar. A porta TCP tem de continuar a corresponder exatamente à do servidor TACACS+ remoto. Não adotar 1812 sem verificação nem alterar o servidor para o adaptar à tabela. Após uma alteração, voltar a ler e comparar o objeto guardado; o início de sessão-piloto e o fallback local continuam a ser necessários.

As tabelas de parâmetros do SFOS 22 e 23 indicam também estes campos obrigatórios e limites de introdução:

Estes dados descrevem apenas a documentação, não um comportamento verificado em execução. Antes de uma alteração autorizada, verificar também os limites na referência da build instalada. Nunca truncar um Shared Secret existente nem alterá-lo apenas para o adaptar a esta tabela. Se houver uma divergência, interromper a alteração e esclarecer com a Sophos Support como proceder.

Ao adicionar ou editar servidores TACACS+ através da API XML, o tratamento das respostas tem de depender da versão do SFOS. A documentação da API distingue os seguintes pares de estado/identificador para Add TACACS+ server e Edit TACACS+ server:

• SFOS 22 – Add: 200/TacacsAddSuccess, 500/TacacsAddFail, 502/TacacsRecordExists, 503/TacacsAddFailDetail.
• SFOS 22 – Edit: 200/TacacsUpdateSuccess, 500/TacacsUpdateFail, 502/TacacsUpdateFailDetail.
• SFOS 23 – Add: 200/CPSuccessConfig, 400/CPInvalidRequestBody, 401/CPUnauthorized, 403/CPForbidden, 409/CPResourceConflict, 500/CPInternalServerError.
• SFOS 23 – Edit: 200/CPSuccessConfig, 400/CPInvalidRequestBody, 401/CPUnauthorized, 403/CPForbidden, 404/CPRecordNotFound, 500/CPInternalServerError.

Os números são valores de estado documentados da operação de configuração, não afirmações sobre o estado do transporte HTTP. Os nomes após / são identificadores JavaScript em bruto sob Message, não textos de mensagem resolvidos. Para o SFOS 23, a automação não deve reutilizar sem alterações as antigas correspondências 502/503. Também não está verificado que 409/CPResourceConflict indique exclusivamente uma entrada de servidor duplicada.

Antes de decidir repetir uma operação de escrita, recomenda-se voltar a ler o objeto de servidor guardado e compará-lo com a configuração pretendida. A lista de estados não garante que a repetição seja segura nem estabelece regras específicas para novas tentativas. Um resultado de configuração não substitui nem Test connection nem uma verdadeira validação do WebAdmin com um perfil mínimo atribuído localmente e uma conta de emergência disponível. Esta distinção descreve o contrato documentado da API, não um teste executado no produto.

XML Delete: verificar o alvo e o resultado separadamente. A operação específica Delete TACACS+ server identifica o servidor guardado, segundo a referência do SFOS 22/23, através de ServerName, não através de um suposto seletor de IP. A tabela de Delete indica apenas este campo: máximo de 50 caracteres, sem vírgula, UTF-8 permitido. O facto de estar assinalado como opcional não autoriza uma eliminação abrangente nem uma eliminação sem um alvo inequívoco. Antes da operação autorizada, lê-se o servidor com o nome exato, compara-se com o pedido de eliminação e verifica-se se ainda é utilizado por algum método de autenticação ou outra função. Enquanto existirem dependências ou o alvo não for claro, não se elimina. Mantêm-se o fallback local funcional e a sessão de administrador local aberta. Depois, volta-se a ler o mesmo alvo e verifica-se se foi removida exatamente a entrada cuja eliminação foi autorizada.

Para Delete, as versões documentam pares de estado/identificador próprios:

• SFOS 22 – Delete: 200/TacacsDeleteSuccess, 500/TacacsDeleteFailed.
• SFOS 23 – Delete: 200/CPSuccessConfig, 500/CPInternalServerError.

Também aqui, os números são valores de estado documentados da operação de configuração, não estados do transporte HTTP. Os nomes são identificadores JavaScript não resolvidos sob Message, não mensagens observadas em execução. As duas páginas de Delete não fornecem um envelope XML de exemplo; por isso, não se inventa um pedido Delete a partir da estrutura de Add/Edit. Continuam a prevalecer a referência da build instalada e a verificação do alvo exato antes e depois da operação. Este enquadramento documental não afirma que tenha sido executado um teste de eliminação nem que existam regras seguras para novas tentativas.

Converter com segurança o utilizador externo em administrador

Os utilizadores de servidores externos ficam visíveis em Authentication > Users depois de se autenticarem com êxito pela primeira vez num serviço da firewall. Para o piloto, utiliza-se um serviço já autorizado para o objetivo, por exemplo o User Portal ou o VPN Portal. Se não existir esse caminho, não se cria uma autorização WAN ampla apenas para criar o utilizador.

O procedimento continua limitado:

1. Autorizar o portal ou serviço de autenticação escolhido apenas a partir da rede de gestão.
2. Adicionar TACACS+ especificamente a esse método de autenticação, sem remover os fallbacks existentes.
3. Iniciar sessão uma vez com êxito como utilizador-piloto.
4. Em Authentication > Users, verificar se o objeto de utilizador externo apareceu.
5. Abrir o utilizador e definir User type como Administrator.
6. Atribuir o perfil preparado, por exemplo NOC-ReadOnly.
7. Repor as autorizações temporárias do portal ou do método que já não sejam necessárias no estado anterior documentado.

Um utilizador externo não recebe preventivamente o perfil completo Administrator. Primeiro testa-se uma função de leitura ou muito limitada. Os direitos de escrita são atribuídos apenas às contas cujas tarefas realmente os exigem.

Alterar Administrator authentication methods

Caminho do menu:

Authentication > Services > Administrator authentication methods

O TACACS+ é adicionado à lista de servidores selecionados. É possível escolher no máximo 20 servidores por método de autenticação. Se existirem vários servidores, o SFOS encaminha o pedido pela ordem apresentada. Por isso, a quantidade e a ordem fazem parte do desenho de segurança.

Para o piloto:

1. Adicionar TACACS+ à lista selecionada.
2. Mover o servidor para a posição planeada.
3. Manter Local como fallback consciente para administradores locais identificados.
4. Utilizar Apply.
5. Manter aberta a sessão admin existente.

Os Administrator authentication methods não se aplicam expressamente ao superadministrador local admin. Esta conta continua a ser o caminho de emergência independente e é protegida separadamente com uma palavra-passe forte, MFA e acesso de rede limitado.

A opção Set authentication methods same as firewall associa o início de sessão administrativo aos métodos de autenticação da firewall. Só é utilizada se essa associação for realmente pretendida e documentada. Para um piloto de administrador claro, uma lista explícita é mais fácil de testar e repor.

Validar o WebAdmin e o efeito da função

O WebAdmin utiliza por predefinição a porta HTTPS 4444; uma porta diferente aparece em Administration > Admin and user settings. Antes dos testes negativos, verificar também aí Block login: após um número suficiente de tentativas falhadas, o SFOS bloqueia o IP de origem para todos os serviços, WebAdmin, CLI, VPN Portal e User Portal. As verificações com um utilizador não autorizado e com uma palavra-passe incorreta constituem testes negativos separados. Antes de cada tentativa, são tidos em conta o limiar de bloqueio, o período de observação e as tentativas falhadas já acumuladas; os testes não são executados imediatamente um após o outro se isso puder atingir o limiar de bloqueio. Mantém-se disponível uma segunda origem de gestão ou a consola. Segundo a Sophos, um CAPTCHA falhado não conta como tentativa de início de sessão falhada.

Uma validação bem-sucedida não verifica apenas o diálogo da palavra-passe:

1. A sessão local admin permanece aberta.
2. O piloto inicia sessão numa janela privada do navegador através do FQDN WebAdmin previsto.
3. O perfil atribuído é verificado: os menus esperados estão visíveis e as áreas não autorizadas estão ausentes.
4. Com Read-only, uma alteração controlada não pode ser guardada.
5. Para uma função de escrita prevista, utiliza-se uma alteração de teste inofensiva com rollback documentado.
6. Um utilizador TACACS+ válido sem função de administrador local não pode abrir o WebAdmin.
7. Uma palavra-passe incorreta tem de ser rejeitada.
8. O admin local tem de continuar a conseguir iniciar sessão numa segunda janela privada.
9. O log do servidor TACACS+, o Log Viewer e o configuration-audit.log são correlacionados temporalmente.

A acessibilidade do WebAdmin é controlada separadamente em Administration > Device access ou através de uma Local Service ACL Exception limitada. O TACACS+ e o MFA não justificam uma autorização WAN ampla. O caminho de rede seguro é explicado em Device Access e Local Service ACL.

Verificar logs e HA

No Log viewer, filtrar pelo utilizador-piloto, IP de origem e momento do teste. Para uma análise mais profunda, são relevantes:

• access_server.log para autenticação, autorização e Accounting no SFOS
• configuration-audit.log para alterações, administrador e momento
• syslog.log para eventos do sistema ao nível do kernel; verifique os eventos do sistema e os iniciados pelo administrador em Log viewer
• o log do servidor TACACS+ para endereço do cliente, utilizador, método e resultado

Num cluster HA, não se pressupõe que uma sessão WebAdmin existente sobreviva a um failover sem interrupção. Depois de uma alteração de funções planeada, realiza-se um novo início de sessão e verifica-se no servidor TACACS+ qual o endereço de origem real da firewall. Se o servidor autorizar clientes pelo endereço de origem, todos os endereços que aparecem no caminho HA real têm de ser permitidos conscientemente.

Os logs residem no node que processou a operação. Num caso HA cujo momento não seja claro, devem ser verificados ambos os nodes ou uma avaliação consolidada.

Delimitar erros por sintoma

Test connection falha

Verificar o endereço do servidor, a rota, a porta TCP, o Shared Secret, a definição do cliente e o estado do servidor. Uma captura de pacotes pode mostrar se a firewall alcança o servidor e a Source-IP utilizada pela ligação. Sem resposta ou com uma Source-IP inesperada, não se avança para as funções de utilizador.

Test connection funciona, mas o WebAdmin rejeita o utilizador

Isto é compatível com a ausência de um perfil de administrador local. Em Authentication > Users, verificar se o utilizador existe, se User type: Administrator está definido e se tem o perfil de acesso ao dispositivo correto. Depois, controlar a ordem em Administrator authentication methods e a ACL do WebAdmin.

O servidor aceita a palavra-passe, mas aplica-se o perfil errado

Neste procedimento do SFOS, o TACACS+ não atribui automaticamente o perfil local da Sophos. Verificar o objeto de utilizador e o perfil na firewall. Não inventar atributos do servidor nem atribuir um perfil de administrador completo como teste rápido.

O início de sessão só funciona até ao failover HA

No servidor TACACS+, verificar a Source-IP real do novo início de sessão. Depois, controlar a rota, a porta, a definição do cliente e o Shared Secret para o caminho ativo. Uma sessão antiga do navegador não constitui prova de sucesso; utiliza-se uma nova sessão.

Todos os inícios de sessão de administradores externos falham

Iniciar sessão com o admin local, verificar o estado do servidor e a ordem dos métodos e, se necessário, remover TACACS+ da lista de administradores de forma controlada. Não alargar a autorização de Device Access para Any nem reiniciar o serviço de autenticação como primeiro passo.

Para um diagnóstico transversal aos métodos, consulte verificar sistematicamente a autenticação da Sophos Firewall.

Desativação e rollback

Na desativação de acesso, o utilizador é primeiro bloqueado no servidor TACACS+. Em seguida, verifica-se na firewall se ainda existe uma sessão ativa e se o objeto de utilizador externo local continua a ter um perfil de administrador. Um bloqueio no servidor não é tratado como garantia de que todas as sessões WebAdmin existentes terminem imediatamente.

Depois do teste negativo, remove-se o perfil de administrador local ou desativa-se o utilizador. Os logs de auditoria e do servidor são documentados com o ticket e o momento. A conta de superadministrador admin não faz parte deste processo normal de desativação.

Rollback de um piloto sem êxito:

1. Iniciar sessão através da sessão de administrador local mantida aberta.
2. Remover TACACS+ de Administrator authentication methods ou repor a posição anterior documentada.
3. Repor as autorizações temporárias do portal e de Device Access no estado anterior.
4. Retirar a função de administrador local ao utilizador-piloto ou desativá-lo.
5. Testar um novo início de sessão de administrador local e o caminho normal de autenticação.
6. Só depois eliminar a entrada do servidor TACACS+, desde que nenhuma outra função a utilize.

Lista de verificação

• admin local, MFA e caminho de recuperação testados
• endereço de origem real da firewall conhecido no servidor TACACS+
• porta TCP e Shared Secret coincidem
• caminho do servidor numa rede fidedigna ou protegida
• Test connection bem-sucedido, sem ser confundido com prova do WebAdmin
• utilizador-piloto visível como objeto de utilizador externo
• User type: Administrator e perfil mínimo atribuídos localmente
• Local mantido como fallback consciente
• testes WebAdmin positivo e negativo concluídos
• WebAdmin acessível apenas a partir da rede de gestão prevista
• access_server.log, log do servidor e Audit Trail correlacionados
• HA ou failover testado com um novo início de sessão
• desativação e rollback documentados

Perguntas frequentes