Pular para o conteúdo principal
Version: 3.21

senhasegura.go for Linux

Introdução​

Os sistemas operacionais baseados em Linux possuem um padrão de permissionamento amplamente conhecido e de fácil compreensão. Sua segregação pelas entidades "dono", "grupo" e "outros", combinado com as ações de escrita, leitura e execução, reduz a possibilidade de granularização em ambientes onde nem mesmo um usuário privilegiado poderia executar mudanças que coloquem em risco o funcionamento de um sistema crítico.

Seria realmente desastroso se um administrador de infraestrutura, por ventura, modifica-se um arquivo de conexão de banco de dados, de responsabilidade de um DBA e amplamente utilizado por sistemas hospedados neste mesmo servidor.

Algumas ferramentas já conhecidas de mercado entregam um melhor controle sobre as ações que ocorram na camada de aplicação, sistema de arquivos e até mesmo kernel. Mas são demasiadamente complicados e descentralizados.

Para aumentar a governança destes ativos, o senhasegura.go for Linux , utilizando da tecnologia CaitSith1, atua como um PEDM, conseguindo integrar toda facilidade de gestão Web com tomadas de decisão centralizadas e replicadas ao parque de dispositivos por ele geridos. Entregando ao profissional de segurança uma poderosa ferramenta que permita aumentar a granularização de ações nos dispositivos Linux ao nível de ações da Kernel.

Objetivo​

Neste capítulo iremos abordar as seguintes funcionalidades do senhasegura.go for Linux

  • Instalação em dispositivo alvo: Ensinaremos como instalar o agente nos dispositivos linux alvo e como vincula-los ao senhasegura

  • Controle de ação em nível de kernel: Apresentaremos como cadastrar as diretivas de proteção e ver na prática sua efetividade

  • Pontos de atenção e solução de problemas: Alguns pontos importantes sobre esta solução e procedimentos de correção em casos de erro de configuração

Preparando o senhasegura para receber o dispositivo alvo​

O agente por sí só não irá integrar-se ao senhasegura sem que antes este tenha informações necessárias sobre qual é o dispositivo a gerenciar.

Sendo assim, iremos demonstrar como preparar o senhasegura com as informações necessárias.

Criando chaves de acesso ao WebService A2A​

caution

É necessário um prévio conhecimento de como criar Clientes, Tokens e de como configurar os recursos desejados. Consulte o Manual do Desenvolvedor ou o Manual do Administrador da Ferramenta para mais detalhes.

caution

Recomendamos que o usuário do senhasegura criado para ser vinculado à configuração WebService A2A não tenha Perfil ou Grupo de acesso vinculado. Pois este não será utilizado para login das interfaces proxy, web, ou utilizado para resgate de informações sensíveis.

  1. Deste ponto entendo que você já criou o usuário, cliente e token WebService A2A que o senhasegura.go for Linux irá utilizar.

  2. Na tela de configuração de recursos do cliente WebService A2A (Settings ➔ Services ➔ API ➔ Tokens), vincule o recurso Linux.Go! ao registro criado anteriormente.

  3. Caso tenha um usuário no servidor destino que necessite ser monitorado, é necessário que cadastre este username como usuário do senhasegura .

    Tal qual o usuário do serviço, este usuário não necessita de Perfil de acesso e Grupo de acesso.

    Caso este username já seja um usuário do senhasegura , não há necessidade de modificações. A auditoria só se faz em dispositivos autorizados.

Agora, será necessário instalar o agente. Posteriormente retornaremos as telas de administração para aprovar usuários e dispositivos detectados.

Instalação do agente​

info

O agente do senhasegura.go for Linux será disponibilizado pela equipe de Serviços do senhasegura . Entre em contato através do senhasegura PAM Solution para mais detalhes.

caution

O agente do senhasegura.go for Linux da suporte para as distribuições Debian e Ubuntu

Ao fazer a instalação do agente deverá ser solicitada uma chave de instalação, esta chave pode ser encontrada no menu: Go ➔ Configurações ➔ Instaladores.

Dependências​

Para o nosso exemplo, utilizaremos o sistema operacional Debian2.

info

Caso deseje utilizar o senhasegura.go for Linux em outro sistema operacional baseado em Linux, entre em contato via senhasegura PAM Solution para que lhe endereçamos instruções específicas para cada sistema.

