Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
the-bastion — Autenticação, autorização, rastreabilidade e auditabilidade para acessos SSH. | Kitploit
Ferramentas/GitHubGitHub/ovh/the-bastion
Autenticação e AutorizaçãoAuditoria de ConfiguraçãoSegurança de RedeTestes de PenetraçãoUtilitários e FrameworksGerenciamento de Identidade e Acesso (IAM)Red Teaming
GitHubovh/the-bastion

the-bastion

Autenticação, autorização, rastreabilidade e auditabilidade para acessos SSH.

Ver Repositório
2.2k13156há 1 mêsRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar
Site

The Bastion Logo

🔒 The Bastion

Visão Geral

Bastions são um cluster de máquinas usadas como ponto de entrada único por equipes operacionais (como administradores de sistema, desenvolvedores, administradores de banco de dados, ...) para conectar-se de forma segura a dispositivos (servidores, máquinas virtuais, instâncias em nuvem, equipamentos de rede, ...), normalmente usando ssh.

O Bastion fornece mecanismos para autenticação, autorização, rastreabilidade e auditabilidade para toda a sua infraestrutura.

Estando entre seus usuários e sua infraestrutura, o Bastion adiciona uma camada de abstração, para que sua infraestrutura não precise conhecer cada membro da equipe operacional individualmente.

Cada membro da sua equipe tem uma conta individual no Bastion e pode ser membro de um ou vários grupos do bastion que podem dar acesso a uma ou mais infraestruturas. Os dispositivos da infraestrutura precisam apenas conhecer e confiar no(s) grupo(s) do bastion do(s) qual(is) podem fazer parte.

O RBAC granular do Bastion torna possível delegar algumas responsabilidades para qualquer conta, com escopo de grupo ou em todo o bastion, incluindo para contas que podem ser usadas por sua automação para, por exemplo, gerenciar o ciclo de vida das contas (vinculado ao seu sistema de gestão de recursos humanos, LDAP ou AD), garantir que a ACL de um grupo esteja atualizada (vinculada ao seu CMDB), etc. Processos automatizados são fáceis de implementar por meio da JSON API over SSH.

Recursos de conhecimento

Quer saber mais enquanto aprecia alguns desenhos interessantes? Aqui está uma série de posts de blog que aprofundam as funcionalidades e princípios principais do The Bastion:

  • Part 1 - Genesis
  • Part 2 - Delegation Dizziness
  • Part 3 - Security at the Core
  • Part 4 - A new era

Outros recursos que podem ser de interesse:

  • Documentação online
  • (Vídeo em francês, slides em inglês) The Bastion no Very Tech Trip 2023, estudo de caso de gerenciamento de uma infraestrutura com e sem o Bastion
  • (Vídeo em francês, slides em inglês) The Bastion no OSSIR, 2021, explicando rapidamente os princípios principais, depois detalhando a funcionalidade de realm e, finalmente, detalhando por que as escolhas técnicas de implementação reforçam a segurança (adicionando voluntariamente uma vulnerabilidade de segurança no código para prová-lo!)
  • (Podcast em francês) The Bastion no NoLimitSecu, 2021, entrevista com perguntas e respostas

♻️ Zero suposições sobre o seu ambiente

Nada sofisticado é necessário, nem no lado de entrada nem no lado de saída do Bastion para funcionar. Apenas seu bom e velho cliente ssh é necessário para se conectar através dele, e do outro lado, qualquer servidor sshd padrão serve. Isso inclui, por exemplo, dispositivos de rede nos quais você pode não ter a possibilidade de instalar qualquer software personalizado. Dispositivos antigos que suportam apenas algoritmos de criptografia de baixa segurança ou telnet podem ser ocultados da Internet por meio de firewall, permitindo apenas o Bastion, evitando assim uma troca de baixa segurança, permitindo apenas conexões de alto nível de segurança no lado de entrada do bastion.

➰ Confiabilidade

  • Apenas algumas bibliotecas conhecidas são usadas; menos código de terceiros significa uma superfície de ataque menor
  • O Bastion é projetado para ser autossuficiente: sem dependências como bancos de dados, outros daemons, outras máquinas ou serviços de nuvem de terceiros, nem para a fase de autenticação ou autorização, estatisticamente significa menos tempo de inatividade
  • A alta disponibilidade pode ser configurada para que várias instâncias do bastion formem um cluster de várias instâncias, com qualquer instância utilizável a qualquer momento (esquema ativo/ativo)

