BLOG | NGINX

Mitigando vulnerabilidades de segurança de forma rápida e fácil com o NGINX Plus

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Laurent Pétroque
Laurent Pétroque
Publicado em 04 de março de 2021

Aqui na NGINX, temos orgulho de que literalmente milhões de organizações ao redor do mundo confiam em nosso software para impulsionar seus sites e infraestrutura de entrega de aplicativos. Considerando o quanto nossos usuários dependem do NGINX, ficamos surpresos quando eles admitem que não pensaram muito na importância de executar uma versão atualizada que tenha correções para vulnerabilidades de segurança, como Vulnerabilidades e Exposições Comuns (CVEs), que se tornaram tão comuns na Internet de hoje.

É claro que não basta pensar em se proteger contra ameaças de segurança: você precisa implementar processos bem definidos para rastrear vulnerabilidades e colocar proteções em prática assim que elas estiverem disponíveis. É fácil subestimar quanto tempo e esforço isso pode levar se você tiver que fazer tudo sozinho, como é o caso do software de código aberto. De fato, tornar rápido e fácil a proteção contra ameaças de segurança é um benefício frequentemente esquecido de softwares com suporte comercial como o NGINX Plus.

Neste blog, exploramos os desafios de proteger software de código aberto e explicamos como o NGINX Plus torna muito mais rápido e fácil mitigar CVEs e outras ameaças de segurança.

Lidando 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 sejam detectados durante o desenvolvimento como parte de um rigoroso processo de conformidade de qualidade, com apenas alguns surgindo sob uso normal ao longo da vida do aplicativo. No pior dos casos, os bugs são descobertos por usuários maliciosos com más intenções.

As consequências dos bugs são muito maiores quando você constrói sua pilha de aplicativos a partir de várias ferramentas de código aberto, linguagens de programação e plataformas. Você precisa revisar cada componente separadamente para validá-lo como livre de bugs. Quando bugs são descobertos em software 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:

  1. Revisão e testes regulares
  2. Rastreamento de vulnerabilidades e relatórios internos
  3. Corrigindo vulnerabilidades em tempo hábil

Relatando uma vulnerabilidade

Quando uma vulnerabilidade de segurança é descoberta, há uma sequência padrão de eventos para divulgá-la. O primeiro passo é enviar um relatório detalhado ao autor ou fornecedor do software. O repórter e o autor decidem juntos como e quando divulgar a vulnerabilidade, geralmente na forma de um registro no banco de dados Common Vulnerabilities and Exposures (CVE). Por convenção, o autor tem 90 dias para resolver o problema antes da divulgação, mas é possível negociar mais tempo.

NGINX e CVEs

Como fornecedora de software de código aberto e fornecedora de software comercial, a NGINX participa ativamente do processo de relatórios e remediaçã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 artigo incluem NGINX Controller [agora F5 NGINX Management Suite ] , NGINX App Protect e NGINX Ingress Controller — e ofertas gratuitas e de código aberto, que incluem NGINX Service Mesh , NGINX Unit e NGINX Amplify .

Os usuários do NGINX Open Source se beneficiam do fato de que o NGINX Plus é baseado nele, porque estamos comprometidos com o suporte de nível empresarial e padrões de processo para clientes do NGINX Plus. Esses padrões incluem acordos de nível de serviço (SLAs) com nossos clientes que determinam procedimentos de correção de bugs e testes com os quais os patches devem estar em conformidade, tanto para o software principal, dependências quanto para módulos suportados. Os SLAs ajudam os clientes a atingir a conformidade com as regulamentações, minimizando o risco de exposição a explorações de vulnerabilidades.

Uma desvantagem adicional do NGINX Open Source é que muitas tecnologias de terceiros o aproveitam e o incorporam em seus produtos. Os fornecedores dessas tecnologias têm seus próprios processos para divulgar e corrigir vulnerabilidades de software quando elas são descobertas. Conforme discutiremos na próxima seção , às vezes há um atraso bastante significativo entre o lançamento de um patch para o NGINX Open Source e o lançamento de um patch correspondente para tecnologias de terceiros.

Como o NGINX Plus protege assinantes contra vulnerabilidades

Na introdução, mencionamos que um benefício frequentemente esquecido do NGINX Plus é como ele torna mais rápido e fácil para nossos clientes se protegerem de vulnerabilidades. Lidar com vulnerabilidades em software de código aberto pode consumir muito mais tempo – e, portanto, ser caro – do que muitas pessoas pensam.

Nas seções a seguir, discutiremos cinco maneiras específicas de resolver vulnerabilidades de forma mais rápida e fácil para assinantes do NGINX Plus.

NGINX informa proativamente assinantes do NGINX Plus sobre patches

Quando lançamos um patch 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 blog anunciando a disponibilidade da maioria dos patches, mas não temos como entrar em contato diretamente com os usuários do NGINX Open Source. Isso coloca sobre eles a responsabilidade de monitorar CVEs e outros bancos de dados de vulnerabilidades e de verificar nosso blog regularmente.

F5 SIRT fornece ajuda em tempo real para assinantes do NGINX Plus sob ataque

