Dúvidas frequentes

• Compreendendo a estrutura de uma URL

  Introdução

  Na XLabs Security, líder em soluções de Web Application Firewall (WAF) e Content Delivery Network (CDN), entendemos que a segurança de um website começa com a compreensão básica da sua estrutura. Neste artigo, exploraremos a estrutura de uma URL, exemplificada por "https://www.exemplo.com/pagina?id=123", e discutiremos como esse conhecimento é crucial para implementar estratégias de defesa eficazes.

  

  1. Schema (Protocolo): https

  A URL começa com o schema ou protocolo, neste caso, "https://". O "https" assegura uma conexão criptografada, crucial para proteger dados transmitidos entre o usuário e o site. Em termos de segurança, é o primeiro passo para garantir a integridade e confidencialidade das informações.

  2. Subdomínio: www

  O "www" é um subdomínio comum, sempre bom utilizar para websites principais de empresas e instituições. Subdomínios podem ser usados para separar sistemas distintos em empresas, o que é relevante para aplicar políticas de segurança diferenciadas, dependendo da natureza do subdomínio.

  3. Domínio puro ou Naked-Domain: exemplo.com

  O domínio, "exemplo.com", é o coração da URL e da empresa, geralmente essa parte da URL demonstra o nome da empresa e o tipo de domínio que é, e qual país pertence o domínio, podendo ser "exemplo.com.br" onde trata-se de um endereço administrado pela autoridade de domínios do Brasil.

  4. Caminho do Recurso: /pagina

  O caminho, como "/pagina", especifica o recurso, diretório ou página web dentro do website ou aplicação web, isso determina as funções que a aplicação ou website pode ter, inclusive pode determinar arquivos que estão sendo acessados, imagens, arquivos de mídia ou estilos como CSS ou códigos JavaScript's.

  5. Query String: ?id=123

  A query string, "?id=123", contém informações adicionais enviadas a página hospedada no servidor, neste exemplo temos o "id" como um parâmetro que a aplicação recebe e o "123" seria o valor que o ID iria receber durante esta requisição. Essa parte da URL é frequentemente alvo de ataques de injeção e outros tipos de explorações.

  Conclusão

  Entender a estrutura de uma URL é fundamental para implementar estratégias de defesa em um website. Cada componente da URL pode ser alvo de diferentes tipos de ataques. Por exemplo, um endpoint de login requer autenticação robusta e proteção contra ataques de força bruta, enquanto um endpoint que serve imagens ou arquivos .mp4 precisa de proteções contra hotlinking ou exploits de buffer overflow.

  Na XLabs Security, nossa abordagem em WAF e CDN é informada por uma compreensão profunda de como as URLs são estruturadas e utilizadas. Ao compreender cada elemento de uma URL, podemos aplicar defesas específicas e eficazes, garantindo que cada parte do seu website esteja segura contra ameaças cibernéticas. A segurança começa com a educação, e a estrutura de uma URL é o primeiro passo para uma defesa cibernética robusta.

