Leia sobre dicas e funcionalidades da GoCache CDN para melhorar a seguranca do seu site, loja virtual ou app mobile.

,

Firewall Global na GoCache – proteção simples e eficiente para seus sites

Lançamento GoCache – Firewall Global

Novidade saindo do forno da nossa equipe de desenvolvimento! Clientes GoCache com múltiplos domínios em nossa plataforma contam com uma nova funcionalidade, o Firewall Global.

 

Qual é a diferença do Firewall Global?

 

Na GoCache todas as configurações são isoladas por domínio. O Firewall aplica as regras de whitelist/blacklist somente para o domínio onde foram configuradas.

Já o Firewall Global permite que as regras sejam aplicadas para os demais domínios presentes na conta.

Isso é extremamente útil para clientes com múltiplos domínios, como por exemplo é o caso das plataformas de e-commerce e agências digitais.

No dia a dia da operação deste tipo de cliente são comuns as tentativas de ataques. Muitas vezes sem saber qual site era o ofensor, havia a necessidade de criar uma regra de Firewall em cada domínio para mitigar esses acessos maliciosos na GoCache. Agora, com um único clique (ou chamada em nossa API), uma regra pode ser aplicada a todos os domínios de uma só vez.

 

Como funciona o Firewall Global?

 

No menu “Segurança” do seu painel de controle, acesse a aba “Firewall” e crie a regra desejada. Você verá que agora os botões exibidos na conclusão da regra são “Salvar para este domínio”, “Salvar para todos domínios”, além do botão “Cancelar”.

 

firewall global

A opção “Salvar para todos domínios” faz com que a regra seja automaticamente replicada para os demais domínios presentes na conta.

É possível identificar a regra global na lista de regras pois ela é assinalada como aplicável a todos os domínios:

firewall global regras

A regra global é exibida na lista de regras de firewall no mesmo formato para todos os domínios de uma mesma conta, no exemplo deste artigo a regra foi criada para o domínio gocache.com.br, veja o que aparece no painel do domínio gocache.net:

firewall global dominio extra

 

Com a implantação do Firewall Global as configurações de controle acesso ficam ainda mais fáceis e práticas para que administra múltiplos domínios na plataforma GoCache.

 

Safer, Faster, GoCache!

 

, ,

Como proteger seu site, loja virtual ou APP contra SQL Injection, XSS e Brute-Force usando WAF

Como proteger seu site ou loja virtual com WAF

 

Quem não está preocupado com a segurança da sua aplicação online? Quer saber como proteger seu site ou loja virtual com WAF? Vamos demonstrar neste artigo.

A configuração da segurança na camada de aplicação é crucial. Falhas podem levar a enormes prejuízos, financeiros e de reputação da sua marca.

Se você pensa que este é um problema exclusivamente das grandes empresas, ledo engano. Mais de 60% dos ataques têm como alvo as empresas de pequeno e médio porte. E a má notícia é que, caso um ataque destes seja bem sucedido, mais de 60% destas empresas irá fechar por não ter recursos suficientes para se recuperar.

Para um blog, perda ou deformação de conteúdo. Uma loja virtual pode sofrer roubo de dados, ou até mesmo fraudes em suas transações comerciais. Um aplicativo móvel pode ter suas chamadas de API clonadas e sofrer todos estes sintomas. A área administrativa de qualquer destas aplicações pode ser indevidamente acessada e o estrago pode ser irreparável.

Quem quer correr estes riscos?

Mas a pergunta que importa mesmo é, como saber se o seu site/loja/app está vulnerável? Ou se está na “mira” de algum usuário mal-intencionado?

Um case de uso do WAF

Resolvemos abrir um case para vocês, o do nosso próprio site – www.gocache.com.br

Em nosso site utilizamos o WordPress em sua última versão, com todos plugins atualizados e hospedado em servidor virtual.

Pouco antes de lançarmos nossa solução de WAF, partimos para o teste final, nada mais justo que testar a ferramenta em nosso site de produção.

A situação inicial

Ativamos o Web Application Firewall com alto critério de filtragem e em modo simulação, para que apenas fossem gerados logs, já que não queríamos arriscar um falso positivo.