Quando os clientes da F5, incluindo assinantes do NGINX Plus, são vítimas de ataques, a Equipe de Resposta a Incidentes de Segurança (SIRT) da F5 está lá para fornecer assistência em tempo real. O SIRT trabalha rapidamente para mitigar ataques de forma eficaz e fazer com que você volte a operar. Eles continuam a trabalhar com você mesmo depois que o ataque para - eles "olham além do incidente relatado para reduzir o dano geral à sua organização, bem como entender, antecipar e impedir ameaças futuras".

NGINX App Protect intensifica a proteção de aplicativos

O NGINX App Protect é um firewall de aplicativo da Web (WAF) de nível empresarial, desenvolvido com base nos 20 anos de experiência em segurança da F5 e implantado como um módulo dinâmico do NGINX Plus. Ele intensifica a segurança da Camada 7 do NGINX Plus com proteção específica para aplicativos contra ainda mais CVEs em seus servidores de aplicativos de back-end. A NGINX e a F5 estão comprometidas em fornecer assinaturas relacionadas a campanhas de ataque específicas. O resultado? O NGINX App Protect libera os assinantes do NGINX Plus da criação de suas próprias assinaturas e da necessidade de 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 patches, protocolos de autenticação sofisticados ajudam a impedir que criminosos acessem seus aplicativos e 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 , para clientes da Web e de API .

Assinantes do NGINX Plus recebem patches imediatamente

Conforme descrito em Relatar uma vulnerabilidade , quando uma vulnerabilidade afeta o software NGINX, geralmente somos notificados antes que ela seja divulgada publicamente como um CVE. O aviso prévio nos permite preparar um patch antes da divulgação pública e geralmente lançamos o patch no dia da divulgação (ou dentro de alguns dias, em alguns casos). A correção está disponível para clientes do NGINX Plus na forma de binários corrigidos. Ele está disponível para usuários do NGINX Open Source na forma de código-fonte corrigido e binários corrigidos para sistemas operacionais suportados, mas, conforme observado acima, não temos como informar os usuários do NGINX Open Source diretamente.

Tecnologias de terceiros que aproveitam ou incorporam o NGINX Open Source podem não tomar conhecimento da vulnerabilidade antes de sua divulgação. Mesmo que isso aconteça, nossa experiência é que seus patches podem ficar vários meses atrás do patch do NGINX. Isso é compreensível, especialmente para software de código aberto, que geralmente é mantido por voluntários, mas deixa sua infraestrutura desprotegida e sujeita à exploração por hackers depois que a vulnerabilidade é divulgada publicamente.

Como exemplo, dois CVEs sobre vulnerabilidades com HTTP/2 foram descobertos no outono de 2018 ( CVE-2018-16843 e CVE-2018-16844 ). Em resposta, aplicamos patches 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 fornecer algumas das funcionalidades do NGINX Plus, lançou pela primeira vez um release candidate que incorporou esses patches em 3 de março de 2019 – 4 meses inteiros após o patch do NGINX. Soluções construídas sobre o OpenResty geralmente levam ainda mais tempo para corrigir sua base de código.

Às vezes, o status de uma vulnerabilidade não é claro, ou o fornecedor do software não acredita que um patch seja necessário, mesmo que constitua um potencial vetor de ataque. Uma situação semelhante ocorreu em 2020 com o ModSecurity, o software WAF de código aberto mais utilizado. A equipe que mantém o OWASP ModSecurity Core Rule Set (CRS) descobriu que a maneira como o ModSecurity v3 faz 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 organização que mantém o ModSecurity, a Trustwave, contestou que o comportamento seja um problema de segurança e se recusou a emitir um patch.

O NGINX ModSecurity WAF é um módulo dinâmico para o NGINX Plus criado no ModSecurity v3. A equipe NGINX decidiu que o comportamento descrito em CVE-2020-15598 tinha potencial suficiente para causar uma vulnerabilidade DoS, emitindo um patch em setembro de 2020. Conforme explicamos no blog que anunciou o patch , os usuários de uma versão de código aberto do ModSecurity (que inclui usuários de código aberto do NGINX) devem decidir por si mesmos se aplicam o patch da equipe do OWASP CRS ou se continuam com o software sem patch da Trustwave e possivelmente implementam as alterações de mitigação propostas pela Trustwave.

[ Editor – O NGINX ModSecurity WAF foi oficialmente encerrado em 1º de abril de 2022 e está em transição para o fim da vida útil em 31 de março de 2024 . Para mais detalhes, veja F5 NGINX ModSecurity WAF está em transição para o fim da vida útil<.htmla> em nosso blog.]

Conclusão

No cenário empresarial cada vez mais competitivo de hoje, as equipes de software estão sob pressão para entregar códigos novos e atualizados o mais rápido possível para oferecer os serviços mais inovadores. Ao mesmo tempo, o aumento de ataques sofisticados à infraestrutura e aos aplicativos torna vital rastrear vulnerabilidades e mitigá-las o mais rápido possível, uma prática tediosa e demorada.

Uma assinatura NGINX Plus alivia esse fardo, permitindo que as equipes de aplicativos se concentrem em sua missão principal – entregar código mais rápido – enquanto a organização permanece protegida contra vulnerabilidades de segurança.

Experimente todos os recursos avançados do NGINX Plus – comece seu teste gratuito de 30 dias hoje mesmo ou entre em contato conosco para discutir seus casos de uso .


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."