• Fail-Over e Balancer da XLabs

  

   

  Novo conceito implementado no WAF da XLabs e já em funcionamento em alguns de nossos clientes que necessitam de uma alta disponibilidade em seus ambientes e aplicações web: Fail-Over e Balancer.

  Muitas empresas ainda possuem sistemas próprios, servidores próprios e hospedados em seus próprios ambientes, infraestrutura própria, links de internet de provedores etc. E como sabemos, mesmo contratando um link dedicado de internet, seja de qualquer provedor, não estamos imunes a imprevistos.

  A quebra ou rompimento de fibras, queima de equipamentos, queda de luz e muitos outros fatores podem impactar a saúde de um link dedicado a atender uma aplicação web de alta complexidade ou criticidade, como em caso de hospitais onde um sistema de exames indisponível por horas devido a um rompimento de fibra ou falha de hardware de rede, por exemplo, pode impactar diretamente vidas que estejam passando por alguma emergência.

   

   

  Nasce a Fail-Over da XLabs

  Diante da necessidade de alguns de nossos clientes, incluindo um grupo hospitalar que atendemos e um dos maiores portos da América Latina, que não pode  parar as exportações e importações que passam por ele, nossos especialistas desenvolveram um serviço integrado ao nosso WAF (Web Application Firewall) e a nossa CDN (Content Delivery Network) apelidado de Fail-Over, ou zona de failover.

  Essa integração nos dá a capacidade de fazer a verificação da saúde de links, servidores e aplicações e escolher a melhor rota ou servidor a ser acessado, acrescentando a capacidade de alta disponibilidade aos clientes em suas aplicações web e websites hospedados “on premise” ou não, no nosso plano “Empresarial Plus” de WAF e CDN.

  Para entender melhor o funcionamento da nossa Fail-Over elaboramos pequenos fluxogramas para explicar a funcionalidade. Acompanhe a seguir como funciona na prática.

   

   

  Sobre o Fail-Over

  Antes de entendermos exatamente do que se trata a Fail-Over vamos abordar como alguns clientes utilizam nossos serviços de WAF e CDN. Clientes com ambientes “on premise” usam nossos serviços somente com um único link de internet servindo seu servidor web HTTP/HTTPS, conforme o fluxograma abaixo:

  

   

  Nesse fluxo, podemos perceber que o cliente utiliza-se somente de um link, enviando conexões ao seu web-server.

  Há ainda clientes que utilizam outra forma de conexão fazendo o balanceamento da carga de acessos entre dois links de operadoras diferentes, e outros, com sistemas de failover próprios, fazem a checagem e a mudança de links em caso de falha, conforme a imagem a seguir:

   

  

   

  Porém, outros clientes, ao utilizarem o balanceamento entre dois links sem a verificação de integridade e saúde dos links, estavam sempre suscetíveis a falhas. Caso algum dos links viesse a apresentar lentidão ou sofresse com algum tipo de desastre, como naturais ou uma ruptura de fibra óptica, fazendo com que praticamente 50% do seu público de usuários de suas aplicações recebesse alguma mensagem de falha (geralmente nossa tela de “Hosting Error” apresentando geralmente o erro 504 de Gateway Timeout), até às equipes de TI dos nossos clientes identificarem o problema em seus links nós já teríamos muitos chamados abertos em nosso suporte com nossos clientes acreditando se tratar de alguma instabilidade em nossa plataforma de WAF e CDN.

   

  

   

  Até descobrirmos se tratar do link com falha (e qual link), para orientarmos o cliente a mudar suas rotas em seu sistema de backup e failover, já teria se passado uns bons 10 minutos ou mais de paralisação parcial ou de intermitências em acessos de sua aplicação web.

  Através do nosso serviço de Health Check e Failover automático, nosso WAF ganhou a capacidade de mudar automaticamente a rota de envio das requisições, evitando quedas extensas que podem impactar grande parte de seus usuários.

  Nossas opções de Health Check, ou checagem de saúde são: Ping (ICMP), GET (HTTP/HTTPS), POST (HTTP/HTTPS) e Port Listening, que faz a checagem de portas abertas ou não.

  Para checagem de saúde de links de internet, recomendamos a utilização de Health Check’s baseados em ping (ICMP), que enviam pequenas requisições ICMP para verificar a saúde e estabilidade de um link de internet.

  Para a checagem de saúde de aplicações web recomendamos a utilização de checagens utilizando o próprio protocolo HTTP, com requisições GET ou POST. Essas requisições de checagens podem ser combinadas com nossas equipes de suporte, sendo que esta modalidade também pode ser utilizada para a verificação de integridade entre servidores e aplicações web para evitar aplicações que estejam apresentando quedas por problemas tanto de links quanto de banco de dados etc, pois pode dar a possibilidade de checagem de múltiplos servidores.

  Para a checagem da saúde de Web-Servers em si, uma simples checagem de porta online já é o suficiente para saber se um Web-Server está operando ok ou não, fazendo nossa Zona de Fail-Over atuar para enviar ao Web-Server disponível.

   

  

   

  Nessa zona especial que desenvolvemos podemos escolher qual melhor link para nosso WAF enviar as requisições HTTP de forma que não impacte as aplicações web atendidas por nossa CDN.

  As checagens são feitas de forma automática e periódicas, todas as funcionalidades de check mencionadas anteriormente são executadas de 5 em 5 minutos. Em caso de falha, ou seja, em caso de queda da aplicação ou link, as checagens são mais curtas, chegando a checagens de 2 em 2 minutos para uma recuperação mais rápida.

   

  

   

  Junto com nossa zona de Health Check e Fail-Over, também disponibilizamos a possibilidade de Balanceamento de cargas entre links.

   

   

  Entendendo o Balancer da XLabs

  Alguns de nossos clientes utilizam somente links primários para atendimento de suas aplicações web, ou seja, precisam que as requisições cheguem 100% em determinados links e somente sejam passadas ao link secundário em caso de desastres.

  Nossa Fail-Over também foi pensada e desenvolvida para estes clientes que possuem somente um link de backup e um principal, conforme exemplificado nas imagens a seguir.

  Podemos definir que o tráfego seja 100% enviado ao link 2 em caso de desastres ou falhas.

   

  

   

  Caso a saúde do link 1 esteja ok, enviamos 100% do tráfego ao link 1.

   

  

   

  Outra possibilidade de balanceamento de carga é a divisão de carga e requisições 50%-50% conforme a imagem a seguir:

   

  

   

  E você? Já escolheu a melhor forma de manter seu ambiente com alta disponibilidade?

   

   

  Considerações

  A XLabs Security  possui uma equipe de especialistas altamente qualificados que, além de atuarem diariamente na proteção das aplicações de nossos clientes, buscam sempre formas de inovar e trazer melhorias para garantir a eficácia dos nossos serviços.