Eis o resultado:

waf dia1

Tivemos apenas uma tentativa de acesso suspeita. Eis os detalhes do incidente:

log waf dia1

Pelas características do incidente deduzimos tratar-se de um robô, provavelmente sondando vulnerabilidades.

No segundo dia com a ferramenta ativa, percebemos que este tipo de acesso não era raro:

waf dia2

Foram 25 acessos que a ferramenta identificou como suspeitos.

Ao checar os detalhes destes eventos, identificamos o seguinte:
log1 waf dia2
log2 waf dia2

 

Além do acesso de um robô semelhante ao do primeiro dia, também houve tentativas de quebra de senha (brute-force) na área administrativa.

 

O tamanho do problema

Com o tempo o volume de acessos suspeitos foi aumentando consideravelmente. Ainda estávamos utilizando o modo de simulação da ferramenta para termos certeza de que não ocorreriam falsos positivos, ou que caso ocorressem poderíamos identificar e criar uma regra de filtragem que evitasse o falso positivo quando habilitássemos o modo de bloqueio.

Seguimos com o plano inicial, de gerar logs durante uma semana antes de ativar o bloqueio. Veja a que ponto chegamos:


waf dia4

waf dia4 pag2

log waf dia3

 

Sim, 14 páginas de log para o dia 13, apenas uma semana após o início do uso da ferramenta. Mais de 400 tentativas de ataque ao nosso site em apenas um dia.

 

A Solução

A esta altura já tinhamos dados suficientes para configurar uma regra de filtragem específica e então modificar o modo de funcionamento do WAF para “bloquear” ao invés de “simular”:

regra waf login

 

Note que para esta regra específica colocamos o WAF em modo “desafiar” ao invés de “bloquear”.  Isso porque para o tipo de ataque que identificamos, feito via robô, o desafio é uma medida um pouco menos drástica e quase tão eficiente quanto o bloqueio. O resultado desta regra é a exibição desta tela antes de apresentar os campos para autenticação na área administrativa do WordPress:

tela desafio waf

 

Com isso ficamos tranquilos para ativar o bloqueio completo dos acessos suspeitos.

 

Os Benefícios

O resultado, além da segurança da aplicação, é a economia de recursos computacionais e de rede, uma vez que os acessos bloqueados no WAF ficam na borda e não consomem a banda na infraestrutura de hospedagem.

Ou seja, além de proteção você também economiza.

Acreditamos que o uso de WAF não é mais uma opção, mas sim uma necessidade, e quem deixar para depois pode não ter tempo para se arrepender. É melhor prevenir do que remediar!

 

Melhores práticas de segurança em aplicações web

Melhores Práticas de Segurança em Aplicações Web

 

Se você está lendo este artigo, provavelmente está bem ciente da importância da segurança em aplicações web. É possível que você já tenha colocado em prática algumas medidas mencionadas aqui. Mas, como muitos proprietários de websites, apps e lojas virtuais, provavelmente não fez o suficiente para cobrir todas as áreas necessárias.

 

Se o seu site já foi afetado por algum tipo de ataque DDoS, ou se você leu a respeito do grande ataque quem a empresa Dyn sofreu no final de 2016 derrubando milhares de sites relevantes, então você sabe que esta é uma grande preocupação. Como mostrado no gráfico abaixo, o número de ataques DDoS têm crescido consistentemente ao longo dos últimos anos e a tendência é que isso continue piorando.

 

ddos evolutionfonte

 

Quer saber o tamanho do problema? Tem um site que monitora os DDoS em tempo real:

http://www.digitalattackmap.com/#anim=1&color=0&country=ALL&list=0&time=17273&view=map

 

Ataques DDoS ocorrem na camada de rede, são por natureza volumétricos (em sua maioria) e dependem do seu provedor de hospedagem ou datacenter para serem apropriadamente mitigados. Normalmente, quando ocorrem, os provedores de infraestrutura tomam as providências necessárias para restabelecer o serviço.

