DEV Community: Nicolas Evangelista

Suas imagens de container não estão seguras!

Nicolas Evangelista — Wed, 20 Mar 2024 21:53:30 +0000

Não vale a pena chover no molhado, então não vou perguntar se você já sabe o que é um container, a pergunta agora é outra: Você sabe se o seu container está seguro? NÃO?!? Então chega junto que eu vou te mostrar uma parada.

Antes de começar precisamos passar por conceitos importantes, porque assim poderemos enxergar o valor real de ferramentas open source focadas em segurança, como as imagens da Chainguard.

O que é uma vulnerabilidade de software?

Uma vulnerabilidade de software pode ser descrita como uma brecha de segurança contida dentro de um código fonte. Essa brecha pode ser aproveitada por pessoas mal intencionadas para acessar e manipular o software de uma forma nociva, causando um impacto negativo em empresas e/ou nos usuários que façam o uso desse software.

Essas vulnerabilidades não podem ser postas como responsabilidade de um único indíviduo dentro de uma equipe de desenvolvimento, até porque podem surgir em diferentes etapas do desenvolvimento, desde a sua concepção, passando pelo desenvolvimento do código até chegar ao deploy e a sustenção do software. E como você deve ter imaginado, existem diversas vulnerabilidades conhecidas no mercado atualmente, porém nem todas são iguais.

O que são CVEs e CVSSs?

Para saber mais sobre as vulnerabilidades existentes e como metrificá-las utilizamos esses dois "queridões", o CVE (Common Vulnerabilities and Exposures) e o CVSS (Common Vulnerability Scoring System).

O CVE é um sistema público que nos ajuda a padronizar a documentação das vulnerabilidades que podemos nos deparar ao longo da nossa carreira, como lidar com novas vulnerabilidades não é do escopo do CVE, porém caso seja encontrada uma solução e ela se torne pública, essa vulnerabilidade terá uma documentação mais ampla, contando com formas de mitigar essa vulnerabilidade, quais foram os vetores e quais foram os danos causados.

O CVE possui um processo para que as vulnerabilidades sejam documentadas, e consequentemente se tornem públicas, ele funciona da seguinte maneira:

Uma pessoa, ou organização, descobre uma vulnerabilidade;
A vulnerabilidade é reportada para uma empresa participante do programa CVE;
A empresa solicita uma identificação para essa vulnerabilidade, essa identificação segue um padrão de nomeclatura, CVE + ano de publicação da vulnerabilidade + Identificador único, por exemplo, CVE-2021-25276;
O ID é reservado e será tratado internamente, porque nessa etapa a agência que cuida dos registros numéricos ainda não está preparada para publicar essa nova CVE, essa agências são chamadas de CNAs (CVE Numbering Authorities);
A empresa publica os detalhes da vulnerabilidade, como a causa do problema, o tipo de vulnerabilidade, o impacto etc.;
Por fim, a CVE é publicada assim que contém os requisitos mínimos para que possa se tornar pública, esse registro público é feito por uma CNA.

O CVSS utiliza algumas métricas para calcular o grau de severidade, como as métricas B (Base metrics), BE (Base and Environmental metrics), BT (Base and Threat metrics) e a BTE que combina todas as métricas, essas diferentes métricas servem para propósitos diferentes, que são os seguintes:

B -> São métricas que representam as características intrínsecas de uma vulnerabilidade que são classificadas como constantes, seja ao longo do tempo e independente do ambiente;

T -> São as características de uma ameaça que podem variar ao longo do tempo, mas não variam necessariamente entre ambientes;

E -> São características de vulnerabilidades que estão dentro do contexto do ambiente em que as aplicações estão sendo executadas.

Essas métricas ajudam a computar um score melhor e mais assertivo quando se trata de vulnerabilidades, aliás, vamos falar sobre o score das vulnerabilidades.

O score (ou pontuação) de cada vulnerabilidade é o que a define como uma vulnerabilidade crítica ou de baixo risco. Para que isso seja possível temos métricas que estão dentro de cada base que citei acima, passando por diversos contextos como vetor do ataque, a complexidade do ataque, se já existem técnicas maduras o suficiente para ajudar nesse ataque, e até mesmo métricas para indicar se o ambiente atacado possui dados sensíveis que não podem ser perdidos ou danificados, além de outras métricas que também são muito importantes para justificar o score.