:godmode: Lista não exaustiva de funcionalidades

  • Esquemas de acesso Pessoal e em grupo com delegação de funções de grupo para garantir a autonomia das equipes sem compromissos de segurança
  • Quebra de protocolo SSH entre as conexões de entrada e saída
  • Gravação de sessão interativa (em arquivos ttyrec padrão)
  • Gravação de sessão não interativa (stdout e stderr via ttyrec)
  • Suporte extensivo a registros via syslog para fácil consumo por SIEM
  • Funcionalidades de autenticação incluem suporte a MFA/2FA (senha, TOTP) além da autenticação por chave pública
  • Suporte à verificação e imposição de atestação de chaves PIV da Yubico no lado da conexão de entrada
  • Suporte a mosh no lado da conexão de entrada
  • Suporte a passagem de scp, sftp e rsync, para upload e/ou download de arquivos para/de servidores remotos
  • Suporte à passagem de subsistema SSH netconf
  • Suporte a realms, para criar uma confiança entre dois bastions de possivelmente duas empresas diferentes, dividindo as fases de autenticação e autorização enquanto ainda aplica políticas locais
  • Suporte a autologin por senha SSH no lado de saída para dispositivos legados que não suportam autenticação por chave pública, enquanto ainda força autenticação por chave pública adequada no lado de entrada
  • Suporte a autologin por senha telnet no lado de saída para dispositivos antigos que não suportam SSH, enquanto ainda força autenticação por chave pública SSH adequada no lado de entrada
  • Suporte a proxy HTTPS com tratamento de autenticação e autorização man-in-the-middle, para desacoplamento de senhas de entrada e saída (principalmente útil para APIs de dispositivos de rede)

🔧 Instalando, atualizando, usando o Bastion

Por favor, consulte a documentação online ou a versão baseada em texto correspondente encontrada na pasta doc/.

🎥 Exemplo rápido de conexão e reprodução

asciicast

⚡ TL;DR: teste: sandbox descartável usando Docker

Esta é uma boa maneira de testar o Bastion em segundos, mas leia as FAQ se você estiver falando sério sobre usar conteinerização em produção.

A imagem sandbox está disponível para as seguintes arquiteturas: linux/386, linux/amd64, linux/arm/v6, linux/arm/v7, linux/arm64, linux/ppc64le, linux/s390x.

Vamos executar a imagem docker:

root@kitploit:~
docker run -d -p 22 --name bastiontest ovhcom/the-bastion:sandbox

Tenha sua chave SSH pública em mãos e configure a primeira conta de administrador:

root@kitploit:~
docker exec -it bastiontest /opt/bastion/bin/admin/setup-first-admin-account.sh poweruser auto

Estamos prontos com a configuração padrão! Vamos configurar um alias útil para o bastion e testar o comando info:

root@kitploit:~
PORT=$(docker port bastiontest | cut -d: -f2)
alias bastion="ssh [email protected] -tp $PORT -- "
bastion --osh info

Ele deve cumprimentá-lo como um administrador do bastion, o que significa que você tem acesso a todos os comandos. Vamos entrar no modo interativo:

root@kitploit:~
bastion -i

Isso é útil para chamar vários plugins --osh em sequência. Agora podemos pedir ajuda para ver todos os plugins:

root@kitploit:~
$> help

Se você tem uma máquina remota para a qual deseja tentar se conectar através do bastion, busque sua chave de saída:

root@kitploit:~
$> selfListEgressKeys

Copie esta chave pública para o arquivo authorized_keys da máquina remota na pasta .ssh/ da conta à qual deseja se conectar, então:

root@kitploit:~
$> selfAddPersonalAccess --host <remote_host> --user <remote_account_name> --port-any
$> ssh <remote_account_name>@<remote_host>

Observe que você pode se conectar diretamente sem usar o modo interativo, com:

root@kitploit:~
bastion <remote_account_name>@<remote_machine_host_or_ip>

É isso! Claro, há muito mais; a documentação está disponível na pasta doc/ e online. Certifique-se de verificar a ajuda do bastion (bastion --help) e a ajuda de cada plugin osh (bastion --osh comando --help). Também não se esqueça de personalizar seu arquivo bastion.conf, que pode ser encontrado em /etc/bastion/bastion.conf (para Linux).

🔀 Sistemas operacionais suportados para instalação

As distribuições Linux abaixo são testadas em cada versão, mas como este é um produto de segurança, você é fortemente aconselhado a executá-lo na versão estável mais recente do seu sistema operacional favorito:

  • Debian 13 (Trixie), 12 (Bookworm), 11 (Bullseye)
  • RockyLinux 10.x, 9.x, 8.x
  • Ubuntu LTS 26.04, 24.04, 22.04
  • OpenSUSE Leap 16.0

Qualquer outra versão Linux dita "moderna" não é testada em cada versão, mas deve funcionar com ajustes nulos ou menores.

Os seguintes sistemas operacionais também são testados em cada versão:

  • FreeBSD 15.1, 15.0, 14.4

O FreeBSD tem suporte parcial a MFA, devido ao seu conjunto reduzido de plugins pam disponíveis. Pode ser configurado suporte para um fator adicional de senha ou TOTP, mas não ambos ao mesmo tempo.

🆗 Qualidade do código

  • O código é executado sob perltidy
  • O código também é executado sob perlcritic
  • Testes funcionais são usados antes de cada versão

🛂 Segurança no núcleo