• mTLS chega ao WAF da XLabs Security

  

   

  Temos o prazer de anunciar a mais recente atualização em nossa plataforma: a integração do mTLS (Mutual Transport Layer Security) com nosso Web Application Firewall (WAF). Essa adição fortalece ainda mais nossa missão de oferecer soluções de segurança de ponta para proteger seus aplicativos e dados contra ameaças cibernéticas em constante evolução.

   

  O que é mTLS e por que é importante?

  O mTLS é uma extensão do protocolo TLS (Transport Layer Security) que garante a autenticação mútua entre cliente e servidor, assegurando que ambos os lados sejam confiáveis e legítimos antes de estabelecerem uma conexão ou sessão. Isso significa que apenas os dispositivos autorizados podem se comunicar com seu servidor, garantindo a confidencialidade, integridade e autenticidade das informações transmitidas.

   

  Principais benefícios da integração mTLS no WAF da XLabs Security

  Segurança aprimorada: A integração mTLS no WAF da XLabs Security ajuda a evitar conexões não autorizadas e a proteger seus aplicativos que utilizam mTLS contra ameaças externas. A autenticação mútua fortalece a segurança da comunicação entre cliente e servidor, reduzindo o risco de interceptações e ataques man-in-the-middle, até mesmo força bruta.

  Conformidade regulatória: Muitas indústrias exigem a implementação de medidas de segurança rigorosas para proteger informações confidenciais, como dados de saúde ou financeiros. A integração mTLS no WAF da XLabs Security ajuda a atender a essas exigências e a manter a conformidade com padrões como PCI-DSS, HIPAA e GDPR.

  Flexibilidade e controle: Com a integração mTLS, você pode configurar e gerenciar suas políticas de segurança com facilidade, garantindo que apenas dispositivos autorizados tenham acesso a sua aplicação. Isso permite um maior controle sobre suas comunicações e a capacidade de adaptar sua estratégia de segurança conforme necessário.
  Monitoramento e gerenciamento eficientes: Através do nosso painel de controle intuitivo, você pode monitorar e analisar o tráfego de rede em tempo real, identificar possíveis ameaças e responder rapidamente a incidentes de segurança. A integração mTLS no WAF da XLabs Security oferece visibilidade aprimorada e controle sobre suas comunicações protegidas.

   

  Como começar?

  Para começar a usar a integração mTLS no WAF da XLabs Security, basta você informar durante a implantação da aplicação a existência do mTLS na aplicação, ou então, informar via suporte para a ativação dessa funcionalidade em sua aplicação.

• WAF da XLabs Security + ElasticSearch: visão ampla de ameaças em tempo real

  

  Hoje em dia a segurança de aplicações web é um assunto de extrema importância para as empresas, sendo a proteção contra ameaças cibernéticas, como ataques de força bruta, injeção SQL e XSS, fundamental para garantir a integridade e disponibilidade das informações transmitidas através da internet. Por isso, é fundamental contar com soluções eficientes de segurança, como o Web Application Firewall (WAF) da XLabs Security, que agora tem integração com o Elastic Search.

  Acompanhe mais sobre esse aprimoramento do WAF da XLabs Security e saiba quais os benefícios dele!

   

   

  WAF da XLabs Security + Elastic Search

  O WAF da XLabs Security por si só vai muito além dos Web Application Firewalls tradicionais, agregando inteligência artificial para ações preditivas e uma CDN. Com a integração do ElasticSearch a proteção de aplicações web passou a ser mais robusta, tornando possível a correlação de logs de acessos e ataques a aplicações web protegidas pelo WAF/CDN.

  Em outras palavras, é possível ter uma visão mais ampla e completa sobre as ameaças que seu sistema enfrenta. Os logs de acessos e ataques registrados pelo WAF podem ser combinados com outros dados de segurança, como logs de intrusion detection e firewall, permitindo uma análise mais precisa e ágil de possíveis ameaças.

  Além disso, a integração com o ElasticSearch permite a utilização de dashboards interativos e gráficos de tendências, facilitando a visualização de dados importantes, como o número de ataques por tipo, origem geográfica, período de tempo, entre outros. Isso permite que as equipes de segurança tomem decisões baseadas em dados concretos e confiáveis, aumentando a eficiência e efetividade na proteção das aplicações web.

  Com o WAF da XLabs Security, agora unido ao ElasticSearch, é possível ter uma solução completa e integrada de segurança, garantindo a proteção de aplicações web de todas as complexidades contra ameaças cibernéticas, mantendo a integridade e disponibilidade dos dados transmitidos pela internet.