Subindo alguns níveis no modelo OSI, voltemos à camada de aplicação. Embora não haja maneira de garantir 100% de segurança, pois é impossível prever tudo, existem medidas que podem ser utilizadas para reduzir as chances de ocorrência de problemas de segurança em aplicativos web. Quanto mais destas medidas forem tomadas simultâneamente, mais protegida estará sua aplicação.

 

 

Criar um plano de segurança para aplicações web

 

O primeiro passo para assegurar-se que você está utilizando as melhores práticas de segurança para aplicações web é ter um plano traçado. Com frequência as empresas adotam uma abordagem desorganizada para esta situação e acabam realizando muito pouco. Sente-se com sua equipe de segurança de TI para desenvolver um plano de segurança detalhado e acionável. É importante que este plano esteja alinhado com os objetivos da sua organização.

 

Por exemplo, talvez você queira melhorar seu compliance, ou talvez você precise proteger sua marca. É necessário priorizar quais aplicativos devem ser protegidos primeiro e como eles serão testados. Você pode optar por fazê-lo manualmente, através de uma solução em nuvem, através de software específico, de um provedor de serviços gerenciados ou por outros meios.

 

Embora o plano de segurança e a lista de verificação de cada empresa sejam diferentes e dependam da arquitetura de sua infraestrutura, é importante que você defina especificamente quais os requisitos de segurança a serem atendidos e os critérios para avaliação. A OWASP (Open Web Application Security Project), grupo especializado em segurança online, criou um checklist bem detalhado que você pode utilizar como base para a sua avaliação – link.

 

Além disso, se sua organização é grande o suficiente, seu plano deve relacionar os indivíduos dentro da organização que serão responsáveis pela manutenção contínua dessas melhores práticas. Finalmente, não se esqueça de levar em conta os custos em que sua organização incorrererá ao engajar essas atividades, pois este pode ser um fator decisivo na hora de priorizar.

 

Realizar um inventário das suas aplicações web

 

É provável que você não tenha uma ideia muito clara sobre quais aplicativos web sua empresa utiliza. Na verdade, a maioria das organizações tem muitos aplicativos “rogue” rodando sem saber, até que algo dê errado. Você não pode esperar manter uma boa política de segurança em aplicações web sem mapear detalhadamente quais aplicativos sua empresa utiliza.

 

Quantos são? Onde estão localizados? Executar esse inventário pode ser uma tarefa trabalhosa e é provável que leve algum tempo até sua conclusão. Ao fazê-lo, anote a finalidade de cada aplicação. Quanto maior a organização, maiores as chances de encontrar aplicações redundantes ou até mesmo inúteis. O inventário virá a calhar para as próximas sugestões, por isso invista o tempo necessário e certifique-se de obter os detalhes de cada aplicação utilizada.

 

Priorize suas aplicações web

 

Depois de concluir o inventário de seus aplicativos web, classificá-los em ordem de prioridade é o próximo passo lógico. Sem priorizar quais aplicativos focar primeiro, você terá dificuldade em fazer qualquer progresso significativo.

 

Classifique as aplicações em três categorias:

 

  • Crítico
  • Importante
  • Normal

 

As aplicações críticas são principalmente aquelas que podem ser acessadas externamente e contém informações de clientes. Estas são as aplicações que devem ser geridas em primeiro lugar, pois são as mais suscetíveis como alvos a serem exploradas por hackers. As aplicações importantes podem ser de uso interno ou externo e podem conter algumas informações confidenciais. Aplicações normais têm muito menos exposição, mas devem ser incluídas em testes por precaução, mesmo que em um segundo momento.

 

Categorizando suas aplicações assim você pode focar testes extensivos nas aplicações críticas e usar testes menos complexos (e caros) nas demais. Isso permite que você faça o uso mais eficaz dos recursos da empresa ao mesmo tempo em que pode alcançar resultados significativos com maior velocidade.

 

Priorizar Vulnerabilidades

 

Conforme você avalia sua lista de aplicativos web antes de testá-los, é necessário decidir quais vulnerabilidades valem a pena eliminar e quais não são tão preocupantes. A maioria das aplicações web tem muitas vulnerabilidades. Por exemplo, dê uma olhada no relatório abaixo, que avaliou e categorizou 9000 sites infectados:

 