A junção de várias métricas e seus resultados é o que constitui o score final da vulnerabilidade, atualmente o score atualizado do CVSS 4.0 é o seguinte:

Como eu posso identificar essas vulnerabilidades?

Agora que passamos pelas vulnerabilidades, é normal se questionar sobre como podemos encontrá-las em nossos projetos pessoais, ou até mesmo em sistemas empresariais. Para isso contamos com a ajuda de diversas ferramentas de scan de vulnerabilidades, como o trivy e o grype, eles podem nos ajudar a buscar vulnerabilidades em uma imagem de um container, em um repositório, um filesystem, imagens de máquinas virtuais etc., ambos servem para o mesmo propósito, porém existem algumas particularidades entre as duas ferramentas que não cabem no assunto do texto, sugiro que deem uma olhada nas documentações para encontrar o que melhor satisfaz sua demanda.

Um exemplo de como utilizar o trivy pode ser encontrado em sua documentação, o mesmo existe para o grype, mas gostaria de trazer aqui um exemplo do trivy e como essas vulnerabilidades são apresentadas para nós.

O trivy faz o scan dos pacotes que são utilizados dentro dos softwares, esses são conhecidos como SBOMs (Software Bill of Materials) e servem como uma "receita de bolo" para se criar um software, portanto lista todos os pacotes e dependências do projeto, isso será analisado pelo trivy; o trivy pode scanear o objeto buscando CVEs conhecidas através da leitura de bancos de dados que contém essas informações sobre as CVEs.

O exemplo mais simples que podemos demonstrar é o scan de uma imagem que está contida no registry do Docker, o famoso docker hub. Para isso vamos pegar uma imagem muito utilizada, a do servidor NGINX, podemos executar essa ação com o seguinte comando:

trivy image nginx:latest

Esse comando faz um scan de uma imagem de container para checar todas as vulnerabilidades, a saída do comando padrão é uma tabela contendo as informações da imagem que foi identificada, o número total de vulnerabilidades e quais os graus de risco de cada:

Abaixo dessa saída, a ferramenta nos oferece uma tabela com todas as CVEs detalhadas e o status de cada, se já foram solucionadas ou não, o grau de risco, os pacotes que são afetados por essa CVE, e outras informações referentes a esse contexto.

Aqui podemos ter uma ideia da quantidade de vulnerabilidades que uma imagem "padrão" pode conter, são 149 vulnerabilidades conhecidas, contendo 28 de alto risco e 2 críticas, imagina a bagaceira que pode acontecer em um possível ataque. Complicado, né?

Cortando o mal pela raiz

Agora que chegamos no final do caminho (será?) temos uma questão a ser resolvida: Como podemos diminuir as vulnerabilidades das nossas imagens de container?

A resposta é simples: Usando imagens confiáveis (durrrr)!

Brincadeiras à parte, hoje temos algumas soluções no mercado que se propõe a criar imagens distroless, que são imagens que não possuem um distribuição Linux convencional por trás da imagem, diminuindo significativamente a quantidade de possível vulnerabilidades que uma imagem pode conter, visto que diversos CVEs apontam que a causa do problema são pacotes de software contidos dentro de um SO que serve como base para nossas imagens, e o pior de tudo, esses pacotes muitas vezes não são necessários para a nossa aplicação em si.

Uma dessas opções é oferecida pela Chainguard, uma empresa que tem como objetivo a segurança do open source, oferecendo imagens seguras para que possamos trabalhar com containers sem termos que nos preocupar tanto com a parte da segurança, por exemplo.

As imagens da chainguard são baseadas no Wolfi, um sistema operacional que é desenvolvido pela própria Chainguard. O Wolfi é uma (não)distro de Linux usada para servir de base para imagens seguras, porque não conta com a presença de pacotes "desnecessários" para que uma aplicação possa rodar.

Todas as imagens da chainguard estão disponíveis no repositório deles no github, exatamente neste repositório aqui -> Images.