Mesmo com o processo de codificação mais conservador, cauteloso e paranóico, o código tem bugs, portanto não deve ser confiado cegamente. Por isso, o bastion não confia em seu próprio código. Ele aproveita as primitivas de segurança do sistema operacional para obter segurança adicional, como visto abaixo.

  • Usa o conhecido e confiável Controle de Acesso Discricionário UNIX:

    • Os usuários do bastion são mapeados para usuários reais do sistema
    • Os grupos do bastion são mapeados para grupos reais do sistema
    • Todo o código verifica constantemente os direitos antes de permitir qualquer ação
    • O DAC UNIX é usado como um cinto de segurança para impedir que uma ação seja bem-sucedida mesmo que o código seja enganado para permiti-la
  • O script principal do bastion é declarado como o shell do sistema do usuário bastion:

    • Nenhum usuário tem acesso real a shell (tipo bash) no sistema
    • Todo o código é executado sob os direitos da conta de sistema do usuário não privilegiado
    • Mesmo que um usuário conseguisse escapar para um shell real, ele não conseguiria conectar-se a máquinas para as quais não tem acesso, pois não tem permissão de leitura em nível de sistema de arquivos para as chaves SSH
  • O código é modular

    • O código principal verifica principalmente direitos, registra ações e permite acesso ssh a outras máquinas
    • Todos os comandos auxiliares, chamados plugins, estão em módulos separados do código principal
    • Os módulos podem ser abertos ou restritos
      • Apenas contas que receberam concessão específica com base na necessidade podem executar um plugin restrito específico
      • Isso é verificado pelo código e também imposto pelo DAC UNIX (o plugin só pode ser lido e executado pelo grupo do sistema específico do plugin)
  • Todo o código que precisa de privilégios estendidos do sistema é separado do código principal, em módulos chamados helpers

    • Os helpers são executados exclusivamente sob sudo
    • A configuração sudoers é vinculada a um grupo do sistema específico do comando, que é concedido a contas com base na necessidade
    • Os helpers só podem ser lidos e executados pelo grupo do sistema específico do comando

🔍 Auditabilidade

  • Os administradores do Bastion devem usar a lógica do bastion para se conectar a ele mesmo para administrá-lo (ou melhor, usar outro bastion para isso), isso garante auditabilidade em todos os casos
  • Cada acesso e ação (permitida ou negada) é registrado com:
    • syslog, que também deve ser enviado para um servidor syslog remoto para garantir que nem mesmo os administradores do bastion possam adulterar seus rastros, e/ou
    • bancos de dados locais sqlite3 para busca fácil
  • Cada sessão é gravada com ttyrec, scripts auxiliares são fornecidos para criptografar e enviar esses registros para um servidor de custódia remoto
  • Este código é usado em produção em vários ambientes certificados PCI-DSS, ISO 27001, SOC1 e SOC2

🔗 Relacionados

Dependências

  • ovh-ttyrec - uma versão melhorada mas compatível do ttyrec, um gravador de terminal (tty)

Ferramentas opcionais

  • yubico-piv-checker - um binário Go autossuficiente para verificar a validade de chaves e certificados PIV. Opcional, para habilitar as funcionalidades do Bastion com suporte a PIV
  • puppet-thebastion (GitHub) - um módulo Puppet para automatizar e manter a configuração das máquinas do Bastion
  • the-bastion-ansible-wrapper - um wrapper para possibilitar a execução de playbooks Ansible através do Bastion
  • debian-cis - um script para aplicar e monitorar o endurecimento de hosts Debian de acordo com as recomendações CIS

Ferramentas da comunidade

Uma lista não exaustiva de ferramentas relacionadas mantidas pela comunidade:

  • chef-cookbook - um cookbook Chef para instalar o bastion e configurar sua configuração padrão
  • ansible role - um role Ansible para instalar e configurar o bastion

📝 Licença

Licenciado sob a Licença Apache, Versão 2.0 (a "Licença"); você não pode usar este arquivo exceto em conformidade com a Licença. Você pode obter uma cópia da Licença em

root@kitploit:~
http://www.apache.org/licenses/LICENSE-2.0

A menos que exigido por lei aplicável ou acordado por escrito, o software distribuído sob a Licença é distribuído "COMO ESTÁ", SEM GARANTIAS OU CONDIÇÕES DE QUALQUER TIPO, expressas ou implícitas. Veja a Licença para as permissões específicas e limitações sob a Licença.

Baixar ferramenta
  • O caminho dos helpers e alguns de seus parâmetros imutáveis são codificados na configuração sudoers
  • O modo tainted do Perl (-T) é usado para todo código executado sob sudo, impedindo que qualquer entrada do usuário interfira na lógica, interrompendo a execução imediatamente
  • O código executado sob sudo não confia em seu chamador e re-verifica cada entrada
  • A comunicação entre código não privilegiado e código privilegiado é feita usando JSON
  • Uma quebra de protocolo é operada entre os lados de entrada e saída, tornando a maioria das vulnerabilidades baseadas em protocolo ineficazes