sexta-feira, 17 de julho de 2015

Evitando ataques DDoS


Explicando o DDoS
Os ataques DDoS são ataques de negação de serviço (DoS) só que ao invés de provir de uma única máquina, são iniciados de várias, a fim de interromper as operações normais. DoS tradicional força um excesso de rede, servidor, ou recursos de aplicativos para desabilitar o acesso ao serviço de destino. Esses ataques amplificam os efeitos de ataques DOs, usando milhares de máquinas para lançar seus ataques. As duas classes principais de ataques DDoS, são ataques de rede e aplicação.

Os Quatro Passos para Mitigar o Ataque DDoS
Existem diversas medidas que empresas podem tomar para mitigar os riscos de sofrerem um ataque desse tipo. Vamos ressaltar, as 4 principais medidas que podem ser tomadas:

1 – Super provisionar banda para absorver os picos de DDoS
Esta é uma das medidas mais comuns para aliviar ataques DDoS, muito utilizado por e-commerces em época de Black Friday, mas também é provavelmente a mais cara, especialmente porque os atuais ataques DDoS podem ser dez ou até cem vezes maior do que os níveis de tráfego padrão para aquela aplicação. Uma alternativa para o excesso de provisionamento de banda de Internet, é a utilização de um serviço de segurança escalável sob demanda para absorver e filtrar o tráfego DDoS. Serviços de proteção de DDoS são projetados para parar maciços ataques DDoS, sem sobrecarregar as conexões de Internet das empresas, fazendo com que o usuário comum não seja afetado com latência nem indisponibilidade da aplicação.

2 – Monitoramento da Aplicação e do Tráfego
A melhor maneira de detectar quando você está sob um ataque, é através de um aplicativo de monitoramento de tráfego de rede e aplicação. Por meio dessas ferramentas, você poderá determinar se o mau desempenho da sua aplicação é devido a falhas de provedores de serviço ou um ataque malicioso. O monitoramento do tráfego, também permite que as organizações diferenciem o tráfego legítimo de tráfego provindo de fontes mal intencionadas. Idealmente, os administradores do departamento de segurança devem rever os níveis de tráfego, o desempenho da aplicação, o comportamento anômalo, violações do protocolo e códigos de erro do servidor Web. Como os ataques DDoS são quase sempre executados por botnets, ferramentas de aplicação devem ser capazes de diferenciar o tráfego bot  do usuário padrão. Esse monitoramento permite que a equipe de TI e segurança tenham um panorama e visibilidade do que está ocorrendo em tempo real podendo assim, tomar decisões mais precisas.

3 – Detecção de Usuários Mal Intencionado
Existem dois métodos principais para identificar tráfego de ataque DDoS: identificar usuários mal intencionados e identificar solicitações maliciosas. Para ataques DDoS em aplicações, muitas vezes, identificar usuários mal intencionados pode ser a forma mais eficaz para mitigar os ataques.

Reconhecer fontes de ataque conhecidos, tais como endereços IP maliciosos que estão atacando ativamente outros sites, proxies anônimos e redes TOR. Fontes de ataque conhecidas, são responsáveis por uma grande percentagem de todos os ataques DDoS. Como essas fontes maliciosas estão em constante mudança, é muito importante que as empresas mantenhas as suas blacklists sempre atualizadas para diminuir o risco e aumentar a eficiência da sua proteção.

Identificar os agentes bot conhecidos. Ataques de negação de serviço são em sua maioria realizados por clientes automatizados. Muitos destes agents ou bots tem características únicas que os diferenciam dos agentes comuns. Ferramentas que reconhecem agentes bot, podem facilitar muito na hora da identificação e de bloquear os ataques de múltiplas fontes de DoS.

Executar testes de validação para determinar se o visitante da Web é um ser humano ou um bot é uma boa saída para se proteger de ataques. Por exemplo, se o navegador do visitante aceita cookies e entende os redirecionamentos de HTTP é bem provável que esse visitante em questão é um ser humano e não um bot script.

Criar regras de bloqueio através de geolocalização. Para alguns ataques DDoS, a maioria do tráfego de ataque pode ser originário de um país ou região específica do mundo. Bloqueio de solicitações de países indesejáveis pode ser uma maneira simples para parar a grande maioria do tráfego de ataque DDoS.

4 – Detecção de Requests Maliciosos
Como os ataques DDoS em aplicação imitam tráfego regular aplicação Web, esses podem ser difíceis de detectar através de técnicas típicas para DDoS de rede. No entanto, usando uma combinação de controles no nível da aplicação e detecção de anomalias, as organizações podem identificar e interromper o tráfego malicioso. As medidas incluem:

Detectar um número excessivo de requests de uma única sessão ou usuário – fontes ataques automatizados, quase sempre solicitam páginas Web mais rapidamente do que usuários válidos fugindo assim do padrão de navegação.

Previna-se contra redes e aplicações conhecidas por realizarem ataques DDoS (Blacklist) – Muitos tipos de ataques DDoS confiam em técnicas de rede simples, como fragmentação de pacotes, spoofing, ou a não realização de handshakes de TCP. Ataques mais avançados, tipicamente em nível de aplicativo, tentam sobrecarregar os recursos do servidor. Estes ataques podem ser detectados através da atividades incomuns de usuários e assinaturas de ataques conhecidos.

Distinguir os atributos e as consequências de um pedido malicioso. Alguns ataques DDoS podem ser detectados por meio de padrões de ataque conhecidos ou assinaturas. Além disso, as solicitações da Web para ataques DDoS na sua grande maioria não estão em conformidade com as normas do protocolo HTTP. O ataque Slowloris, por exemplo, inclui cabeçalhos HTTP redundantes.

Ao longo dos últimos anos, a industrialização de ataques e a ascensão do hacktivismo resultaram em uma explosão de ataques poderosos e destrutivos de DDoS. Usando toolkits simples, os criminosos podem construir rapidamente botnets de milhares ou até milhões de computadores. Usuários mal intencionados podem alugar estes botnets para desencadear ataques DDoS destrutivos sobre praticamente qualquer vítima. Além disso, os hacktivistas voltaram-se para as redes sociais e ferramentas de ataque como LOIC e Refref para desencadear ataques DDoS poderosos.

As técnicas de mitigação apresentados, são apenas algumas das medidas que as organizações podem usar para combater ataques de DDoS. Devido à variedade de vetores de DDoS, ataques maciços de rede, como SYN floods, muitas empresas começaram a terceirizar sua segurança DDoS aos prestadores de serviços de segurança dedicados e especializados nessa questão.



Fonte:http://goo.gl/wAT3Bq

HTTP Security Headers: Guide




O protocolo HTTP possui diversos Headers que podem aumentar consideravelmente a segurança de sua aplicação web e esses Headers podem ser muito úteis para prevenir alguns tipos de ataques.

A ideia deste artigo é mostrar todas as opções de Header HTTP que você pode utilizar para aumentar a segurança de sua aplicação e como você pode configurá-lo.

Confira abaixo:

Access-Control-Allow-Origin

Hoje é normal encontrarmos empresas que disponibilizam seus serviços através de APIs e que justificam o grande número de requisições com a origem de diversas fontes, mas diversas empresas não fornecem esse serviço e podem usar um Header HTTP chamado Access-Control-Allow-Origin que é parte integrante do Cross-Origin Resource Sharing (CORS). Este cabeçalho permite você definir quais endereços podem acessar os recursos do seu website.

Um exemplo de utilização seria:

Access-Control-Allow-Origin: http://labs.siteblindado.com
Onde seria permitido apenas o próprio site acessar os recursos. Você pode utilizar o Wildcard (*), onde permite que todos os sites acessem as informações, mas não é recomendado.

Maiores informações:


Content-Security-Policy

O Content Security Policy é um cabeçalho HTTP que fornece uma whitelist de recursos confiáveis no qual o navegador poderá confiar. Um recurso pode ser um script, CSS, imagem ou outro tipo de arquivo que poderá ser indicado. Isso significa que mesmo se um atacante conseguir injetar um código XSS no seu site, o CSP poderá impedir a sua execução.

Você poderá utilizar o Content Security Policy no Header como mostrado abaixo:

Content-Security-Policy: policy

Sendo que o texto “policy” deverá seguir algumas diretivas. Veja um exemplo:

ContentSecurityPolicy:
script
src 'self' scripts.seusite.com.br;
media
src 'none';
img
src *;
default
src 'self' http://*.seusite.com.br

Nesse exemplo, os scripts podem ser carregados apenas do servidor atual e da URL scripts.seusite.com.br. Áudio e vídeo não podem ser carregados de nenhum local, imagens podem ser carregadas de qualquer host e qualquer outro recurso pode ser carregado apenas do servidor atual ou de todos os subdomínios em seusite.com.br.

O único problema atual do CSP é que a interpretação é diferente em alguns navegadores e por isso você terá que fazer um tratamento de qual Header enviar, como no caso do Safari, que você precisará usar o modelo abaixo.

X-WebKit-CSP: policy

Mais informações:


X-Content-Type-Options

Este cabeçalho permite proteger sua aplicação contra um ataque específico chamado MIME-Type confusion ou também conhecido como MIME sniffing.