"Nicolas, fala logo das vulnerabilidades da imagem, pelo amor de Deus!! Tem criança chorando aqui!!!", e eu te digo: Calma, mussarelo! Vamos ao que interessa então, vamos passar o trivy na imagem do NGINX da chainguard para checar as vulnerabilidades.

trivy image cgr.dev/chainguard/nginx:latest

Antes de mostrar o resultado, peço que segure o queixo para não cair, de novo. Segurou? Então se liga no resultado:

Sim, nenhuma vulnerabilidade!

Pronto! Agora você conhece uma alternativa para as suas imagens padrão, uma alternativa segura, performática e enxuta. Lembrando que os projetos da Chainguard são open source, portanto se você quiser e puder contribuir com os projetos, sinta-se livre para checar o repositório deles no github, seja para ajudar em uma issue, abrir uma discussão sobre melhorias, apontar bugs encontrados etc., faça sua parte para que possamos construir um futuro mais seguro e open source.

Por fim, gostaria de indicar o hub de imagens da chainguard e o site com as documentações pros produtos que eles oferecem. Esse texto foi muito introdutório e mostrou apenas a ponta do iceberg quando se trata de imagens seguras, mas acho que a mensagem foi passada de forma clara: Cuide da segurança das suas imagens!

Aqui temos o hub das imagens da Chainguard -> Hub

Aqui temos a documentação das imagens oferecidas pela Chainguard -> Docs

Infelizmente os conteúdos relacionados às imagens da Chainguard, seguindo a documentação oficial, estão todos em inglês, mas prometo fazer um esforço para trazer mais conteúdo sobre elas em português.

Agradeço a atenção e a leitura! Estou disponível para conversar mais sobre o assunto e receber feedbacks sobre o conteúdo deste texto, muito obrigado!

Bibliografia

https://edu.chainguard.dev/

https://github.com/wolfi-dev

https://github.com/aquasecurity/trivy

https://juniorjbn.medium.com/o-que-%C3%A9-esse-tal-de-distroless-d1cc5dcd070e

https://gomex.me/blog/distroless/

https://www.akamai.com/blog/security/cves-what-they-are-ways-to-mitigate-their-impact

https://www.first.org/cvss/specification-document#CVSS-v4-0-Scoring

https://www.cve.org/About/Process#CVERecordLifecycle

Protocols and how they work

Nicolas Evangelista — Tue, 05 Mar 2024 14:15:14 +0000

Disclaimer: This is an introductory article made by someone who's studying this subject, if you have some advice about the topics that are covered in here, DM me! We can have a chat and i'll be pleased to change this article. Thanks for reading!

After my last article about deploys and how they work (only an introduction about that topic), i started to study more about network and how we can connect our devices with another devices, and exchange data between them, of course.