hacked appsfonte

 

Eliminar todas as vulnerabilidades de todas as aplicações web não só não é possível como nem mesmo vale o seu tempo.

 

Mesmo depois de categorizar suas aplicações de acordo com a importância, será necessário um investimento considerável de recursos para analisá-las. Limitando os testes apenas às vulnerabilidades mais ameaçadoras, você economizará muito tempo e fará o trabalho muito mais rápido. Quanto à determinação das vulnerabilidades a serem focadas, isso realmente depende das aplicações que você está usando. Existem algumas medidas de segurança padrão que devem ser implementadas (discutidas mais adiante), porém vulnerabilidades específicas de aplicativos precisam ser pesquisadas e analisadas.

 

Mantenha em mente também que, à medida que o teste evolui, você pode perceber que ignorou certas questões importantes. Não tenha medo de interromper os testes para redefinir prioridades ou focar em vulnerabilidades adicionais. Lembre-se que no futuro este trabalho será muito mais fácil, pois será iterativo, o esforço inicial é o mais trabalhoso.

 

Executar aplicativos usando o mínimo de privilégios

 

Mesmo depois que todas as suas aplicações web forem avaliadas, testadas e sanitizadas contra as vulnerabilidades mais problemáticas, você não está a salvo. Cada aplicativo web possui privilégios específicos em computadores locais e remotos. Esses privilégios podem, e devem, ser ajustados para aumentar a segurança. Sempre use as configurações menos permissivas para todas as aplicações web. Isso significa que as aplicações devem ser “amarradas”. Somente pessoas com autorizações de alto nível devem poder fazer alterações no nível de sistema.

Este é um fator a ser considerado em suas avaliações iniciais, caso contrário você terá que repassar toda a lista ajustando as permissões de acordo. Para a vasta maioria das aplicações apenas os administradores de sistemas necessitam de acesso completo. A maioria dos outros usuários pode realizar o necessário com configurações minimamente permissivas. No caso improvável em que privilégios são ajustados incorretamente para um aplicativo e certos usuários não podem acessar os recursos de que precisam, o problema pode ser tratado pontualmente. É muito melhor ser demasiado restritivo nesta situação do que ser demasiado permissivo.

 

Proteja-se mesmo durante o processo de avaliação

 

Mesmo uma empresa pequena e simples pode levar semanas – ou até meses – para listar seus aplicativos web e fazer as alterações necessárias. Durante esse período o negócio pode estar vulnerável a ataques, portanto é crucial utilizar as ferramentas adequadas para evitar maiores problemas. Para isso existem algumas opções:

 

  • Remover funcionalidades de determinados aplicativos: se a funcionalidade torna o aplicativo mais vulnerável a ataques pode valer a pena restringir o seu uso.
  • Use um WAF (Web Application Firewall) para proteção contra as vulnerabilidades mais preocupantes.

como funciona wafO firewall de aplicação web filtra e obstrui tráfego HTTP indesejável e ajuda a blindar contra XSS, SQL injection e muito mais.

 

Durante todo o processo as aplicações web existentes devem ser monitoradas continuamente, para assegurar que não estão sendo violadas por terceiros. Se sua empresa, ou site, sofre um ataque durante este período, identifique o ponto fraco e faça a correção antes de continuar com o processo de checagem e sanitização. Você deve adquirir o hábito de documentar cuidadosamente as vulnerabilidades e como elas devem ser tratadas, para que as ocorrências futuras possam ser solucionadas de forma mais rápida e eficaz.

 

Use cookies de forma segura

 