• O que é um WAF?
  

  Firewall’s normais ou modernos e sistemas de prevenção de intrusão não fornecem proteções suficientes para a maioria dos sites voltados ao público ou aplicações Web personalizadas e críticas para os negócios internos de empresas e todos os negócios que envolvem a web. Explicamos como os Web Application Firewall’s podem ajudar os gestores de segurança a proteger melhor esta parte dos sistemas da empresa que ficam expostos à grande rede.

  Uma breve análise

  No final dos anos 90, a maioria das empresas não estavam usando WAF’s para proteger seus servidores Web e suas aplicações. Firewall’s foram a melhor prática, a detecção e prevenção de intrusão ainda estavam amadurecendo. A relativamente baixa complexidade dos aplicativos Web não eram motivos suficientes para justificar um investimento adicional, e os atacantes ainda não tinham motivos financeiros.

  Desde então, as aplicações Web se tornaram mais complexas, contando com linguagens mais avançadas, como HTML5, Java, JavaScript, PHP e para “aplicação de interface rica” (Rich Interface Application ou RIA em inglês), framework’s extensos e bibliotecas de terceiros complexas. Os falsos positivos e hits de desempenho decorrentes de proteções que contavam com tráfego-padrão tornou-se um problema real. Fornecedores de IPS’s tendo que desativar a maioria das assinaturas de proteção de aplicações Web por padrão para reduzir esses problemas. Organizações do tipo A perceberam a necessidade de uma nova abordagem para a segurança de aplicações Web, e adicionaram WAF’s às suas carteiras de produtos.

  Em 2008, o PCI Security Standards Council (PCI SSC) lançou o Padrão de Segurança de Dados PCI (PCI DSS) 1.2 com um requisito de atualização atual de versão 6.6, o que permitiu os WAF’s surgirem como uma alternativa viável para avaliações de vulnerabilidades em aplicações Web.

  O requisito do PCI tem dado um impulso adicional para o mercado de WAF’s, ajudando-o a expandir para além de casos de uso do próprio nicho, especialmente em organizações financeiras e bancárias.

  Infelizmente, muitas empresas e fornecedores WAF usam um baixo padrão de conformidade PCI como meta e não procuram mais do que uma auditoria bem-sucedida.
  Bom a segurança de aplicativos Web exige mais do que uma boa abordagem na seleção da “caixa que irá proporcionar a segurança”. A maioria dos WAFs pode fornecer a marca de verificação PCI, mas, como a história muitas vezes nos faz lembrar, o cumprimento não é automaticamente equivalente com boa segurança.

  Avaliações competitivas para as tecnologias WAF ainda são complicadas e exigem uma prova longa de conceito, porque nomes de funcionalidades semelhantes mascaram discrepâncias significativas na profundidade da segurança. Uma vez em produção, WAF’s continuam a exigir um acompanhamento atento para oferecer um alto valor.

  Esta pesquisa abrange os principais recursos da tecnologia WAF, explica as opções de implantação e fornece diretrizes de seleção. Ele irá ajudar os líderes de segurança responsáveis por projetos de segurança de aplicativos Web para entender melhor os benefícios e desafios da implementação de um WAF.

  A tecnologia

  Firewalls de aplicações Web protegem servidores Web e aplicações Web hospedadas contra ataques na camada de aplicação (Layer 7) e ataques “nonvolumetric” na camada de rede. Ele pode ser implementado como um agente endpoint no servidor Web, um dispositivo de rede software ou hardware, um módulo de software hospedado em um controlador de entrega de aplicativos, um dispositivo virtual ou um serviço na nuvem.

  
  

  Ataques web demandam mais que assinaturas

  Ameaças contra aplicações Web estão bem documentadas. O projeto Open Web Application Security Project (OWASP) Top Ten ou Top10, Exploit-DB, Securityfocus dentre outras organizações, Referenciam elementos que podem ajudar a aumentar a conscientização sobre o cenário de ameaças, proporcionando a justificativa da necessidade de tecnologia dedicada a segurança de aplicativos Web. No entanto, as equipes de segurança muitas vezes não conseguem explicar como WAF’s podem fornecer uma proteção mais específica, especialmente desenvolvidos para a proteção aplicativos Web, diferentes de NGFW’s e IPS’s.

  
  

  Firewall’s e IPS’s fornecem assinaturas, principalmente contra injeções de SQL (SQLi) ou cross-site scripting (XSS), mas não incluem funcionalidades mais avançadas que as tecnologias WAF podem oferecer, tais como:

  1. “Patching virtual”: O nome é um exagero. O WAF pode aproveitar os dados dos testes dinâmicos de segurança na aplicação ou dynamic application security testing (DAST) realizados por ferramentas para sugerir ou permitir controles/assinaturas adicionais para proteção contra as ameaças detectadas. O nível de valor fornecido depende da qualidade da ferramenta de avaliação de vulnerabilidade utilizada.
  2. A política de aprendizagem automática: O mecanismo de segurança WAF ouve solicitações HTTP/Response para domínios Web configurados, cria um mapa de URL’s e seus parâmetros, em seguida, sugere a aplicação de whitelist’s apropriadas (muitas vezes chamado-se modelo de segurança ativo).
  3. Contextualizada inspeção de tráfego Web: WAF’s incorporam mecanismos de inspeção dedicados para protocolos e linguagens da Web, para realizar a decodificação de tráfego e normalização antes de aplicar em contexto de inspeção de segurança. Isso melhora a eficácia da defesa de vulnerabilidades e ataques Web.
  4. Anti-automação: Isso distingue humanos reais de clientes automatizados que interagem com um aplicativo da Web.
  5. Defesa lógica do negócio: WAFs monitoram sessões de usuários para detectar ataques que exploram as transações comerciais, que tem por objetivo realizar atividades maliciosas que interrompem uma prática comercial normal.
  6. Anti-DDoS: WAF’s podem incluir a proteção contra-alvos de aplicativos de negação de serviço distribuída (DDoS), mas não podem atenuar ataques volumétricos. Fornecedores com uma oferta em nuvem, como o XLabs Web Application Firewall por exemplo, muitas vezes fornecem anti-DDoS como diferencial em suas soluções aos seus clientes que utilizam WAF’s.

  Recomendações

  Principais desafios aos gestores de segurança da informação nas empresas:

  Avaliar a Conformidade com o PCI-DSS.

  Avaliar a necessidade de firewall’s de aplicações Web, com base no impacto nos negócios de cada aplicação Web exposta, não importando qual for o cliente, funcionário ou cliente da empresa, em vez de proteger apenas aplicações Web voltadas ao público.

  Avaliar e implementar a tecnologia WAF, em combinação com outras tecnologias e alternativas de segurança, tais como testes de segurança de aplicações e práticas de programação segura.

  Avalie a implantação e qual os casos de utilização são aceitáveis para a sua organização, compreender os desafios específicos para cada um sistema web.

  WAF’s na nuvem (em cloud) são ótimos pois a realização de ajustes da configuração inicial durante o período de aprendizagem podem ser efetuados por equipes de Centros de Operações em Segurança capacitados. Os SOC’s além de efetuar os ‘ajustes finos’ continuamente atualizam as configurações do WAF para obter os melhores benefícios da tecnologia.

  O que os gestores precisam saber

  WAF’s são implantados na frente de servidores Web, e incluem técnicas de proteção especiais dedicadas à proteção de aplicações Web específicas. WAF’s combinam modelos de segurança passivos (que protegem contra ataques conhecidos) e ativos (fazem a entrega de tráfego legítimo somente) para detectar e proteger contra ataques em aplicações Web e reduzir o risco de falsos positivos.

  Os profissionais de segurança às vezes confundem WAF’s com NGFW’s (Firewall’s de nova geração), ou a estimativa de que WAF’s não trazem valor suficiente para justificar o custo, quando comparado com IPS’s. Organizações já equipadas com firewall’s e IPS’s podem ver WAF’s como um investimento exponencial para benefícios incrementais. No entanto, proteções de IPS contra vulnerabilidades Web são baseadas em assinaturas de vulnerabilidades conhecidas.

  Sites corporativos e aplicações Web que transportam as operações críticas de empresas e negócios, como exemplo uma folha de pagamento, ou transações de internet banking e encomendas de comércio eletrônico, muitas vezes incluem uma combinação de código personalizado, com vulnerabilidades auto-infligidas e componentes de terceiros.

  CIO’s não podem decidir deixar servidores web críticos intocados por medo de falsos alertas ou interrupções de serviço, porque linguagens Web complexas (HTML5, JavaScript) dão aos atacantes alvos atraentes.

  Gestores de segurança devem considerar investir em WAF’s, complementando com testes de segurança em aplicativos e proteger o desenvolvimento de seus códigos se sua organização possui websites ou aplicações críticas abertos para a internet.

  Conclusões

  Firewall’s de Aplicações Web (WAF’s) são diferentes dos firewall’s de nova geração (NGFW’s ou Next Generation Firewall) e sistemas de prevenção de intrusão (IPS’s ou Intrusion Prevention System).
  WAFs protegem em um nível especial aplicativos da Web, tanto os conhecidos como também os personalizados de empresas contra ataques na internet.

  Mesmo quando NGFWs e IPSs são implantados, o WAF é muitas vezes a única tecnologia que inspeciona o tráfego da Web de entradas criptografadas e não criptografadas.
  Equipes que entendem como um WAF trabalha e como ele realiza suas tarefas é um fator crítico na decisão de você empregar um WAF. Evitar falsos alertas (“falsos positivos”), em particular, requer atenção específica de um profissional capacitado.

  Empresas tendem a concentrar os seus esforços sobre o cumprimento do WAF em proteger os aplicativos Web personalizados voltados para o público, mas os aplicativos internos muitas vezes são negligenciados, porém são igualmente importantes.

  Também não podemos de deixar de mencionar nossa tecnologia desenvolvida 100% nacionalmente, ao qual defende na nuvem aplicações web, API’s Web, websites e demais sistemas baseados em web: o XLabs Web Application Firewall, que é capaz de aplicar todos os benefícios de um WAF na nuvem, trazendo estabilidade, segurança e alto padrão de criptografia HTTPS/SSL para seu sistema web.

