* Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
O Docker Engine realiza o trabalho pesado de executar e gerenciar contêineres. O Docker Engine usa recursos do kernel Linux como **Namespaces** e **Cgroups** para fornecer isolamento básico entre os contêineres. Ele também usa recursos como **Capabilities dropping**, **Seccomp**, **SELinux/AppArmor para obter um melhor isolamento**.
O cliente Docker pode acessar o Docker Engine **localmente usando um soquete Unix ou remotamente usando http**. Para usá-lo remotamente, é necessário usar https e **TLS** para garantir confidencialidade, integridade e autenticação.
Por padrão, ele escuta no soquete Unix `unix:///var/`\
`run/docker.sock` e nas distribuições Ubuntu, as opções de inicialização do Docker são especificadas em `/etc/default/docker`. Para permitir que a API e o cliente do Docker acessem o Docker Engine remotamente, precisamos **expor o daemon do Docker usando um soquete http**. Isso pode ser feito por:
Exporar o daemon do Docker usando http não é uma boa prática e é necessário garantir a segurança da conexão usando https. Existem duas opções: a primeira opção é para o **cliente verificar a identidade do servidor** e a segunda opção é para **ambos, cliente e servidor, verificarem a identidade um do outro**. Certificados estabelecem a identidade de um servidor. Para um exemplo de ambas as opções, [**verifique esta página**](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-3engine-access/).
As imagens do contêiner são armazenadas em um repositório privado ou público. A Docker fornece as seguintes opções para armazenar imagens de contêiner:
* [Docker hub](https://hub.docker.com) - Este é um serviço de registro público fornecido pela Docker.
* [Docker registry](https://github.com/%20docker/distribution) - Este é um projeto de código aberto que os usuários podem usar para hospedar seu próprio registro.
* [Docker trusted registry](https://www.docker.com/docker-trusted-registry) - Esta é a implementação comercial da Docker do registro Docker e fornece autenticação de usuário baseada em função, juntamente com a integração do serviço de diretório LDAP.
Os contêineres podem ter **vulnerabilidades de segurança** tanto por causa da imagem base quanto pelo software instalado em cima da imagem base. A Docker está trabalhando em um projeto chamado **Nautilus** que faz a verificação de segurança dos contêineres e lista as vulnerabilidades. O Nautilus funciona comparando cada camada da imagem do contêiner com o repositório de vulnerabilidades para identificar falhas de segurança.
O comando **`docker scan`** permite que você faça a verificação de imagens do Docker existentes usando o nome ou ID da imagem. Por exemplo, execute o seguinte comando para verificar a imagem hello-world:
As imagens de contêineres Docker podem ser armazenadas em um registro público ou privado. É necessário **assinar** as imagens de contêineres para confirmar que elas não foram adulteradas. O **publicador** de conteúdo é responsável por **assinar** a imagem do contêiner e enviá-la para o registro.\
Aqui estão alguns detalhes sobre a confiança de conteúdo do Docker:
* A confiança de conteúdo do Docker é uma implementação do projeto de código aberto [Notary](https://github.com/docker/notary). O projeto de código aberto Notary é baseado no projeto [The Update Framework (TUF)](https://theupdateframework.github.io).
* A confiança de conteúdo do Docker é habilitada com `export DOCKER_CONTENT_TRUST=1`. A partir da versão 1.10 do Docker, a confiança de conteúdo **não está habilitada por padrão**.
* Quando a confiança de conteúdo está habilitada, só é possível **baixar imagens assinadas**. Ao enviar uma imagem, é necessário inserir a chave de marcação.
* Quando o publicador envia a imagem pela **primeira vez** usando o comando docker push, é necessário inserir uma **senha** para a **chave raiz e chave de marcação**. As outras chaves são geradas automaticamente.
* O Docker também adicionou suporte para chaves de hardware usando o Yubikey e os detalhes estão disponíveis [aqui](https://blog.docker.com/2015/11/docker-content-trust-yubikey/).
O seguinte resultado mostra a **imagem do contêiner sendo enviada para o Docker hub com assinatura** habilitada. Como não é a primeira vez, o usuário é solicitado a inserir apenas a frase secreta para a chave do repositório.
É necessário armazenar a chave root, a chave do repositório e a frase secreta em um local seguro. O seguinte comando pode ser usado para fazer backup das chaves privadas:
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir facilmente e **automatizar fluxos de trabalho** com as ferramentas comunitárias mais avançadas do mundo.\
Os namespaces são úteis para isolar um projeto dos demais, isolando as comunicações de processos, rede, montagens... É útil isolar o processo do Docker de outros processos (e até mesmo da pasta /proc) para que ele não possa escapar abusando de outros processos.
Poderia ser possível "escapar" ou mais precisamente **criar novos namespaces** usando o binário **`unshare`** (que usa a chamada de sistema **`unshare`**). O Docker, por padrão, impede isso, mas o Kubernetes não (no momento em que este escrito foi feito).\
De qualquer forma, isso é útil para criar novos namespaces, mas **não para voltar aos namespaces padrão do host** (a menos que você tenha acesso a algum `/proc` dentro dos namespaces do host, onde você poderia usar o **`nsenter`** para entrar nos namespaces do host).
Considero este um dos recursos **mais importantes** em relação à segurança do isolamento do processo. Isso ocorre porque, sem as capacidades, mesmo que o processo esteja sendo executado como root, **você não poderá executar algumas ações privilegiadas** (porque a chamada de sistema **`syscall`** retornará um erro de permissão porque o processo não possui as capacidades necessárias).
Ele é ativado por padrão no Docker. Ele ajuda a **limitar ainda mais as syscalls** que o processo pode chamar.\
O **perfil Seccomp padrão do Docker** pode ser encontrado em [https://github.com/moby/moby/blob/master/profiles/seccomp/default.json](https://github.com/moby/moby/blob/master/profiles/seccomp/default.json)
O Docker possui um modelo que você pode ativar: [https://github.com/moby/moby/tree/master/profiles/apparmor](https://github.com/moby/moby/tree/master/profiles/apparmor)
**Namespaces** são um recurso do kernel Linux que **particiona os recursos do kernel** de forma que um conjunto de **processos veja** um conjunto de **recursos**, enquanto **outro** conjunto de **processos veja** um conjunto **diferente** de recursos. O recurso funciona tendo o mesmo namespace para um conjunto de recursos e processos, mas esses namespaces se referem a recursos distintos. Os recursos podem existir em vários espaços.
O recurso do kernel Linux **cgroups** fornece a capacidade de **restringir recursos como CPU, memória, IO, largura de banda de rede entre** um conjunto de processos. O Docker permite criar Containers usando o recurso cgroup, que permite o controle de recursos para o Container específico.\
A seguir, temos um Container criado com memória do espaço do usuário limitada a 500m, memória do kernel limitada a 50m, compartilhamento de CPU para 512, peso de blkioweight para 400. O compartilhamento de CPU é uma proporção que controla o uso de CPU do Container. Ele tem um valor padrão de 1024 e varia entre 0 e 1024. Se três Containers têm o mesmo compartilhamento de CPU de 1024, cada Container pode usar até 33% da CPU em caso de contenção de recursos da CPU. O peso de blkioweight é uma proporção que controla o IO do Container. Ele tem um valor padrão de 500 e varia entre 10 e 1000.
As capacidades permitem um **controle mais preciso das capacidades que podem ser permitidas** para o usuário root. O Docker utiliza o recurso de capacidade do kernel do Linux para **limitar as operações que podem ser realizadas dentro de um contêiner**, independentemente do tipo de usuário.
Quando um contêiner Docker é executado, o **processo descarta as capacidades sensíveis que o processo poderia usar para escapar do isolamento**. Isso tenta garantir que o processo não seja capaz de realizar ações sensíveis e escapar:
[SELinux](https://www.redhat.com/en/blog/latest-container-exploit-runc-can-be-blocked-selinux) é um **sistema de rotulagem**. Cada **processo** e cada **objeto do sistema de arquivos** possuem um **rótulo**. As políticas do SELinux definem regras sobre o que um **rótulo de processo pode fazer com todos os outros rótulos** no sistema.
Os motores de contêiner lançam **processos de contêiner com um único rótulo SELinux confinado**, geralmente `container_t`, e em seguida definem o contêiner dentro do contêiner para ser rotulado como `container_file_t`. As regras de política do SELinux basicamente dizem que os **processos `container_t` só podem ler/escrever/executar arquivos rotulados como `container_file_t`**.
Um plugin de autorização **aprova** ou **negam****solicitações** ao **daemon** do Docker com base no contexto atual de **autenticação** e no contexto de **comando**. O contexto de **autenticação** contém todos os **detalhes do usuário** e o **método de autenticação**. O contexto de **comando** contém todos os dados relevantes da **solicitação**.
Se você não estiver limitando adequadamente os recursos que um contêiner pode usar, um contêiner comprometido pode realizar um ataque de negação de serviço (DoS) no host onde está sendo executado.
Um ataque de negação de serviço (DoS) de largura de banda é um tipo de ataque cibernético que visa sobrecarregar a largura de banda de um sistema ou rede, tornando-o inacessível para usuários legítimos. Nesse tipo de ataque, o objetivo é consumir toda a largura de banda disponível, impedindo que outros usuários acessem os recursos do sistema ou da rede.
Existem várias técnicas que podem ser usadas para realizar um ataque de negação de serviço de largura de banda, incluindo o envio de uma grande quantidade de tráfego malicioso para o alvo, o que pode ser feito por meio de botnets ou amplificação de tráfego. Além disso, um atacante também pode explorar vulnerabilidades em servidores ou roteadores para aumentar o tráfego e sobrecarregar a largura de banda.
Para proteger-se contra ataques de negação de serviço de largura de banda, é importante implementar medidas de segurança, como firewalls, sistemas de detecção e prevenção de intrusões (IDS/IPS) e balanceadores de carga. Além disso, é recomendado monitorar o tráfego de rede em busca de atividades suspeitas e manter os sistemas e roteadores atualizados com as últimas correções de segurança.
Se você estiver executando um contêiner onde um invasor consegue obter acesso como um usuário de baixo privilégio. Se você tiver um **binário suid mal configurado**, o invasor pode abusar dela e **elevar privilégios dentro** do contêiner. O que pode permitir que ele escape dele.
Para mais opções **`--security-opt`**, verifique: [https://docs.docker.com/engine/reference/run/#security-configuration](https://docs.docker.com/engine/reference/run/#security-configuration)
Além disso, **não use variáveis de ambiente** para suas informações sensíveis. Qualquer pessoa que possa executar `docker inspect` ou `exec` no contêiner pode encontrar seu segredo.
Volumes do Docker são melhores. Eles são a maneira recomendada de acessar suas informações sensíveis na documentação do Docker. Você pode **usar um volume como sistema de arquivos temporário mantido na memória**. Volumes removem o risco de `docker inspect` e de registro. No entanto, **usuários root ainda podem ver o segredo, assim como qualquer pessoa que possa `exec` no contêiner**.
Se você apenas precisa do **segredo na sua imagem**, você pode usar o **BuildKit**. O BuildKit reduz significativamente o tempo de construção e possui outros recursos interessantes, incluindo suporte a segredos em tempo de construção.
1. Defina-o como uma variável de ambiente com `export DOCKER_BUILDKIT=1`.
2. Inicie seu comando `build` ou `run` com `DOCKER_BUILDKIT=1`.
3. Ative o BuildKit por padrão. Defina a configuração em /_etc/docker/daemon.json_ como _true_ com: `{ "features": { "buildkit": true } }`. Em seguida, reinicie o Docker.
4. Em seguida, você pode usar segredos no momento da construção com a flag `--secret` assim:
Com o Docker Compose, adicione o par chave-valor dos segredos a um serviço e especifique o arquivo de segredo. Agradecimentos à resposta do [Stack Exchange](https://serverfault.com/a/936262/535325) pela dica de segredos do Docker Compose, da qual o exemplo abaixo é adaptado.
Se você estiver usando [Kubernetes](https://kubernetes.io/docs/concepts/configuration/secret/), ele possui suporte para segredos. O [Helm-Secrets](https://github.com/futuresimple/helm-secrets) pode ajudar a facilitar a gestão de segredos no K8s. Além disso, o K8s possui Controles de Acesso Baseados em Função (RBAC), assim como o Docker Enterprise. O RBAC torna a gestão de acesso aos segredos mais fácil e segura para equipes.
**gVisor** é um kernel de aplicativo, escrito em Go, que implementa uma parte substancial da superfície do sistema Linux. Ele inclui um tempo de execução [Open Container Initiative (OCI)](https://www.opencontainers.org) chamado `runsc` que fornece um **limite de isolamento entre o aplicativo e o kernel do host**. O tempo de execução `runsc` integra-se ao Docker e ao Kubernetes, tornando simples a execução de contêineres isolados.
**Kata Containers** é uma comunidade de código aberto que trabalha para construir um tempo de execução de contêiner seguro com máquinas virtuais leves que têm a sensação e o desempenho de contêineres, mas fornecem **isolamento de carga de trabalho mais forte usando tecnologia de virtualização de hardware** como uma segunda camada de defesa.
* **Não use a flag `--privileged` ou monte um** [**socket do Docker dentro do contêiner**](https://raesene.github.io/blog/2016/03/06/The-Dangers-Of-Docker.sock/)**.** O socket do Docker permite a criação de contêineres, então é uma maneira fácil de assumir o controle total do host, por exemplo, executando outro contêiner com a flag `--privileged`.
* **Não execute como root dentro do contêiner. Use um** [**usuário diferente**](https://docs.docker.com/develop/develop-images/dockerfile\_best-practices/#user) **e** [**namespaces de usuário**](https://docs.docker.com/engine/security/userns-remap/)**.** O root no contêiner é o mesmo do host, a menos que seja remapeado com namespaces de usuário. Ele é apenas levemente restrito por, principalmente, namespaces, capacidades e cgroups do Linux.
* [**Descarte todas as capacidades**](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) **(`--cap-drop=all`) e habilite apenas as necessárias** (`--cap-add=...`). Muitas cargas de trabalho não precisam de nenhuma capacidade e adicioná-las aumenta o escopo de um possível ataque.
* [**Use a opção de segurança "no-new-privileges"**](https://raesene.github.io/blog/2019/06/01/docker-capabilities-and-no-new-privs/) para impedir que processos obtenham mais privilégios, por exemplo, por meio de binários suid.
* [**Limite os recursos disponíveis para o contêiner**](https://docs.docker.com/engine/reference/run/#runtime-constraints-on-resources)**.** Limites de recursos podem proteger a máquina contra ataques de negação de serviço.
* **Ajuste os perfis de** [**seccomp**](https://docs.docker.com/engine/security/seccomp/)**,** [**AppArmor**](https://docs.docker.com/engine/security/apparmor/) **(ou SELinux)** para restringir as ações e chamadas de sistema disponíveis para o contêiner ao mínimo necessário.
* **Use** [**imagens oficiais do Docker**](https://docs.docker.com/docker-hub/official\_images/) **e exija assinaturas** ou construa suas próprias com base nelas. Não herde ou use imagens com [backdoors](https://arstechnica.com/information-technology/2018/06/backdoored-images-downloaded-5-million-times-finally-removed-from-docker-hub/). Armazene também as chaves raiz e a frase secreta em um local seguro. O Docker tem planos para gerenciar chaves com o UCP.
* **Reconstrua regularmente** suas imagens para **aplicar patches de segurança no host e nas imagens**.
* No seu Dockerfile, **prefira COPY em vez de ADD**. ADD extrai automaticamente arquivos compactados e pode copiar arquivos de URLs. COPY não possui essas capacidades. Sempre que possível, evite usar ADD para não ficar suscetível a ataques por meio de URLs remotas e arquivos Zip.
Se você tiver acesso ao socket do Docker ou tiver acesso a um usuário no **grupo docker, mas suas ações estão sendo limitadas por um plugin de autenticação do Docker**, verifique se você pode **burlá-lo**:
* A ferramenta [**docker-bench-security**](https://github.com/docker/docker-bench-security) é um script que verifica dezenas de práticas recomendadas comuns para implantar contêineres Docker em produção. Os testes são todos automatizados e baseados no [CIS Docker Benchmark v1.3.1](https://www.cisecurity.org/benchmark/docker/).\
Você precisa executar a ferramenta no host que executa o Docker ou em um contêiner com privilégios suficientes. Saiba **como executá-la no README:** [**https://github.com/docker/docker-bench-security**](https://github.com/docker/docker-bench-security).
Use [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) para construir e **automatizar fluxos de trabalho** com facilidade, utilizando as ferramentas comunitárias mais avançadas do mundo.\
* Você trabalha em uma **empresa de cibersegurança**? Gostaria de ver sua **empresa anunciada no HackTricks**? Ou gostaria de ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo Telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