Garanta que seu sistema tenha instalado os seguintes pacotes: GCC3, make4, DKMS5, linux-headers6, libjansson47, libcurl38 e libconfig99.

No caso do Debian, execute o comando abaixo para garantir sua instalação:

$ sudo apt-get install gcc make dkms 
linux-headers-$(uname -r) libjansson4 libcurl3 libconfig9
caution

Para realizar a instalação a versão do kernel deve ser a mesma versão disponível do linux-headers. Utilize o seguinte comando para verificar os pacotes disponíveis: apt list -a linux-headers*

Instalação​

Assim que as dependências forem supridas, execute o instalador secpack-installer.run.

$ sudo /bin/bash secpack-installer.run

A instalação exibirá diversas mensagens informando as tarefas que estão sendo executadas. Essas mensagens serão importantes caso um erro venha a ocorrer. Se concluída com sucesso, a mensagem Installation completed! será apresentada. Caso contrário, entre em contato conosco tendo em mãos as saídas apresentadas durante o processo de instalação para que possamos apoia-lo.

Uma vez instalado, é necessário configura-lo com os dados de conexão WebService A2A criados anteriormente.

Edite o arquivo /etc/senhasegura/secpack.conf e preencha os campos abaixo com os valores solicitados.

  • iso_http_address: URL do WebService A2A . Como de costume, será a URL que você utiliza para acessar a interface web do senhasegura mais o sufixo /iso. Exemplo: https://senhasegura.mycompany/iso.

  • iso_oauth_key: Identificador do cliente WebService A2A criado anteriormente

  • iso_oauth_token: Token do cliente WebService A2A criado anteriormente

Agora iremos solicitar registro deste dispositivo ao senhasegura executando o comando secpack-register com usuário privilegiado.

$ sudo secpack-register

Caso você se depare com a mensagem de erro Failed to sign workstation. -- como a demonstrada abaixo -- verifique se os passos de configuração do cliente WebService A2A foram corretamente executados e se o dispositivo alvo realmente tem acesso ao senhasegura através de conexão HTTPS (443). Em caso de dúvidas, entre em contato via senhasegura PAM Solution para apoiarmos na solução do problema.

root\@debian:/root# secpack-register 
senhasegura security pack v1.0.0-1 
Failed to sign workstation.

Em caso de sucesso, você receberá a mensagem This device was registered successfully., como no exemplo abaixo: 

root\@debian:/root# secpack-register 
senhasegura security pack v1.0.0-1 
ERROR: 1002: Registration of pending approval workstation 
Adding group gonix\...
This device was registered successfully.

A mensagem ERROR: 1002: Registration of pending approval workstation indica que este dispositivo ainda não foi aprovado pelo gestor do senhasegura para receber informações de bloqueio e auditoria. Veremos isso em seguida.

Validação​

Uma vez instalado, o serviço secpack-maestro deve estar em execução. Valide-o com o comando service secpack-maestro status.

A mensagem de erro 2037: Incorrectly informed users ocorre quando nenhum usuário presente no dispositivo tem correlação com os usuários aprovados na interface administrativa do senhasegura.go for Linux no senhasegura . Resolveremos isso adiante.

Valide apenas que o serviço esteja em execução através das diretivas Loaded e Active.

Criando as primeiras diretivas​

Deste ponto em diante, o dispositivo alvo já está informando ao senhasegura quais usuários ele possuí e solicitando diretivas de bloqueio e auditoria. Iremos então aprovar o dispositivo e cadastrar nossa primeira diretiva.

Autorizando dispositivos​

Através do menu go ➔ Workstations você terá a relação de dispositivos que estão utilizando as diretivas do senhasegura.go for Linux , dispositivos que tiveram permissão revogada e dispositivos que estão com permissão pendente de aprovação. Neste nosso exemplo, nosso dispositivo recém instalado está pendente. Veja na imagem.

Dispositivo pendente de aprovação

Repare que a coluna Status está com um círculo amarelo que representa este estado de indecisão. Este círculo pode variar entre verde para dispositivos aprovados e vermelho para dispositivos revogados.

Para aprovar o uso, clique na ação de registro Aprovar.

Uma vez aprovado, esta workstation passará a receber as diretivas que cadastraremos adiante.

Cadastrando diretivas a nível de kernel​

caution