• O que é uma CDN?
  

  Este artigo tem por objetivo explicar uma das evoluções de nossa plataforma, essa evolução está disponível para os clientes desde meados de novembro de 2017. A solução trata-se de uma Content Delivery Network (CDN), que além de dar a performance aos usuários de websites dos nossos clientes, acrescenta mais escalabilidade em nossa rede. Escalabilidade esta horizontal, algo novo em nossa infraestrutura.

  Desde o princípio nossa plataforma já contava com uma escalabilidade vertical, onde recursos de hardware e redes são acrescentados conforme os recursos fossem se esgotando, algo que também nosso IA BOT evita que ocorra, pois trata-se de um robô que analisa o tráfego anômalo e impede que estes tráfegos atrapalhem na saúde do servidor/rede, algo a ser abordado em um artigo futuro.

  CDN ou Content Delivery Network é uma rede de distribuição de informação que fornece o conteúdo web de forma mais rápida a um grande número de utilizadores, através de múltiplos servidores que direcionam o conteúdo ao utilizador com base na proximidade do servidor.

  A missão de uma CDN é praticamente encurtar a distância física entre o cliente e o servidor, melhorando a velocidade de renderização e o desempenho do site, e evitando atrasos ao carregar o conteúdo de uma página Web.

   

  

   

  Neste artigo além de apresentar um dos mais novos serviços implementados na infraestrutura de WAF da XLabs Security, também explicamos como uma CDN funciona e quais seus princípios fundamentais.

   

  Como uma CDN funciona?

  Para minimizar a distância entre os visitantes e o servidor do seu site, a CDN armazena uma versão em cache de seu conteúdo em vários locais geográficos (a.k.a, pontos de presença, ou PoP’s). Cada PoP contém uma série de servidores de cache responsáveis ​​pela entrega de conteúdo aos visitantes dentro de sua proximidade. Em essência, a CDN coloca seu conteúdo em vários lugares ao mesmo tempo, proporcionando uma cobertura superior aos seus usuários.

   

  

   

  O que são POP’s?

  Os POP’s CDN (Points of Presence) são centros de dados estrategicamente localizados responsáveis ​​pela comunicação com os usuários em sua vizinhança geográfica. Sua principal função é reduzir o tempo de ida e volta ao aproximar o conteúdo do visitante do site. Cada POP de CDN normalmente contém inúmeros servidores de cache.

  Quem usa uma CDN?

  Hoje, mais de metade de todo o tráfego mundial já está sendo servido por CDN’s. Esses números estão rapidamente subindo a cada ano que passa. A realidade é que, se alguma parte do seu negócio estiver online, existem poucos motivos para não usar uma CDN.

  No entanto, mesmo como um serviço gratuito, as CDN’s não são para todos. Especificamente, se você estiver executando um site estritamente localizado, com a grande maioria de seus usuários localizados na mesma região que sua hospedagem, há pouco benefício em utilizar uma CDN . Nesse cenário, o uso de uma CDN pode realmente piorar o desempenho do seu site, introduzindo outro ponto de conexão não essencial entre o visitante e um servidor já localizado. Ainda assim, a maioria dos sites tende a operar em uma escala maior, tornando o uso de CDN uma escolha popular nos seguintes setores:

  • Propaganda
  • Mídia e entretenimento
  • Jogo online
  • Comércio eletrônico
  • Cuidados de saúde
  • Ensino superior
  • Governo
  • Setores financeiros
  • Setores bélicos
  • Provedores de Mitigação DDoS

   

  Web Application Firewalls

  As redes de entrega de conteúdo empregam tecnologias de Web Application Firewalls. Em topologia de redes, isso significa que CDNs são implantadas na frente do(s) servidor(es) de backend. Esta posição, à beira do perímetro de sua rede, oferece várias vantagens importantes além da capacidade inata de uma CDN de acelerar a entrega de conteúdo.

  Hoje, a topologia de WAF’s está sendo alavancada por CDN multi-purpose para fornecer os seguintes tipos de soluções.

  1 – Segurança aos websites

  A cibersegurança trata de gerenciar o acesso externo ao seu perímetro protegido, bloqueando idealmente todas as ameaças antes de serem efetivamente utilizadas contra os seus alvos.

  Implantado na ponta da sua rede, uma CDN está perfeitamente situada para atuar como uma vedação virtual de alta segurança e prevenir ataques em seu site e aplicativo web. A posição de ponta também torna uma CDN ideal para bloquear inundações de DDoS, que precisam ser atenuados fora de sua infraestrutura de rede principal.

  2 – Balanceamento de carga

  O balanceamento de carga é como ter um “guarda de trânsito” posicionado na frente de seus servidores, alternando o fluxo de pedidos recebidos de forma que os engarrafamentos sejam evitados.

  Claramente, a topologia de proxy reverso de uma CDN é ideal para isso, assim como o destinatário padrão de todo o tráfego recebido. Além disso, a topologia de proxy reverso também fornece uma CDN com visibilidade aprimorada no fluxo de tráfego. Isso permite avaliar com precisão a quantidade de solicitações pendentes em cada um dos servidores backend, permitindo assim uma distribuição de carga mais efetiva.

   

  A evolução das CDN’s 

  Em geral, a evolução da CDN pode ser segmentada em três gerações, cada uma introduzindo novas capacidades, tecnologias e conceitos para sua arquitetura de rede. Trabalhando em paralelo, cada geração viu o preço da tendência dos serviços de CDN, marcando sua transformação em uma tecnologia de mercado de massa.

  

   

