Aplicativos web recebem 71 tentativas desse tipo de taque por hora, mas isso pode chegar a 1,3 mil. Considere os conselhos de segurança para impedir ataques SQL

Em médias, aplicativos web recebem 71 tentativas de ataque por injeção de comandos SQL por hora. Mas durante picos de ataque, esse volume pode atingir 1,3 mil por hora. Essa descoberta veio da fornecedora de segurança Imperva, que divulgou uma nova pesquisa sobre ataques SQL. Para tal estudo, a companhia monitorou 30 aplicativos web diferentes – todos reais, de diferentes tamanhos e utilizados por diferentes indústrias – durante nove meses. Nesse período, a empresa viu o número de ataques diários aumentar, em média, 34%.

Os ataques contra aplicativos web, infelizmente, já são muitos eficientes. Desde 2005, eles resultaram em 83% das brechas bem sucedidas relacionadas à hacking, de acordo com a Privacy Rights Clearinghouse. O motivo é simples: a maioria dos aplicativos web tem vulnerabilidades que podem ser facilmente exploradas por quem comanda os ataques.

A disponibilidade de ferramentas automáticas para testes de penetração facilita o trabalho. Só em injeção de SQL, por exemplo, o código aberto Sqlmap pode lançar cinco tipos diferentes de ataques. Popular também – e usada por LulzSec, entre outros – é o Havij, uma ferramenta automática de SQL para Windows, distribuída pela empresa de segurança iraniana ITSecTeam. As duas ferramentas podem identificar (pela digital) bancos de dados individuais, restaurar senhas e nomes de usuário, eliminar colunas e tabelas, rodar SQL e, às vezes, até executar comandos por meio do sistema operacional do servidor de banco de dados.

Com tais ferramentas em circulação, e grandes vulnerabilidades em aplicativos web, o que empresas podem fazer para se protegerem? Quando se trata de impedir ataques SQL, comece com esses conselhos:

1. Lista negra de hosts maliciosos.

Quase um quarto dos ataques SQL registrados pela Imperva, em julho de 2011, vieram de três hosts. Além disso, metade dos dez principais hosts que lançaram ataque SQL geraram até duas mil ameaças em um período entre um e sete dias, e mais de 30 hosts geraram, ao menos, 100 ataques num período de 48 horas. Tudo isso significa que os hosts mais perigosos podem ser identificados e adicionados à lista negra de acesso ao banco de dados.

2. Pool de recursos.

Negócios que compartilham inteligência em ataques SQL podem ter uma ideia melhor de quais hosts lançam os ataques. Dito isso, de acordo com a Imperva, “a velocidade de atualização da lista negra deve ser maior para ficar em dia com as novas ameaças”, porque, em média, os hosts se mantêm ativos apenas por meio dia.

3. Acesso minimizado.

Restrinja os dados que qualquer aplicativo web pode resgatar do banco de dados. Nunca permita acesso ao banco de dados em nível de administrador a aplicativos web.

4. Codifique dados.

Nunca armazene dados em formato de texto simples. Em vez disso, codifique os dados e dificulte senhas, para que caso um ataque chegue ao banco de dados, extraia o mínimo possível de informações valiosas.

5. Desconfie de usuários.

“Qualquer input é maligno”. Esse é um mantra essencial para aplicativos web, de acordo com a Microsoft. O que significa que, em um cenário ideal, desenvolvedores de aplicativos web somente permitiriam input esperados e bloqueariam todo o resto.

6. Perfil de aplicativo.

Compreenda o comportamento normal do aplicativo web, para que fique mais fácil identificar qualquer comportamento anormal, como tentativas de executar mais buscas em bancos de dados do que o normal ou utilizando inputs incomuns.

7. Padronize inputs.

Padronize input de banco de dados “para evitar tentativas de evasão”, aconselha a Imperva. Depois compare o padrão com inputs maliciosos conhecidos para identificar ataques em andamento.

8. Cuidado com automação.