I intend to do a series (don't know how many articles it will be) of articles about protocols and how they work individually, by the end of the series you might have a good understanding about how the internet works with all of these protocols working together, making a deploy look like child's play.

For this matter i'll be using the two most used models, the TCP/IP and OSI model, as both of them can be used as reference models, it'll help us understand the data flow within any type of network.

I've already knew OSI model from previous studies but it wasn't something that caught my attention, even TCP/IP, which is the backbone of our network communication didn't grab my attention, until now. Thus, i have decided to make some articles about some protocols that we already know, but showing - or trying to - how things work within the OSI and TCP/IP model.

OSI and TCP/IP stack

Both models are structured with layers, the OSI has 7 layers that correlates with the 4 layers of TCP/IP model, because both of them can be used as reference models.

First, let's go through what protocols actually do and why we call them a stack.

Protocols are basically an agreement between two or more hosts to establish some standards for this communication to happen, the stack is created so we can have a reference for the multiple stages in this conversation, and troubleshoot any issues that might show up. We can say that a protocol stack is the one that contains all the protocols, or services, that are needed for hosts to communicate with each other.

Furthermore the stack also represents the isolation between layers, so each layer will communicate with the same layer in the other host and will pass through the same stages using the same protocols, the isolation between layers is used so that the upper layers don´t have to occupy themselves with some services that are being executed on the lower layers.

Ok, but what these layers actually do?

The 1st layer of the stack is the physical layer and at this point i think that everyone knows how data is physically transmitted, doesn't matter what is the medium used, the computer will always see bits flowing.

The 2nd layer is responsible for transforming the transmission received, break into smaller pieces making data frames (hundreds or thousands of bytes) and transmitting the frames sequentially, the receiver can send back an acknowledgement frame to confirm that he has received the data frame correctly.

3rd layer might be the most famous one, it is the layer responsible for routing data through networks, besides that, it is responsible for dealing with congestion and the quality of the service offered by other layers, the network layer must assure that the correct protocols are being used. The data in this layer is called packets.

4th layers is the most challenging for me, specially because it's here where the magic - or the isolation - happens, this layer is responsible for isolating the communication process between the upper and lower layers, therefore it needs to put everything in order, so it must reorder every data received and handle the communication with care. This is a layer that must establish a connection that aims directly to the other machine, so it is a "direct" connection between two hosts, because the lower layers will handle the communication between the host and the next immediate host, so it could be a router, a switch or an access point, but the 4th layer will handle the communication between the host and the final destination.

The last 3 layers represents just 1 layer of the TCP/IP stack, and why is that? Well, that's an interesting topic, but we'll not deal with that right now, so let's keep moving.

The session layer is mainly responsible for taking care of the session tokens, like keeping track of whose turn it is to transmit data, will also manage this tokens so the two parties won't even attempt to send data without the token, and last but not least, making sure that the data that has been transmitted is in order even if a crash occurs during the data transmission.

Almost reaching the peak of the model we have the presentation layer, this layer we can look at him more like a support role, because it will help the application layer to communicate with some services offered by the session layer, it is through this layer that the session layer knows which services it needs to provide to keep the data flowing.

Last, but definitely not least, we have the application layer that have the duty of provide access to other services within the OSI model, it does that by using an interface that allows the end user to communicate with other services, all of the data generated with this input will be used by some other tools that will establish a connection with the layer below, then follow the process until it reach the other host.

To be continued...

This may sound confusing right now, but i'm sure that will help a lot with the understanding of the protocols that will be presented to you throughout your career as IT professional, because this layers can be seen by every communication process in a network, as i said at the beginning of this article, these are reference models, so it won't show you the answers about how an specific protocol work, but will definitely show you which rules the protocol has to follow to be part of some layer, or what functionalities some protocol have just for being part of any of these layers.

The next article will treat the communication process within a LAN, which is a local area network, how the data flow works and the responsibilities for every component, it'll give a better understanding about how reference models can be applied to real scenarios.

References

Tanenbaum, Andrew S. Computer Networks. 5th ed. Upper Saddle River, NJ: Prentice Hall, 2010.

Piscitello, David M., and Chapin, A. Lyman. Open Systems Networking: TCP/IP and OSI. Upper Saddle River, NJ: Addison-Wesley, 1993.

O que é um deploy?

Nicolas Evangelista — Wed, 04 Oct 2023 15:07:28 +0000

O que é? De onde vieram? O que comem?

Esse texto foi escrito após um período de grande decepção, muitas incertezas sobre a carreira em tech, bem no vale da auto-estima entre a inteligência de Alan Turing e a certeza de nunca ser um bom desenvolvedor. Tudo isso por conta do tema de hoje: Deploy de aplicações.

Como disse Marx no prefácio de sua magnum opus, O Capital: "Todo o começo é difícil — isto vale em qualquer ciência."
Não foi diferente para mim, começando a me aventurar no mundo de DevOps após ter sido instigado por uma dúvida muito trivial: "Como meu código vai sair do local host e ir parar na internet?", foi assim que eu me dei mal. Ou quase.

Sumário

Tudo é físico
Por que meu código está preso ao localhost?
Final boss: A internet.
Agradecimentos
Bibliografia

Tudo é físico

A maior dificuldade que tive para entender esse processo foi exatamente o marco zero da computação, o motivo pelo qual todos podemos ler textos online, ver conteúdos divertidos e ajudar outras pessoas ao redor do mundo: Tudo é físico!
Em algum lugar do mundo, o nosso código existe na forma de bits, eletricidade, incomodando um hardware etc., ele está lá dando uma baita canseira em algum servidor físico.

Mas isso não diz nada a respeito - até o presente momento - sobre o que é um deploy, então vamos por partes!

Por que meu código está preso ao localhost?

A associação ainda não tinha sido feita, esse conceito estava órfão em minha mente.
Pensei nisso por muito tempo, de verdade, passei noites em claro pensando em formas mirabolantes de resgatar meu querido código de dentro dessa prisão chamada "localhost", mas afinal o que é o localhost?

Espera um pouco... O localhost possui um nome muito sugestivo: É um host (server) local!
Poxa! Como eu nunca havia pensado nisso?!?

O localhost nada mais é do que hostname, equivalente ao DNS para a internet e os IPs públicos, onde seu computador irá fazer uma requisição para ele mesmo, o IP do localhost sempre será o IP de sua máquina, portanto podemos acessar nossa aplicação da seguinte maneira:

(Nosso localhost) -> 127.0.0.1 : (Porta local) -> 3000

Isso significa que estamos acessando nosso IP, um host local, na porta de número 3000 onde estará rodando nossa aplicação, aqui deve-se atentar ao fato de que o IP será diferente e a porta também, deverá seguir seu próprio código para realizar este experimento.

O DNS, ou Domain Name Service, nos ajuda a nomear os IPs, tal qual nossos documentos que contam com um nome e um Registro Geral, o famoso RG. Ainda não somos máquinas, mas temos algumas semelhanças.

Se ligarmos o tico com o teco veremos que o passo inicial foi dado, nosso código está rodando em algum lugar.

Final boss: A internet.

Até aqui já sabemos que o nosso código não é uma alucinação coletiva, e nem está tão aprisionado assim, mas então como podemos jogá-lo para dentro desse oceano chamado internet?

A resposta é simples: Além de possuirmos um IP local, também possuímos um IP público, para que outros computadores possam nos enxergar na internet. Ok, estamos chegando à algum lugar.

A ideia é boa e está tudo uma maravilha mas aqui temos outro problema, um problema físico!

Físico?! Como assim!?!

Pois é, pequeno gafanhoto. Nesse cenário ideal nós já nos esquecemos do marco zero da computação, a eletricidade!
Aqui basta pensar no seguinte cenário: Colocamos nossa aplicação para rodar em nosso computador e conseguimos mergulhar nosso código nas águas do oceano da web, mas e se desligarmos nosso computador? Aí é que mora o perigo, porque nosso código será "desligado" também.

Ok, então qual a solução?

A solução é colocar nosso código em uma máquina que não desliga, literalmente.

Devemos enviar nosso código para um servidor e executá-lo dentro do mesmo servidor, que terá um IP privado, o tal do localhost, e um IP público que poderá ser acessado por outros computadores que estão conectados na internet.

Isso, por definição, seria um deploy feito da forma mais primitiva possível, mas pense positivo, esse conceito já não é mais um mistério.

Na data presente, em Outubro de 2023, existem diversas formas de fazer esse bendito deploy, porém esses foram os conceitos fundamentais que me ajudaram a entender um pouco mais sobre esse processo que parecia tão impossível.

No próximo artigo irei abordar as diferentes formas de fazer um deploy e como isso foi realizado ao longo dos anos, então fiquem ligados para mais novidades não tão novas assim.

Agradecimentos

Graças à comunidade Heart Developers pude entrar em contato com outro profissional da área de DevOps que abriu meus caminhos sobre este tema, esse artigo é apenas uma forma de agradecimento pelo tempo cedido. Valeu, He4rt! Valeu, Felipe Schossler!

Bibliografia

https://kubernetes.io/docs/concepts/overview/#why-you-need-kubernetes-and-what-can-it-do

https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/Publishing_your_website

https://www.hostinger.com/tutorials/what-is-localhost

Fiz um push sem checar as alterações do repositório, e agora?

Nicolas Evangelista — Thu, 14 Sep 2023 01:04:55 +0000

Este artigo foi escrito em conjunto com @donadonf

Dentro de uma equipe de desenvolvimento nos deparamos com algumas demandas que são desenvolvidas por pares, alguns casos utilizam até a mesma branch para desenvolver a tarefa e fazem com que os desenvolvedores trabalhem 2 habilidades muito importantes: A comunicação e o versionamento de código. Neste artigo iremos tratar de uma situação que pode ser comum, podemos chamá-la de “Fiz um push e não sabia que a branch havia mudado, e agora?”.

Ao tentar fazer um push, provavelmente recebeu de volta uma mensagem indicando um conflito de branches, sendo a branch local em que está trabalhando e a branch remota, para onde irá o commit feito.

[rejected] master -> master (fetch first)
error: failed to push

Bom, teremos um longo caminho pela frente, mas fique tranquilo porque há uma solução!

Primeiramente, devemos verificar os commits que já estão na branch remota e qual o nosso status em relação a ela, para isso podemos executar o comando:

git status

Receberá uma informação sobre o status das branch em que está trabalhando, dessa forma:

On branch nome-da-branch
Your branch and 'origin/nome-da-branch' have diverged,
and have 1 and 1 different commits each, respectively.

Isso indica que sua branch local está com um commit a ser enviado, mas está com um commit atrasado em relação a branch remota, nesse cenário é necessário puxar os dados da branch remota antes de realizar o push para que não tenha um conflito de versões de código.

Começaremos a solução do conflito entre as branches checando os logs dos commits feitos com o comando:

git log

Vamos pegar o ID do último commit feito, porque aqui estaremos visualizando um histórico dos commits feitos. Com esse ID iremos executar um hard reset na branch atual e retirar o commit do HEAD com outro comando, então a sequência de comandos será a seguinte:

git reset --hard ID-do-commit

git reset HEAD~1

Novamente, vamos checar o status das versões que estamos trabalhando com comando git status, veremos que alguns arquivos estão marcados como Changes not staged for commit, isso significa que o commit foi resetado corretamente e as alterações feitas não foram perdidas. Devemos então armazenar essas mudanças dentro do stash para que possamos fazer o commit mais tarde com o comando:

git stash

Caso a operação ocorra bem, a mensagem será a seguinte:

Saved working directory and index state WIP on nome-da-branch: ID-do-commit-atual-da-branch

Devemos então executar o comando que irá mostrar a quantidade de arquivos que estão salvos no último stash feito.

git stash show

Como os arquivos estarão salvos no stash e branch terá voltado ao mesmo estágio da branch remota, podemos dar sequência ao procedimento padrão de um commit. Iremos checar o status da branch remota com o git status e depois executar um git pull para receber as alterações feitas na branch remota.

Por fim, podemos retirar os arquivos do stash porque iremos utilizá-los agora:

git stash pop

Isso irá trazer de volta as alterações feitas no commit que não conseguimos realizar o push. Caso esteja apavorado com a situação, poderá repetir o fluxo de visualizar o status da branch remota com git status e ver se há mais atualizações, poupando uma possível dor de cabeça. Caso não tenha nenhuma alteração, podemos seguir com o commit normalmente:

git commit -m "feat: texto-do-commit"

git push

Dessa forma, podemos solucionar os conflitos de versões de uma forma simples e objetiva utilizando apenas o terminal do git.
É chegado o grande momento, podemos dormir tranquilos com as versões atualizadas e organizadas em nossas respectivas branches.

DEV Community: Nicolas Evangelista

Suas imagens de container não estão seguras!

O que é uma vulnerabilidade de software?

O que são CVEs e CVSSs?

Como eu posso identificar essas vulnerabilidades?

Cortando o mal pela raiz

Bibliografia

Protocols and how they work

OSI and TCP/IP stack

Ok, but what these layers actually do?

To be continued...

References

O que é um deploy?

Sumário

Tudo é físico

Por que meu código está preso ao localhost?

Final boss: A internet.

Agradecimentos

Bibliografia

Fiz um push sem checar as alterações do repositório, e agora?

*Este artigo foi escrito em conjunto com @donadonf *

Este artigo foi escrito em conjunto com @donadonf