• Informações sobre o bloqueio "Este WebSite está protegido!"

  Durante a utilização do nosso Web Application Firewall, nossos clientes ao utilizarem suas aplicações protegidas por nossa infraestrutura se deparam com mensagens de bloqueios, porém cada mensagem de bloqueio significa ocasiões diferentes.
  Neste tópico iremos abordar a mensagem de bloqueio do Web Application Firewall demonstrada na imagem a seguir:

   

  

   

  Esta mensagem é devido as configurações do Web Application Firewall, ao verificar os padrões da RFC's (2616, 7230, 7231, 7232, 7233, 7234, 7235, 2817, 5785, 6266, 6585) aos quais representam os padrões HTTP, quando é percebido algo anormal aos padrões definidos pela IETF.org o Web Armor Zone descarta a conexão exibindo a tela demonstrada no momento do bloqueio exibindo o erro "423 Locked" ou "Este WebSite está protegido!".

   

  

   

  As informações sobre a conexão são armazenadas e analisadas em tempo real por nossos robôs de IA e o nosso Centro de Operações em Segurança é notificado dos casos mais críticos de anomalias também em tempo real.
  
  Caso a conexão seja considerada um ataque por nossos robôs de Inteligência Artificial, nossa nuvem de proteção toma ações proativas para o bloqueio da ameaça detectada.
  
  Ou caso a conexão seja legítima e o bloqueio persistir, recomendamos os administradores responsáveis pelo web-site entrarem em contato via suporte com a XLabs Security.
  
  Literatura:
  RFC2616
  RFC7230
  RFC7231
  RFC7235
  RFC2616 by w3.org