Outra área que muitas organizações não aborda cuidadosamente é o uso de cookies. Os cookies são incrivelmente convenientes, tanto para empresas quanto para usuários. Eles permitem que os usuários sejam lembrados pelos sites que visitam, para que visitas futuras sejam mais rápidas e, em muitos casos, mais personalizadas. No entanto, cookies também podem ser manipulados por hackers para obter acesso a áreas protegidas. Apesar de não ser necessário interromper completamente o uso de cookies – o que seria um grande retrocesso em muitos aspectos – é necessário fazer ajustes a fim de minimizar o risco de ataques.

 

  1. Nunca use cookies para armazenar informações altamente sensíveis ou críticas, por exemplo não use cookies para lembrar as senhas dos usuários, pois isso facilita muito aos hackers a obtenção de acesso não autorizado.
  2. Você também deve ser conservador ao definir o prazo de expiração para os cookies. Claro, é bom saber que um cookie permanecerá válido para um usuário por meses, mas a realidade é que cada cookie representa um risco de segurança e quanto mais tempo durar, maior o tempo de exposição ao risco.
  3. Finalmente, considere criptografar as informações armazenadas nos cookies que você usa, isto já vai dificultar muito o uso de forma maliciosa.

 

Implementar as seguintes sugestões de segurança web

 

Além do que já mencionamos, existem algumas outras sugestões de segurança de aplicações mais “imediatas” que você pode implementar:

 

  • Utilize HTTPS e redirecione todo o tráfego HTTP para HTTPS;
  • Evite ataques de cross-site-script (XSS) usando o cabeçalho de segurança x-xss-security;
  • Implemente uma política de segurança de conteúdo;
  • Nunca é demais lembrar, use senhas fortes que empregam uma combinação de letras minúsculas e maiúsculas, números e símbolos especiais, etc.

 

Conduzir Treinamentos para Conscientização de Segurança em Aplicações Web

 

Em uma empresa, são grandes as chances de que apenas um punhado de pessoas compreenda a importância da segurança em aplicações web. A maioria dos usuários tem apenas a compreensão mais básica do problema e isso pode torná-los descuidados. Usuários sem instrução não conseguem identificar apropriadamente os possíveis riscos de segurança. Em essência, educar a todos sobre segurança em aplicações web é uma ótima maneira de envolver a organização no ato de encontrar e eliminar vulnerabilidades. Com isso em mente, considere a possibilidade de trazer um especialista em segurança de aplicativos web para conduzir treinamentos de conscientização aos seus funcionários. Isso é muito importante para ajudar na implementação e manutenção das melhores práticas.

Manter as melhores práticas de segurança em aplicativos web é um esforço de equipe. Sua segurança como um todo é limitada ao elo mais fraco, seja sistema ou membro da equipe. Mantenha isso em mente e busque identificar constantemente o elo mais fraco a fim de fortalecê-lo.

As 3 camadas de segurança na GoCache CDN

WAF, SmartRules e Firewall – 3 camadas de proteção para o seu site

 
Na GoCache um é pouco, dois é bom e três é demais!

 

Além dos benefícios que o Firewall e o WAF proporcionam, você ainda conta com o auxilio das nossas exclusivas e extraordinárias SmartRules, as regras que permitem customização inigualável.

 

Defina áreas específicas de sua aplicação e em questão de segundos as SmartRules serão aplicadas. Nosso painel dá acesso em tempo real aos eventos de segurança de qualquer camada. É um conjunto de tecnologias que proporciona flexibilidade e robustez inéditos no mercado!

 

As camadas (por ordem de processamento/prioridade):

 

2. Firewall
3. WAF

 

Conhecendo um pouco mais sobre cada uma das camadas:

 

# 1 camada: SmartRules

 

Com as SmartRules, é possível criar regras customizadas para determinadas áreas da sua aplicação, essa é a camada com a maior prioridade. As regras criadas nessa camada se sobrepõe às das outras camadas. Ative e desative as regras de Firewall, crie novas regras, ou altere todas as políticas de segurança do WAF para determinadas áreas de sua aplicação através das SmartRules.

 

# 2 Camada: Firewall

 

Crie um conjunto de regras para bloquear acessos indesejados, ou permitir acessos bem-vindos em toda a sua aplicação utilizando os seguintes critérios:

– Endereço IP/Range
– Pais
– Continente
– User Agent
– Referer Host
– URI

 

# 3 Camada: WAF

 

