Aqui na NGINX, temos orgulho de saber que literalmente milhões de organizações em todo o mundo confiam em nosso software para operar seus sites e sua infraestrutura de entrega de aplicativos. Considerando o quanto nossos usuários dependem do NGINX para operações essenciais, ficamos surpresos quando admitem que não deram muita atenção à importância de usar uma versão atualizada, que inclua correções para vulnerabilidades de segurança — como as Vulnerabilidades e Exposições Comuns (CVEs) — que se tornaram tão frequentes na Internet atual.
É claro que não basta pensar em se proteger contra ameaças à segurança — é preciso implementar processos bem definidos para monitorar vulnerabilidades e adotar medidas de proteção assim que elas estiverem disponíveis. É fácil subestimar quanto tempo e esforço isso pode exigir quando você precisa fazer tudo por conta própria, como acontece com softwares de código aberto. Na verdade, a possibilidade de se proteger contra ameaças à segurança de forma rápida e fácil é um benefício muitas vezes negligenciado de softwares com suporte comercial, como o NGINX Plus.
Neste blog, exploramos os desafios de proteger softwares de código aberto e explicamos como o NGINX Plus torna a mitigação de CVEs e outras ameaças à segurança muito mais rápida e fácil.
Como lidar com vulnerabilidades em software de código aberto
Por mais que todos os desenvolvedores gostem de pensar que escrevem códigos perfeitos, nenhum software está livre de bugs. Os desenvolvedores esperam que a maioria dos bugs seja detectada durante o desenvolvimento, como parte de um rigoroso processo de garantia da qualidade, e que apenas alguns apareçam durante o uso normal ao longo da vida útil do aplicativo. Na pior das hipóteses, os bugs são descobertos por usuários mal-intencionados.
As consequências dos bugs são muito maiores quando a pilha da sua aplicação é composta por várias ferramentas de código aberto, linguagens de programação e plataformas. É necessário analisar cada componente separadamente para verificar se ele está livre de bugs. Quando bugs são descobertos em softwares de código aberto, é importante ter uma política definida para validá-los, testá-los e, se possível, corrigi-los.
Sua política para software de código aberto precisa incluir pelo menos três processos:
- Revisão e testes regulares
- Rastreamento de vulnerabilidades e comunicação interna
- Corrigir vulnerabilidades em tempo hábil
Como relatar uma vulnerabilidade
Quando uma vulnerabilidade de segurança é descoberta, há uma sequência padrão de etapas para divulgá-la. O primeiro passo é enviar um relatório detalhado ao autor ou fornecedor do software. O responsável pelo relato e o autor decidem juntos como e quando divulgar a vulnerabilidade, geralmente na forma de um registro no banco de dados de Vulnerabilidades e Exposições Comuns (CVE). Por convenção, o autor tem 90 dias para resolver o problema antes da divulgação, mas é possível negociar um prazo maior.
NGINX e CVEs
Como fornecedora de software de código aberto e de software comercial, a NGINX participa ativamente do processo de notificação e correção de CVEs e outras vulnerabilidades que afetam o NGINX Open Source e o NGINX Plus, bem como seus outros produtos comerciais – que, no momento da redação deste texto, incluem o NGINX Controller [agora F5 NGINX Management Suite], o NGINX App Protect e o NGINX Ingress Controller – e suas soluções gratuitas e de código aberto, que incluem o NGINX Service Mesh, o NGINX Unit e o NGINX Amplify.
Os usuários do NGINX Open Source se beneficiam do fato de o NGINX Plus ser baseado nele, pois temos o compromisso de oferecer suporte e padrões de processos de nível empresarial aos clientes do NGINX Plus. Esses padrões incluem acordos de nível de serviço (SLAs) com nossos clientes, que determinam os procedimentos de correção de bugs e testes que os patches devem seguir, tanto para o software principal quanto para as dependências e os módulos compatíveis. Os SLAs ajudam os clientes a cumprir as regulamentações, minimizando o risco de exposição à exploração de vulnerabilidades.
Uma complicação adicional para o NGINX Open Source é que muitas tecnologias de terceiros o utilizam e o incorporam aos seus produtos. Os fornecedores dessas tecnologias têm seus próprios processos para divulgar e corrigir vulnerabilidades de software quando elas são descobertas. Como discutimos na próxima seção, às vezes há um atraso bastante significativo entre o lançamento de uma correção para o NGINX Open Source e o lançamento de uma correção correspondente para tecnologias de terceiros.
Como o NGINX Plus protege os assinantes contra vulnerabilidades
Na introdução, mencionamos que um benefício frequentemente ignorado do NGINX Plus é a rapidez e a facilidade que ele proporciona aos nossos clientes para se protegerem contra vulnerabilidades. Lidar com vulnerabilidades em software de código aberto pode consumir muito mais tempo — e, portanto, ser mais caro — do que muitas pessoas imaginam.
Nas seções a seguir, discutimos cinco maneiras específicas pelas quais a correção de vulnerabilidades é mais rápida e fácil para os assinantes do NGINX Plus.
A NGINX informa proativamente os assinantes do NGINX Plus sobre correções
Quando lançamos uma correção de segurança para o NGINX Open Source e o NGINX Plus, informamos proativamente os clientes do NGINX Plus por e-mail. Também publicamos um post no blog anunciando a disponibilidade da maioria das correções, mas não temos como entrar em contato diretamente com os usuários do NGINX Open Source. Com isso, cabe a eles monitorar CVEs e outros bancos de dados de vulnerabilidades, além de consultar nosso blog regularmente.
O F5 SIRT oferece ajuda em tempo real a assinantes do NGINX Plus sob ataque
Quando os clientes da F5, incluindo os assinantes do NGINX Plus, são vítimas de ataques, a Equipe de Resposta a Incidentes de Segurança da F5 (SIRT) está disponível para prestar assistência em tempo real. A SIRT age rapidamente para mitigar os ataques de forma eficaz e restabelecer suas operações. A equipe continua trabalhando com você mesmo após o fim do ataque, buscando “ir além do incidente relatado para reduzir os danos gerais à sua organização, bem como compreender, antecipar e impedir ameaças futuras”.
NGINX App Protect eleva a proteção de aplicações
NGINX App Protect é um firewall de aplicações web (WAF) de nível empresarial, respaldado pelos 20 anos de experiência em segurança da F5 e implantado como um módulo dinâmico do NGINX Plus. Ele reforça a segurança da camada 7 do NGINX Plus com proteção específica para aplicações contra ainda mais CVEs nos servidores de aplicações de backend. A NGINX e a F5 estão comprometidas em fornecer assinaturas relacionadas a campanhas de ataque específicas. O resultado? O NGINX App Protect dispensa os assinantes do NGINX Plus de criar suas próprias assinaturas e lidar com vários falsos positivos.
NGINX Plus oferece suporte à autenticação baseada em JWT e OpenID Connect
Mesmo na ausência de vulnerabilidades específicas que exijam correções, protocolos de autenticação sofisticados ajudam a impedir que agentes mal-intencionados acessem seus aplicativos e sua infraestrutura. Além dos métodos disponíveis no NGINX Open Source, o NGINX Plus oferece suporte à autenticação baseada em JSON Web Token (JWT) e OpenID Connect, tanto para clientes da Web quanto de API.
Assinantes do NGINX Plus recebem patches imediatamente
Conforme descrito em Como relatar uma vulnerabilidade, quando uma vulnerabilidade afeta o software NGINX, geralmente somos notificados antes que ela seja divulgada publicamente como uma CVE. Esse aviso prévio nos permite preparar uma correção antes da divulgação pública e, em geral, lançamos a correção no dia da divulgação (ou, em alguns casos, dentro de alguns dias). A correção é disponibilizada aos clientes do NGINX Plus na forma de binários corrigidos. Para os usuários do NGINX Open Source, ela é disponibilizada na forma de código-fonte corrigido e binários corrigidos para os sistemas operacionais compatíveis, mas, como mencionado acima, não temos como informar diretamente os usuários do NGINX Open Source.
As tecnologias de terceiros que utilizam ou incorporam o NGINX Open Source podem não tomar conhecimento da vulnerabilidade antes de sua divulgação. Mesmo que tomem, nossa experiência mostra que suas correções podem levar vários meses a mais do que a correção do NGINX para serem disponibilizadas. Isso é compreensível, especialmente no caso de software de código aberto, que muitas vezes é mantido por voluntários, mas deixa sua infraestrutura desprotegida e sujeita à exploração por hackers após a divulgação pública da vulnerabilidade.
Por exemplo, duas CVEs relacionadas a vulnerabilidades no HTTP/2 foram descobertas no segundo semestre de 2018 (CVE-2018-16843 e CVE-2018-16844). Em resposta, aplicamos correções de segurança ao NGINX Plus R16 e ao NGINX Open Source 1.15.6. O popular software OpenResty, que se baseia no NGINX Open Source para oferecer algumas das funcionalidades do NGINX Plus, lançou pela primeira vez uma versão candidata que incorporava essas correções em 3 de março de 2019 — quatro meses completos após a correção da NGINX. As soluções desenvolvidas com base no OpenResty geralmente demoram ainda mais para corrigir sua base de código.
Às vezes, o status de uma vulnerabilidade não é claro, ou o fornecedor do software não considera necessário lançar uma correção, mesmo que ela constitua um possível vetor de ataque. Uma situação desse tipo ocorreu em 2020 com o ModSecurity, o software WAF de código aberto mais utilizado. A equipe responsável pelo Conjunto de Regras Básicas do OWASP ModSecurity (CRS) descobriu que a forma como o ModSecurity v3 realiza a correspondência global de expressões regulares pode resultar no que a equipe do OWASP CRS considera uma vulnerabilidade de negação de serviço (CVE-2020-15598). A Trustwave, organização responsável pela manutenção do próprio ModSecurity, contestou que esse comportamento fosse um problema de segurança e se recusou a lançar uma correção.
NGINX ModSecurity WAF é um módulo dinâmico para o NGINX Plus desenvolvido com base no ModSecurity v3. A equipe do NGINX decidiu que o comportamento descrito na CVE-2020-15598 tinha potencial suficiente para causar uma vulnerabilidade de DoS e, por isso, lançou uma correção em setembro de 2020. Conforme explicamos no blog que anunciou a correção, os usuários de uma compilação de código aberto do ModSecurity (o que inclui os usuários do NGINX Open Source) devem decidir por conta própria se aplicam a correção da equipe do OWASP CRS ou se continuam usando o software sem correção da Trustwave e, possivelmente, implementam as alterações de mitigação propostas pela Trustwave.
[Editor – O NGINX ModSecurity WAF deixou oficialmente de ser comercializado em 1º de abril de 2022 e está em processo de descontinuação, que será efetivada em 31 de março de 2024. Para mais detalhes, consulte O F5 NGINX ModSecurity WAF está em processo de descontinuação<.htmla> em nosso blog.]
Conclusão
Experimente todos os recursos avançados do NGINX Plus – comece hoje mesmo sua avaliação gratuita de 30 dias ou entre em contato conosco para conversar sobre seus casos de uso.
Sobre o autor
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.