Atenção! Diretivas proibitivas podem causar grandes danos ao dispositivo. Podendo levar ao bloqueio total de interatividade.

Através do menu go ➔ Linux ➔ Access Policies você poderá visualizar e gerenciar todas diretivas cadastradas. As diretivas são segregadas em três níveis.

  • Gerais: Diretivas que são aplicadas a todos dispositivos onde o senhasegura.go for Linux estiver ativo e aprovado

  • Por dispositivo: Diretivas aplicadas a dispositivos específicos

  • Por username: Diretivas que são aplicadas apenas nos dispositivos que contenha o username específico.

Para entendermos melhor seu uso, vamos apresentar o seguinte problema.

Dentro de uma corporação, o DBA é um funcionário contratado e de alta confiança. Já o suporte aos sistemas operacionais é realizado por uma empresa contratada.par A empresa contratada detém um usuário de alto privilégio para executar atualizações e manutenções no dispositivo. Sendo assim, estes funcionários terceirizados acabam tendo acesso ao arquivo de configuração do Oracle® orrendo o risco de altera-lo.par% O Gestor de Segurança da Informação e o DBA gostariam de proteger a escrita neste arquivo de forma centralizada sem ter que criar diversos grupos auxiliares servidor a servidor, correndo o risco de perder o controle dos membros destes grupos.

Neste caso, será necessário criar uma diretiva no senhasegura.go for Linux informando que apenas o usuário DBA tem permissão de escrita no arquivo alvo. Desta forma, nem mesmo o super usuário terá como alterar seu conteúdo. Mesmo que ele detenha autoridade sobre o arquivo.

Siga os passos a seguir para configurarmos este cenário.

  1. Acesse o relatório de diretiva através do menu go ➔ Linux ➔ Access Policies

  2. Clique na ação de relatório New Rule para criarmos uma diretiva global

  3. No formulário que se abre, preencha os campos da seguinte forma

    • Identification name: Nome da diretiva. Campo obrigatório. Este nome deve ser amigável para que seja fácilmente identificável. Não será repassado ao dispositivo alvo. Neste exemplo, preencheremos com "Deny TNS changes"

    • Enable audit: Indica se será habilitado a auditoria de ações que se enquadram nesta diretiva. O campo é obrigatório e por padrão vem ativo. Manteremos como ativo.

    • Enabled: Estado da diretiva. Campo obrigatório. Se ativo, a diretiva será considerada nos dispositivos alvo. Caso contrário, não será aplicada. Manteremos como ativo.

    • Guideline: Diretiva de kernel a ser monitorada. Campo obrigatório. Estas ações são provenientes das ações suportadas pela biblioteca CaitSith10. Utilizaremos a diretiva "Write file". Essa diretiva irá identificar o momento que uma tentativa de escrita em arquivo ocorrer.

    • Checker: Alvo da diretiva. Apesar deste campo não ser obrigatório, tenha muito cuidado ao não preenche-lo. O não preenchimento ou o preenchimento incorreto deste campo pode levar a completa inutilização do dispositivo.

      Neste exemplo, iremos preencher a variável path com o local do nosso arquivo alvo. Exemplo: path=˝/etc/oracle/tnsnames.ora˝

    • Include general denial rule?: Indicador se a diretiva de negar a todos deve ser considerada no momento que esta diretiva for aplicada. Por possibilitar ações a usuários específicos, é interessante que aos demais usuários este privilégio seja negado. Manteremos marcado em nosso exemplo. Campo obrigatório.

  5. Até este momento, cadastramos as características da diretiva a ser cadastrada. Agora iremos indicar os usuários que tem permissão ou proibição de execução da diretiva.

    • Allow or deny: Indica se cadastraremos uma diretiva de permissão ou negação ao usuário. Em nosso exemplo iremos cadastrar uma diretiva de Allow para nosso usuário DBA

    • Rule text: Agora colocaremos nosso username dba dentro do formato de diretivas do CaitSith11. Exemplo: task.uid=˝dba˝. Isso indica que se o processo que se enquadra a diretiva tiver o UID do username DBA, essa diretiva será aceita.

  7. Salve o registro e observe o resultado no dispositivo alvo!

caution

Atenção! Os campos Checker e Rule text, apesar de não serem obrigatórios, requerem muito cuidado. O não preenchimento ou o preenchimento incorreto deste campo pode levar a completa inutilização do dispositivo. E seus valores devem estar envoltos de aspas-duplas conforme o exemplo.