• Informações sobre o erro "Hosting Error"

  Durante a utilização do nosso Web Application Firewall, nossos clientes ao utilizarem suas aplicações protegidas por nossa infraestrutura se deparam com mensagens de alertas ou bloqueios, porém cada mensagem significa ocasiões diferentes.
  Vamos abordar neste tópico inicial a mensagem de alerta "Hosting Error" demonstrada na imagem a seguir.

  
  Muitos pensam se tratar de um bloqueio gerado por nossa ferramenta, porém, esta mensagem aponta instabilidades na aplicação web acessada, pode ser por alguma manutenção na aplicação, instabilidades no link entre nosso Web Application Firewall e o Data-Center do cliente, ou então algum erro específico na aplicação web que foi suprimido de emitir informações, informações estas que podem ser sensíveis na tela dos usuários comuns, por isso mascaramos o erro com uma tela amigável de "Hosting Error", conforme explicamos e demonstramos à seguir exemplos...

   

  

   

  Ao analisarmos as requisições utilizando ferramentas que vem nos próprios browser's, ao usarmos o F12 do Chrome, na aba "Network", identificamos o erro HTTP 500, conforme demonstramos na imagem a seguir:

   

  

   

  Esta mensagem é proposital e tem por objetivo esconder possíveis erros na aplicação web do cliente, são erros que podem exibir informações sensíveis do sistema que hospeda a aplicação do cliente.
  
  Geralmente são ocasionadas por erros "50x" onde o 'x' são números, estes erros podem ser:
  500 Erro interno do servidor
  501 Não implementado
  502 Bad Gateway
  503 de serviço indisponível (Service Unavailable)
  504 Gateway Time-Out
  505 HTTP Version not supported
  
  Para maiores informações sobre estes e outros códigos de estado HTTP podemos encontrar em: Wikipedia Lista de Códigos de estado HTTP
  
  Se o erro persistir, contate o administrador do website acessado, ou então se você for um dos administradores do website entre em contato conosco através de nossos canais de comunicação disponibilizados através deste portal de suporte.

• Informações sobre a tela "Hosting Block"

  A tela "Hosting Block" é uma funcionalidade fornecida pela XLabs Security, apesar de ser parecida com a tela de "Hosting Error", ela tem um objetivo e uma origem diferente de um erro propriamente dito. Esta tela é exibida quando o servidor web que hospeda a aplicação do cliente está respondendo com um código HTTP "403 Forbidden".

   

  

   

  Existem várias razões potenciais pelas quais isso pode ocorrer, e a tela "Hosting Block" serve como uma forma de comunicar isso de maneira clara e amigável, enquanto protege informações sensíveis do servidor.

  1. Bloqueio de conexões pelo servidor de origem: O servidor web que hospeda a aplicação do cliente pode estar bloqueando as conexões recebidas. Isso pode ser devido a configurações de firewall, listas de controle de acesso ou outras configurações de segurança no servidor de origem.

  2. O servidor de WAF não está em whitelist: O servidor de WAF deve ser adicionado à whitelist no arquivo .htaccess ou no servidor web para acessar livremente a aplicação web. Se o WAF não estiver na whitelist, o servidor de origem pode rejeitar as conexões, resultando em um erro "403 Forbidden".

  3. Plugins de segurança do website: Alguns plugins de segurança, como os plugins de WAF do WordPress, podem estar bloqueando o IP do servidor de WAF. Esses plugins são projetados para proteger o site contra ataques maliciosos, mas se estiverem configurados de forma inadequada, podem acabar bloqueando o tráfego legítimo.

  4. Limitações de segurança na aplicação de origem: Por vezes, as próprias aplicações web têm mecanismos de segurança que podem resultar em um erro "403 Forbidden". Isso pode ser devido a limites de taxa, regras de autenticação ou outras medidas de segurança.

  A tela "Hosting Block" é projetada para lidar com esses problemas de maneira eficiente. Em vez de exibir o erro "403 Forbidden" cru, que pode ser confuso e potencialmente revelar detalhes do servidor, a tela "Hosting Block" fornece uma explicação amigável do problema. Isso ajuda os usuários e administradores da aplicação web a entenderem o que está acontecendo e como eles podem corrigir o problema, ao mesmo tempo em que mantém as informações sensíveis do servidor seguras.