A utilização desse cabeçalho é muito simples e necessita apenas adicionar a opção “nosniff” no cabeçalho, como mostrado abaixo:

X-Content-Type-Options: nosniff


Strict-Transport-Security

HTTP Strict Transport Security (HSTS) traz diversas melhorias para o SSL, entre elas, forçar a utilização do HTTPS, impedindo que sites sejam acessados usando o protocolo HTTP ou que parte do código de um site que está usando HTTPS seja executada em servidores usando o HTTP.

Um exemplo de configuração no Apache onde coloca o website na lista STS por um ano e incluiria os subdomínios seria:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Mais informações:


X-Frame-Options

O principal objetivo do X-Frame-Options é proteger contra os ataques de Clickjacking. Este cabeçalho permite que o proprietário do site decida quais sites estão autorizados a incluir conteúdo do seu site em outros locais.

A melhor opção é configurar como “SAMEORIGIN” que permite apenas os recursos que são parte da mesma origem acessar. Você também pode configurar como "DENY", que nega qualquer recurso (local ou remoto) de tentar incluir os recursos.

Um exemplo de utilização seria:

X-Frame-Options: SAMEORIGIN

O X-Frame-Options será substituído pela diretiva Frame-Options no Content Security Policy version 1.1 que está sendo desenvolvida.

Mais informações:


X-XSS-Protection

Este cabeçalho pode ser utilizado para configurar uma proteção no navegador contra ataques XSS Reflected. Atualmente, apenas os navegadores Internet Explorer, Google Chrome e Safari (WebKit) o suportam.

Exemplo de Header:
X-XSS-Protection: 1; mode=block

Sendo que os parâmetros “1; mode=block” habilitam a proteção contra XSS e instruem o navegador a bloquear scripts que sejam inseridos pelos usuários.


Public-Key-Pins

A Public Key Pinning Extension for HTTP (HPKP) é um recurso que informa o navegador para associar uma chave pública de criptografia específica com um determinado servidor de web para prevenir ataques MiTM que utilizem certificados falsos.

O HPKP é baseado em uma técnica conhecida como Trust on First Use (TOFU). No primeiro acesso ao servidor web, informa o cliente através de um cabeçalho HTTP especial que as chaves públicas pertencem a ele, o cliente armazena esta informação por um determinado período de tempo. Quando o cliente visita o servidor novamente, ele espera um certificado que contém uma chave pública cuja impressão digital já é conhecido via HPKP. Se o servidor fornece uma chave pública desconhecida, o cliente irá apresentar um alerta para o usuário.

Um exemplo de configuração seria:

Public-Key-Pins: pin-sha256="<sha256>"; pin-sha256="<sha256>"; max-age= 5184000; includeSubDomains

Neste exemplo o primeiro pin, pin-sha256="<sha256>", faz o pin da chave pública utilizada no servidor de produção, o segundo faz o pin da chave backup. O max-age diz que o cliente deve armazenar a informação por dois meses, um tempo razoável especificado pelo IETF RFC e por último a opção includeSubdomains diz que o key pinning é válido para todos os subdomínios.

Mais informações:


Além desses headers, muitas aplicações definem um header customizado com um token para proteção contra o ataque de Cross-Site Request Forgery (CSRF), como esse tipo de token não segue um padrão, cada aplicação poderá definir o seu.

Essas opções mostradas anteriormente não podem ser consideradas como uma solução definitiva para deixar uma aplicação web segura, porém utilizando ela em conjunto com outras contramedidas, dependendo da sua necessidade, poderá aumentar consideravelmente a sua segurança online.

Fonte:http://goo.gl/qVN12h

Strategic Security – Linux For Infosec Pros


 lista de vídeos e material de estudos sobre segurança para servidores linux.
http://goo.gl/GE6XRS

quarta-feira, 1 de julho de 2015

Universidade Stanford tem curso online e gratuito sobre criptografia

A Universidade Stanford traz um curso indispensável para quem quer entender sobre proteção de informações em sistemas de computador. O curso “Criptografia I”, oferecido por meio da plataforma de ensino online Coursera, é totalmente gratuito e legendado em português.

Para quem ainda não conhece, o serviço conta com 12 milhões de usuários no mundo e oferece gratuitamente mais de mil cursos de instituições renomadas do mundo todo.


O curso explica o funcionamento interno de primitivas criptografias e como usá-los corretamente. Os alunos irão aprender a raciocinar sobre a segurança das construções criptográficas e como aplicar esse conhecimento no mundo real. O curso inclui trabalhos de casa por escrito e laboratórios de programação. Clique aqui e comece!

Fonte:https://goo.gl/NYBtQ8