Em nosso primeiro artigo sobre segurança de containers, questionamos se os containers que estamos acostumados a usar são nativamente seguros. Agora, vamos focar em como aumentar a segurança do container, oferecendo algumas soluções.
Você pode ouvir também a versão em áudio deste artigo:
Quando olhamos para a segurança do container, temos que imaginar algumas fronteiras de proteção. Desta forma, temos que proteger o host do container, bem como proteger o container de outros containers.
Como em muitos aspectos de segurança de aplicações, nosso primeiro pensamento é termos a segurança pensada em camadas, e com isso, reforçar e melhor utilizar cada uma delas. Então, devemos pensar em como combinar múltiplos controles de segurança para mitigar as possíveis fragilidades e, assim, proteger nosso ativo.
Sistema de Arquivos
Para que um container funcione de forma apropriada, considerando um host linux, alguns sistemas de arquivos devem ser montados. Mas, da mesma forma, devemos entender que nem todos estes sistemas de arquivos precisam ser montados com acesso total, podemos melhorar isso.
Assim, podemos montar estes sistemas de arquivos de modo a permitir apenas a leitura (read-only), limitando assim o seu uso. Isso porque a grande maioria das aplicações não vai precisar mesmo ter outro tipo de acesso que não apenas de leitura. Assim, aqui vai nossa primeira dica: conheça bem quais acessos e a quais estruturas sua aplicação deve ter.
Então, podemos sugerir alguns espaços de sistemas de arquivos de devem ser montados com acesso de apenas leitura. São eles: /sys, /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus. Entretanto, sempre avalie se estes são suficientes. Se conseguirmos manter estes espaços de sistemas de arquivos restritos, também garantimos que o container apenas possa ler estes arquivos. Assim, não há como afetar o sistema do host.
No entanto, ainda há uma outra coisa que devemos ter em mente: temos que limitar a possibilidade do container remontar estes sistemas de arquivos de outra forma. Ou seja, retornar ao padrão de permissionamento total de acesso.
Capabilities
Mas tenha cuidado: limitar demais o acesso de processos privilegiados do container pode levar a aplicação a funcionar de forma incorreta – ou até mesmo a não funcionar no seu container. Por isso, queremos sugerir alguns capabilities que são usados pelos containers e devem ser tratados com cuidado. São eles: chown, dac_override, fowner, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, setfcap e audit_write.
Também há um conjunto de capabilities que são retirados dos containers por padrão. Vamos apenas usar dois exemplos destes. Ao ter retirado a capabilities SYS_MODULE, o container não poderá por exemplo, carregar ou descarregar algum módulo do kernel.
Ou ainda, se a capability NET_ADMIN está desabilitada, o container não terá a capacidade de modificar, por exemplo, seu próprio endereço IP. Ele também não poderá adicionar novas rotas em sua tabela de roteamento, ou ainda , modificar alguma regra de firewall do iptables.
Ainda há um outro componente muito importante de ser retirado. O SYS_ADMIN permite aos containers com processos privilegiados desta capability, que executem, por exemplo, uma ação de modificação de um namespace ou mesmo uma chamada de syscall. Você não vai querer seu container executando este tipo de ação, não é mesmo?
Aqui continua valendo a máxima: se não é necessário, pode ser retirado!
Ah ok, mas como eu posso tirar estas funcionalidades? É simples, e além de retirar, você pode colocar no momento em que entender necessário. Apenas use os comandos –cap-add ou –cap-drop ao executar seu container.
Namespaces
Já falamos em nosso outro artigo sobre os namespaces, mas queremos detalhar um pouco alguns deles.
PID settings (–pid)
A primeira coisa que temos que lembrar é que, por padrão, todo container já tem o PID habilitado.
O PID fornece aos containers, ou mesmo em qualquer sistema linux, a separação dos processos. Assim, o PID remove a visão que podemos ter sobre os processos, e se você não vê um processo, se torna mais difícil qualquer ação sobre ele.
No entanto, em alguns casos, você precisa que o container compartilhe de processos do host usando o seu namespace. E, basicamente, o que vai acontecer é que o processo dentro do container vai ver o processo do seu host.
Não é necessário lembrar que esse tipo de ação requer uma avaliação cuidadosa e muito mais elaborada. Mas vamos dizer que você queira executar algumas ferramentas de debugging, mas usando o namespace do seu host. Arriscado mas possível. Então, os PID nos proporcionam esse tipo de limitação aos processos, o que pode ser um bom passo para a segurança do nosso container e do host em si.
Configurações de Rede no container
Assim como em qualquer máquina, os containers também possuem as características de configurações de rede. E por padrão elas já estão habilitadas em todos os containers criados.
Um dos cenários possíveis é que você pode ter um conjunto de DNS específicos para seus containers, proporcionando por exemplo, que seu conjunto de containers tenham tráfegos gerenciados por DNS mas restritos.
Configurar as rede de seu container passa primeiro por entender que os containers podem ter alguns tipos de configurações. Como é o caso da opção “none”, ou seja, sem qualquer tipo de rede, ou ainda a opção “bridge” onde as configurações padrão do Docker serão usados.
Ainda temos as opções “host”, e aqui o container vai usar e ter disponível as interfaces de rede do host. E há também a opção de container, onde um container pode usar a configuração de rede de outro.
Existem inúmeras formas de configurar um container quando pensamos em redes e vale muito uma boa lida na documentação oficial da Docker é bem detalhada e muito explicativa.
SAIBA MAIS SOBRE NOSSOS SERVIÇOS
Últimas considerações sobre segurança do container
Como sempre, nosso objetivo principal é o de trazer temas que possam estimular o estudo e a leitura de assuntos relacionados à AppSec.
Neste tema em específico, podemos ver que há um grande campo de estudo e avaliação quando falamos de segurança de containers. Precisamos entender a ferramenta, saber quais são as suas fragilidades e como podemos atuar sobre elas.
O que não podemos de forma alguma é sermos simples observadores de um processo que vem amadurecendo com o tempo, e não participarmos dele de forma correta.
Queremos ajudar a todos que estão começando agora a sua jornada com containers. Lembre: containers são ferramentas que podem nos trazer grandes ganhos, mas também podem nos colocar em problemas muito maiores.
A construção e uso corretos de containers pode ser a diferença entre manter a sua estrutura segura ou ter um ponto frágil dentro do seu sistema.
Espero ter ajudado! Nos vemos no próximo artigo!