O WAF – Web Application Firewall – é uma funcionalidade que ajuda a proteger toda a sua aplicação das vulnerabilidades mais comuns na Internet: padrões comuns de ataques, SQL Injections e Cross-site scripting (XSS). Configure o nível de segurança e o modo de bloqueio desejado e pronto, toda a sua aplicação estará protegida.

 

– Níveis: Alto, Médio e Baixo

– Modos:

  • Simular: Entenda melhor o seu tráfego sem que os bloqueios sejam aplicados, qualquer acesso considerado “suspeito” será exibido no log de eventos em tempo real.
  • Bloquear: Bloqueia efetivamente qualquer atividade incomum em toda a aplicação.
  • Desafiar: Aplica um desafio(reCAPTCHA do Google) assim que identifica algo incomum no seu tráfego. Você define o tempo válido para esse desafio e, caso queira expirar os desafios temporários, pode fazê-lo imediatamente com um simples clique em seu painel de controle.

 

 Segurança para sua aplicação web como você nunca viu antes!

 

Go Faster. GoCache!

SmartRules para WAF – Controle total da segurança nas suas mãos

O Carnaval está chegando, mas a GoCache não pára! Anunciamos o lançamento das SmartRules para WAF! Esta nova funcionalidade permite tornar seu WAF flexível, para que você configure o acesso às áreas sensíveis do seu site como preferir.

Como funcionam as SmartRules para WAF

As possibilidades são infinitas, você especifica o critério(ou critérios) para o qual uma regra será aplicada:

waf criterios

As opções de critério são:

  • URL
  • Método HTTP
  • Cookies
  • User Agent
  • HTTP Referer
  • Endereço ou Range de IP
  • País de Origem
  • Continente de Origem

 

Em seguida seleciona qual o tipo de ação a ser tomada quando o critério for satisfeito:

 

waf acoes

As ações possíveis são:

  • Whitelist – libera o acesso para os acessos que correspondem ao critério.
  • Blacklist – bloqueia o acesso para os acessos que correspondem ao critério.
  • Challenge – exibe um captcha para que o usuário prove ser humano.

 

As regras podem ser facilmente Ativadas/Desativadas, ou Editadas, através de um simples botão:

waf on/off

 

Com a adição das SmartRules o WAF da GoCache se torna a mais flexível solução deste tipo disponível no mercado nacional, resultado do nosso compromisso em entregar o melhor produto que a tecnologia atual permite construir.
Mãos à obra, pode criar suas regras e se tiver alguma dúvida nossa equipe de atendimento está pronta para te ajudar.

 

Quer testar nosso WAF sem compromisso durante 7 dias? Cadastre-se aqui, não é necessário cartão de crédito!

 

Go faster. GoCache!

Qual a diferença entre um WAF e um IPS?

Web Application Firewall x Intrusion Prevention System – Qual a diferença?

 

Introdução

Se você se já pesquisou seriamente sobre segurança, deve estar familiarizado com o termo “Intrusion Prevention System”, ou IPS. Porém ultimamente tem ganhado destaque e atenção outro tipo de proteção, o “Web Application Firewall”, ou WAF.  Mas qual a diferença entre os dois? Neste artigo faremos uma breve análise de ambos, suas limitações e a forma como se complementam.

 

O Sistema de Prevenção a Intrusão (IPS)

O IPS observa o fluxo de pacotes através da rede. Age de forma semelhante a um Sistema de Detecção de Intrusão (IDS), tentando identificar dados suspeitos nos pacotes de rede com base em um banco de dados de assinaturas, ou detectar anomalias em comparação ao que é pré-definido como tráfego “normal”. Além de sua funcionalidade IDS, um IPS pode fazer mais do que apenas gerar logs e alertas. É possível programa-lo para reagir ao que detecta. A capacidade de reagir às detecções é o que torna o IPS mais desejáveldo que o IDS.

 

Há algumas desvantagens para um IPS. Ele é projetado para bloquear certos tipos de tráfego, identificados como potencialmente perigosos. O IPS não tem a capacidade de compreender a lógica do protocolo da aplicação web. Assim, o IPS não distingue completamente se uma solicitação é normal ou malformada na camada de aplicação (camada OSI 7). Esta limitação poderia potencialmente permitir a passagem de alguns tipos de ataques sem que sejam detectados ou prevenidos, especialmente novos tipos de ataques mais sofisticados e sem assinaturas.

 