Validando a diretiva no dispositivo alvo​

Voltaremos então ao nosso exemplo evidênciando:

  • que a regra foi criada no dispositivo destino;

  • que o usuário DBA tem permissão de escrita no arquivo; e

  • que o super usuário não poderá escrever no arquivo

Validando a diretiva​

Exiba o arquivo /sys/kernel/security/caitsith/policy para verificar as regras padrão CaitSith12aplicadas no dispositivo.

root\@debian:/root# cat /sys/kernel/security/caitsith/policy 
POLICY_VERSION=20120401 
stat Policy updated: 9036 (Last: 2019/12/24 00:31:57) 
stat Requests denied: 10 (Last: 2019/12/23 18:55:22) 
stat Memory used by policy: 4512 
stat Memory used by audit: 63808 
stat Memory used by query: 0 
quota memory audit 16777216 
quota memory query 1048576 
quota audit\[1\] allowed=0 denied=1024 unmatched=1024 
 
**1**00 acl write path="/etc/oracle/tnsnames.ora" 
audit 1 
100 allow task.uid=1002 
200 deny

A saída acima apresenta alguns status que não são importantes neste momento. Mas repare que o texto em destaque apresenta exatamente a regra que criamos anteriormente. O senhasegura.go for Linux realizou inclusive a tradução do username dba para seu correto UID, tendo em vista que nem sempre este será o UID em cada dispositivo.

Escrevendo no arquivo como usuário dba​

Agora iremos inserir um conteúdo ao arquivo alvo como usuário dba. Conforme a regra aplicada, deve ser aceita. Repare que o usuário dba consegue escrever no arquivo

O usuário dba consegue escrever no arquivo

Tentando escrever no arquivo como super-usuário​

Já o super-usuário não conseguirá escrever no arquivo, uma vez que este usuário está na regra de negação da diretiva criada. Mesmo sendo super-usuário, a tentativa de escrita falha.

O usuário root não consegue escrever no arquivo

Pontos de atenção e solução de problemas​

Como dito anteriormente, diretivas escritas sem um recurso ou usuário alvo, acabam valendo para todo sistema, aumentando o risco de um bloqueio total no sistema.

O serviço secpack-maestro estará sempre em execução e atualizando as regras conforme elas forem cadastradas no senhasegura . Mas caso exista a necessidade de uma intervenção manual no dispositivo, execute o seguinte procedimento:

  1. Utilizando o usuário root, interrompa a execução do serviço secpack-maestro

    service secpack-maestro stop

  2. Execute o binário caitsith-loadpolicy para remover as diretivas desejadas. Removeremos como exemplo a diretiva criada anteriormente.

    echo 'delete 100 acl write path="/etc/oracle/tnsnames.ora"' \| /usr/sbin/caitsith-loadpolicy

  3. Valide que a diretiva foi removida verificando novamente o arquivo aplicado

    cat /sys/kernel/security/caitsith/policy

  4. Realize as mudanças no senhasegura para que a regra não seja aplicada novamente

  5. Inicie novamente o serviço secpack-maestro

    service secpack-maestro start

Gravação de sessão​

O agente senhasegura.go for Linux permite que determinados usuários sejam monitorados via vídeo durante toda sua sessão, independente do binário que estejam executando. Isso é possível através do terminal secpack-trec. Para ativa-lo, altere o terminal padrão do usuário alvo.

Conforme nosso exemplo utilizando o Debian13, utilize o comando vipw para editar o arquivo /etc/passwd e alterar o terminal padrão dos usuários alvo para /usr/bin/secpack-trec.

Assim que o usuário alvo iniciar sua sessão, será notificado de que suas ações estão sendo monitoradas.

Mensagens de erro ao login​

SIGNUSR: 1013: Local user does not exist on server​

Este usuário deve ter uma equivalência com um usuário de mesmo username no senhasegura . E este usuário do senhasegura não necessita estar vinculado a Perfil ou Grupo de Acesso.

SIGNUSR: 1014: User pending approval location​

Neste ponto a equivalência existe mas ainda não foi aprovada.

Vá ao relatório go ➔ Users e localize o usuário pendente de aprovação. Estará indicado pelo círculo laranja na coluna Status. O status pode variar entre laranja para estado de indefinição, verde para aprovado e vermelho para reprovado.