Como os ataques SQL são lançados por meio de ferramentas automáticas, preste atenção aos indicadores dessa técnica. De acordo com a Imperva, “existem diversos mecanismos para detectar o uso de clientes automáticos, como políticas baseada em taxas e coerção de resposta à desafios por clientes válidos”.

As técnicas acima ajudarão a equipe de TI a bloquear ataques SQL. Elas não vão impedir absolutamente todos os ataques a aplicativos web, mas, devido à prevalência de vulnerabilidades nesses aplicativos e à habilidade dos responsáveis pelos ataques em explorar, com êxito, essas falhas, os negócios precisam de toda ajuda que conseguirem.

fonte:8 técnicas para bloquear ataques SQL

Com a chegada de cada nova versão do SQL Server, novas tecnologias são introduzidas ou ha melhorias nas ja existentes. Quando o SQL Server 2005 foi lançado, uma nova solução de alta disponibilidade denominada Mirror foi um dos grandes diferenciais em relação sua versão anterior (SQL Server 2000).

Como o Mirror Funciona:
Vamos supor que exista o servidor SRV01 com a base BSE1 na instancia ITC1, ja no servidor SRV2, existe a instancia ITC2. Voce foi designado para propor uma solução de alta disponibilidade, porem, voce não possui uma storage (Armazenamento externo), e como lhe foi dito que a diferença entre a base de contingencia e a principal deve ser minima, o log shipping pode até ser aceitavel, porem não é recomendado cria-lo para ficar rodando em um intervalo muito pequeno, como voce precisa ter alta disponibilidade de toda uma base, a replicação se torna uma solução inviavel, portanto sua melhor opção (Até o SQL Server 2008) é a utilização do Mirror.
Claro que o mirror possui sua vantagens e desvantagens, cujas quais são listadas abaixo:

Vantagens:
- Facil configuração e monitoramento.
- Base primaria e secundaria sincronizadas em tempo real.
- Não é necessario uma solução de hardware de discos externos (Storage).
- FailOver automatico com a utilização de uma instancia Witness.

Desvantagens:
- Necessario espaço em disco igual nos servidores envolvidos.
- Por ser sincrono, problemas de infra-estrutura em relação a rede podem atrapalhar a performance entre os servidores.
- FailOver de apenas uma base por mirror.
- Base secundaria fica em modo restoring não podendo nem ser acessada para consultas via SELECTs.

No SQL Server 2011 que ainda será lançado, existe uma nova solução atualmente chamada de High Avaiability Disaster Recovery AlwaysOn, ou simplismente HADRON, esta solução funciona como um mirror, porem possui algumas vantagens sobre seu concorrente.

Vantagens sobre o mirror comum:
- Escrita assincrona e com intervalo pequeno, ou seja, voce tera seus dados atualizados o mais rapido possivel em sua base secundaria, porem a performance de rede não ira impactar as ações na base primaria.
- FailOver automatico gerenciado pelo WSCS (Windows Server Cluster Service) para mais de uma base automaticamente.
- Como todo o FailOver é pelo WSCS, não é mais necessario uma instancia Witness para verificação do estado dos servidores envolvidos.
- Bases secundarias podem ser configuradas com 3 roles basicas de acesso:

1. Leitura -> Os usuarios podem se conectar porem apenas para leitura.
2. Leitura de conexão -> Não existe conexão direta na base, porem um select informando esta base, schema e tabela ira funcionar.
3. Sem leitura -> Mesmo estado do mirror comum.

Como conclusão final é possivel dizer que a solução HADRON não é realmente uma mudança extremamente impactante ou inovadora como foi o Mirror para o SQl Server 2005, mas possui conceitos e melhorias interessantes a serem considerados para sua implantação em alguns ambientes, principalmente pelo acesso de leitura na base secundaria.

Fonte: Nova classe de banco de dados emerge

Fonte: Banco de dados: processos distribuídos

Fique atento! O suporte ao SP2 do SQL Server 2005 encerrou no dia 12/01. O suporte a versão RTM do SQL Server 2008 vai encerrar em 13/04. Confira a tabela abaixo ou acesse o blog oficial da Microsoft  aqui.