Havendo um grande número de aplicações web, tanto comerciais quanto caseiras, a tendência é que existam os mais diversos tipos de vulnerabilidades a serem exploradas por hackers. O IPS não consegue efetivamente cobrir todas essas vulnerabilidades potenciais e, provavelmente, acabará produzindo muitos falsos positivos. Falso positivos são péssimos pois fazem com que os analistas de segurança, normalmente já ocupados, fiquem ainda mais ocupados. Uma sobrecarga de falsos positivos pode atrasar a resposta a ataques reais, ou fazer com que sejam aceitos porque um analista tentou reduzir o “ruído”.

 

O IPS de Host (HIPS) é um pouco mais granular do que o IPS de rede (NIPS). O HIPS monitora a camada de aplicação (OSI Layer 7) um pouco mais próximo da lógica fornecida à aplicação web. Mas o HIPS ainda carece de alguma compreensão das linguagens de aplicações web e sua lógica. Em resposta a essas deficiências, surgiu o Firewall de Aplicação Web – WAF.

 

 

Web Application Firewall (WAF)

 

O WAF é projetado para proteger aplicações web/servidores de ataques baseados na web que um IPS não pode impedir. Assim como um IPS, o WAF pode ser baseado em rede ou host. Ele monitora o tráfego de e para os aplicativos/servidores web. Basicamente, a diferença está no nível de capacidade de análise da lógica de aplicação web na camada 7.

 

Enquanto o IPS avalia o tráfego comparando assinaturas e comportamentos anômalos, o Web Application Firewall avalia o comportamento e a lógica do que é solicitado e devolvido. O WAF protege contra ameaças de aplicações web tais como injeção de SQL, cross-site scripting, sequestro de sessão, alteração de URL ou de parâmetro e estouro de buffer. Ele faz isso da mesma maneira que um IPS faz, analisando o conteúdo de cada pacote de entrada e de saída.

 

WAFs normalmente são implantados em um proxy na frente das aplicações web, para que não vejam todo tráfego da rede. Ao monitorar o tráfego antes que ele atinja a aplicação Web, o WAF pode analisar as requisições antes de transmiti-las. Isto é o que lhe dá vantagem sobre o IPS, que é projetado para interrogar todo o tráfego de rede, sem analisar a camada de aplicação com o rigor necessário.

 

O WAF não apena detecta ataques que são conhecidos por ocorrerem em ambientes de aplicações Web, mas também detecta (e pode prevenir) novos tipos desconhecidos de ataques. Ao observar padrões inusitados ou inesperados no tráfego, ele pode alertar e/ou defender contra ataques até então desconhecidos. Por exemplo, se o WAF detecta um aplicativo retornando mais dados que o esperado, pode bloqueá-lo e alertar alguém.

 

 

Conclusão

 

Os Firewalls de Aplicação Web são um tipo especial de produto, utilizados para detectar ataques contra aplicações web com mais profundidade e critério do que os Sistemas de Prevenção a Intrusão. O WAF pode ser usado no ambiente para fornecer proteção aprimorada a aplicações/servidores Web. Usar um WAF é uma boa maneira de complementar o IPS e fornecer uma camada adicional de proteção para uma arquitetura de defesa em profundidade mais completa.

 

*Publicado originalmente no portal iMasters: http://imasters.com.br/infra/seguranca/web-application-firewall-x-intrusion-prevention-system-qual-diferenca/

HTTPS, Google Chrome e o seu site

Bem-vindo a 2017, o ano da Internet mais segura. Você ainda não utiliza SSL para que seu site seja acessado via HTTPS? É muito provável que isto mude neste ano.

HTTPS & SSL

O “https” que é exibido na barra de endereços do navegador demonstra que o site possui um certificado SSL instalado. SSL é a abreviação para Secure Sockets Layer. É um protocolo de comunicação que cria um canal criptografado entre o servidor e o navegador, para garantir o sigilo e a segurança dos dados transmitidos. É comumente utilizado para tornar mais seguros os pagamentos online e a autenticação de dados em áreas com acesso restrito. Os usuários de um website reconhecem a segurança quando visualizam o “cadeado fechado” na barra de endereço do site.