• Protegendo seu website implementando o WAF da XLabs Security

  Uma das ações para a proteção dos websites, portais web e API's web de nossos clientes através do nosso WAF e CDN, o Web Armor Zone da XLabs Security é a transferência correta do tráfego dos portais a serem protegidos para uma zona especial, criada e mantida pela XLabs Security ao qual efetua o balanceamento e direcionamento ao Data-Center mais próximo dos usuários do cliente conforme a sua Geo Localização.
  
  Assim os usuários das aplicações web de nossos clientes podem experimentar uma melhor experiência na navegação e utilização dos sistemas HTTP/HTTPS protegidos por nossa plataforma de defesa e estabilidade.
  
  Essa melhor experiência se da na medida que a latência é reduzida e os usuários das aplicações de nossos clientes passam a receber uma descarga de informações e Bytes de forma inicial rápida, sem um acréscimo de milissegundos na espera dessas informações chegarem ao destino, assim melhorando a experiência ao carregar os websites e informações de uma maneira mais rápida.
  
  São vários os fatores que melhoram o desempenho de uma aplicação web ao utilizar nosso sistema de CDN e WAF, como citamos no parágrafo anterior, ao reduzirmos a latência do link, entregando um Data-Center mais próximo aos usuários da aplicação do cliente temos uma melhora no desempenho, porém não ficamos somente neste desempenho melhorado, em nosso WAF trazemos uma melhoria de performance ao qual a entrega dos primeiros Bits e Bytes ocasiona uma melhor entrega dos "Primeiros Bytes", melhorando o carregamento de páginas ao reduzir a latência também do "TTFB" ou "Time To First Byte", ou tempo para o primeiro Byte, é o tempo que nosso Web-Server de WAF demora para trazer ao usuário da aplicação web os primeiros Bytes contidos na página web do nosso cliente. Padrão este melhorado da versão 3 de nosso WAF para a versão 4.
  
  Todos estes parâmetros fazem a diferença quando entregamos um serviço de excelência ao cliente e aos usuários de nossos clientes, procuramos sempre melhorar estas questões de performance das aplicações web por nós protegidas, além de claro, entregarmos um dos melhores padrões de segurança em aplicações web que o mercado nacional até o momento presencia.

   

  Para solicitar a implantação de novas URL's, utilize este formulário: Formulário de atendimento.

  Selecione em "Motivo do Contato", "Implementação de novas URL's" que irá demonstrar o formulário de implantação.

  
  Bom, após uma breve explicação das melhorias empregadas em nosso ambiente especial de proteção, um dos passos principais para o nosso cliente efetuar é a transferência de seu tráfego via alteração do DNS, especificamente na aplicação que o cliente deseja proteger, exemplo, podemos pegar um website principal de uma empresa, a empresa.com, o website principal podemos ter duas opções, muitos clientes utilizam uma entrada do tipo "A" no DNS, apontando o www.empresa.com e o "Naked-Domain" o "domínio puro" empresa.com apontados ambos para o IP do servidor web que o hospeda, exemplo, www.empresa.com e empresa.com apontados para o IP 123.124.125.126.
  
  Solicitamos para o cliente que a entrada do tipo "A", www.empresa.com seja apagada e recriada como tipo "CNAME" do www.empresa.com apontando para nossa zona especial "web.armor.zone", com um TTL abaixo dos 5 minutos, aconselhamos que seja utilizado um TTL de 60 segundos, para a rápida transferência aos nossos sistemas e Data-Centers.
  
  O cliente pode inclusive acompanhar a transferência do seu website aos nossos sistemas usando um sistema para verificação da replicação dos DNS's globais, exemplo o DNS Checker: https://dnschecker.org/
  
  Após a transferência solicitamos o cliente a transferência do "Naked-Domain" ou domínio puro aos nossos IP's responsáveis por responderem aos "Naked-Domain's", aos quais são:
  
  35.198.32.34
  35.198.61.223
  
  Simplesmente recriando a entrada do "naked-domain" empresa.com, do tipo A, com o IP mencionado anteriormente, inclusive, podendo ser criada entradas duplicadas, do "naked-domain", apontando uma para cada IP nosso, criando um balanceamento de carga entre nossos dois DC's.
  
  Ficando algo semelhante a esta imagem:

  

  Para clientes que utilizam outros sistemas de DNS's que utilizam a proteção também de WAF para as aplicações Web, recomendamos desativar a proteção dos Proxys destes serviços, uma vez que nossos proxys serão os responsáveis por estas proteções neste momento.
  
  Ficando algo parecido com esta imagem:

  

   

  Após se certificar que tudo está ok e passando por nossas infraestruturas, os DNS's mundiais começam a apontar o website da instituição ao web.armor.zone que por sua vez analisa todo o tráfego e direciona somente os acessos legítimos ao seu destino, que é o servidor web de nossos clientes.
  
  Ao utilizar o "HTTPS Free" de nosso sistema, o cliente pode experimentar de 20 a 30 minutos a instabilidade nos acessos via HTTPS, até que nossos servidores possam gerar os certificados através da Autoridade Certificadora "Lets Encrypt" e estes mesmos certificados sejam sincronizados em toda a nossa rede de Data-Centers mundial.
  
  Os nossos analistas serão os responsáveis por monitorar suas aplicações para verificações de ByPass, regras que possam a vir impactar sua aplicação web, caso nossas mitigações sejam habilitadas durante algum ataque real, regras de ByPass, são geralmente aplicadas a tráfegos genuínos que por ventura nosso WAF possa detectar como um comportamento inseguro, ou anormal às RFC's do HTTP normal.
  
  Durante o período de adaptação de tráfego, nossos WAF's atuam somente em modo "Apenas Detecção" não ocasionando bloqueios indevidos nas aplicações web protegidas por nosso sistema a acessos genuínos originados por usuários reais da aplicação web de nosso cliente.
  
  Mesmo durante o período de adaptação de tráfego, nossos WAF's atuando em somente "Apenas Detecção", através de nossa Inteligência Artificial, os dispositivos de WAF's reagem a ataques confirmados, bloqueando e sinalizando a ameaça detectada na tela de "WAF Intelligence" no painel do 'Control", onde demonstra atuações do nosso WAF durante ataques reais direcionados às aplicações web de nossos clientes.
  
  Após o período de adaptação do tráfego, nossos clientes podem optar por ativarem ou não as proteções preditivas de nosso WAF, onde as mitigações são ativadas, todo e qualquer tráfego anômalo não será enviado ao servidor web de nosso cliente.
  
  Com as mitigações preditivas ativas, nosso WAF começa a responder com códigos de resposta "423" a toda requisição que ele considerar suspeita e que deva ser bloqueada.
  
  Em casos de clientes dos planos "Empresarial Plus" onde a mitigação Anti-DDoS em camada de aplicação (Layer 7) é ativa, quando um usuário ou robô atinge a marca de requisições por segundo estabelecidas em conjunto entre cliente e o nosso SOC para a aplicação web protegida, as requisições excedidas são descartadas utilizando códigos de resposta "420", sinalizando que o usuário da aplicação de nosso cliente excedeu o número de requisições por segundo estabelecidas como "saudáveis" para a aplicação web.