Clique na ação de registro Authorize para continuar.

Registro de sessão​

Uma vez tendo vinculado corretamente o usuário, este será monitorado através de uma gravação de vídeo. O usuário será notificado logo após o login desta ação, e perceberá o envio de evidências ao término.

Mensagem de alerta ao usuário

Para assistir o vídeo emitido, vá ao relatório de sessões no menu PAM ➔ Access Control ➔ Remote Sessions.

Player de vídeo da sessão

Controle de diretórios e arquivos​

A funcionalidade Controle de diretórios e arquivos permitir que o administrador cadastre configurações que irão controlar a permissão de arquivos e diretórios Linux.

Esta configuração é realizada através da interface web do senhasegura onde serão indicados o permissionamento de arquivos e diretórios, determinados, para todos usuários da workstation indicada. Ou seja:

"Se para o diretório Documentos" da worktation "01" os usuários receberão somente a permissão de leitura, ou seja, poderão apenas ver e listar os arquivos e subdiretórios contidos dentro de "Documentos" (diretório) na workstation "01"."".

  1. Acessando o menu go ➔ Linux ➔ Access Policies você tem acesso o todas diretivas cadastradas. Para criar controle de diretórios e arquivos você pode utilizar somente as diretivas:

    • Gerais: Diretivas que são aplicadas a todos dispositivos onde o senhasegura.go for Linux estiver ativo e aprovado

    • Por dispositivo: Diretivas aplicadas a dispositivos específicos

  2. Para criar um novo controle diretórios e arquivos clique na ação de relatório New Rule ou New rule for workstation;

    info

    Se desejar apenas edite um registro já existe para incluir o controle de diretórios e arquivos.

  3. No formulário que se abre, vá para a guia Controle de diretórios e arquivos;

  4. Na seção Permissões selecione o tipo de permissionamento que será permitido aos usuários no campo Permissão:

    • Leitura: Pode apenas ver e listar os arquivos e subarquivos/subdiretórios

    • Escrita: Pode editar um arquivo ou modificar o conteúdo de um diretório

    • Execução: Pode executar um arquivo ou acessar um diretório

  5. No campo Diretório ou arquivo indique o caminho completo do arquivo ou diretório que deseja que seja controlado.

  6. Clique no botão Adicionar para incluir o permissionamento para o controle. Se desejar, realize o passos anteriores para adicionar mais arquivos e diretórios para serem controlados.

  7. Na seção Regras de bloqueio selecione o tipo de permissionamento que será não será permitido aos usuários no campo Permissão:

    • Leitura: Ver e listar os arquivos e subarquivos/subdiretórios

    • Escrita: Editar um arquivo ou modificar o conteúdo de um diretório

    • Execução: Executar um arquivo ou acessar um diretório

  8. No campo Diretório ou arquivo indique o caminho completo do arquivo ou diretório que deseja que seja controlado.

  9. Clique no botão Adicionar para incluir o permissionamento para o controle. Se desejar, realize o passos anteriores para adicionar mais arquivos e diretórios para serem controlados.

    1. Caso tenha escolhido a opção de controle Segregação por workstation o formulário apresentará uma aba chamada Workstation

    2. Ao acessar essa aba clique no botão de adição e selecione na lista as workstaions que faram parte deste configuração e clique em Adicionar

  10. Para finalizar clique em Salvar

Ao termino realize um acesso a workstation onde o controle foi configurado e tente realizar as permissões que foram bloqueadas ou permitidas.

  1. CaitSith (GNU 2) https://caitsith.osdn.jp/↩
  2. https://www.debian.org/↩
  3. https://gcc.gnu.org/↩
  4. https://www.gnu.org/software/make/↩
  5. https://github.com/dell/dkms↩
  6. Procure a melhor referência ao seu sistema operacional↩
  7. http://www.digip.org/jansson/↩
  8. https://curl.haxx.se/libcurl/↩
  9. http://www.hyperrealm.com/libconfig/libconfig.html↩
  10. CaitSith (GNU 2) https://caitsith.osdn.jp/↩
  11. CaitSith (GNU 2) https://caitsith.osdn.jp/↩
  12. CaitSith (GNU 2) https://caitsith.osdn.jp/↩
  13. https://www.debian.org/↩