Por que usar SSL se tornou praticamente obrigatório?

Tudo começou em 2014, quando o Google anunciou que o uso de SSL seria considerado um fator importante no posicionamento de um site nas páginas de resultados de buscas (SERPs). Este foi oficialmente o início do movimento por uma internet mais segura.

Em seguida, em Setembro de 2016, o Google fez um novo anúncio, estabelecendo Janeiro de 2017 como o mês em que todo e qualquer formulário que solicite senha, ou cartão de crédito, deve obrigatoriamente utilizar HTTPS, ou será exibido como inseguro no Chrome.

HTTPS not secure

 

Por que isso é importante?

Bem, no Brasil o Chrome é “um pouco” mais utilizado do que os demais navegadores (fonte StatCounter):

chome mkt share BR

 

Ou seja, se você tem um formulário para alguma área logada em seu site e não utiliza HTTPS, 3 de cada 4 visitantes estão recebendo um aviso de “não seguro”.

E o Google irá além, conforme o anúncio de Setembro de 2016 eles pretendem exibir como “inseguro” no Chrome todos os sites que não utilizarem HTTPS em todo o site!

site sem HTTPS

 

Apesar de ainda não haverem divulgado a data para esta última mudança, melhor prevenir do que remediar, certo?

 

Como adquirir um certificado SSL?

 

Existem duas opções, o certificado tradicional e pago, ou o certificado gratuito. O certificado pago pode ser adquirido através de diferentes entidades certificadoras tradicionais. A alternativa mais econômica e simples é  o certificado gratuito da Let’s Encrypt.

A Let’s Encrypt foi fundada em Abril de 2016, justamente com o objetivo de ajudar a tornar a internet mais segura. Seu certificado gratuito pode ser obtido rapidamente e renovado automaticamente, para utilização em qualquer website. Além disso, o certificado da Let’s Encrypt não necessita de um endereço IP dedicado para sua instalação, neste caso dependendo de ter a extensão SNI habilitada no servidor web em questão.

Ainda existem algumas limitações, comparado a outras certificadores, como a não possibilidade de emissão de certificados Wildcard e nem do tipo EV (Extended Validation SSL), que mostra a barra verde completa no navegador com informações específicas da empresa.
Apesar disso, atende muito bem aos requisitos de segurança para tornar o site mais seguro e ainda impacta positivamente o SEO.
Agora você não tem mais motivos para deixar de usar o HTTPS em seu site, está esperando o quê?
,

Agora na GoCache CDN o SSL gratuito automático pode ser usado em todos os planos!

Quer usar um certificado SSL gratuito e rodar seu site em HTTPS?

 

ssl browser

O que é SSL e para que serve?

É uma tecnologia que criptografa a comunicação entre o usuário do site e o servidor onde o website está hospedado. Isso assegura a privacidade e integridade dos dados do usuário. Por este motivo seu uso é considerado obrigatório em sites de comércio eletrônico, por exemplo.

Seu site em HTTPS na GoCache

Agora todos os planos da GoCache CDN contemplam o usodo certificado da Let’s Encrypt. É um certificado gratuito, automatizado e aberto, sem nenhum custo adicional. Com isso os clientes GoCache ganham a oportunidade de economizar os custos de aquisição e manutenção de um certificado próprio. Além disso, o uso de SSL ajuda a melhorar a posição do website nos mecanismos de busca, conforme anunciado pelo Google.

Para entender como configurar no seu WordPress, por favor consulte o seguinte tutorial:

Tutorial de configuração

 

Já os usuários que não utilizam WordPress podem entrar em contato com nosso suporte – suporte@gocache.com.br – caso tenham dúvidas e teremos prazer em auxiliar com a configuração.

 

Se tiver alguma dúvida ou sugestão, por favor não hesite em falar conosco no contato@gocache.com.br .

 

Go faster. Go Cache.