SISTEMAS DE LOG, TRATAMENTO DE ATAQUES E ERROS PROF.: PAULO RICARDO LISBOA DE ALMEIDA

Transcrição

1 SISTEMAS DE LOG, TRATAMENTO DE ATAQUES E ERROS PROF.: PAULO RICARDO LISBOA DE ALMEIDA

2 LIDANDO COM ATAQUES A aplicação está sendo atacada E agora?

3 LIDANDO COM ATAQUES A aplicação está sendo atacada E agora? Corra para as montanhas!

4 LIDANDO COM EXCEÇÕES (ERROS) É impossível criar uma aplicação livre de erros Pelo menos quando consideramos aplicações de grande porte Os erros podem ser apresentados aos usuários para que eles saibam que problema aconteceu ao processar uma requisição enviada Ex.: Ocorreu um erro: a idade informada não pode ser menor que 12

5 LIDANDO COM EXCEÇÕES (ERROS) Como uma mensagem de erro pode ser considerada uma falha de segurança?

6 LIDANDO COM EXCEÇÕES (ERROS) Mensagens com muita informação podem ser de grande ajuda ao atacantes Nunca deve-se retornar uma mensagem de erro gerada internamente ou qualquer outra informação de debug ao usuário Ex.: Ocorreu um erro. Não foi possível conectar ao banco de dados meubancodb.

7 LIDANDO COM EXCEÇÕES (ERROS) Geralmente as mensagens verbosas são originadas de blocos try catch incorretos Exemplo incorreto try{ //faz o processamento }catch(exception e){ System.out.println(e.getMessage()); }

8 LIDANDO COM EXCEÇÕES (ERROS) Geralmente as mensagens verbosas são originadas de blocos try catch incorretos Exemplo de implementação correta try{ //faz o processamento }catch(datanascimentoinvalida dtninv){ System.out.println("A data de nascimento informada não é válida"); }catch(exception e){ System.out.println("Ocorreu uma falha."); }

9 LIDANDO COM EXCEÇÕES (ERROS) Configurar o servidor para tratar exceções não tratadas de forma não informativa Ex.: Ao ocorrer um erro não tratado ir para a página de erros, que simplesmente diz que ocorreu uma falha Mas e as informações sobre o erro?

10 LIDANDO COM EXCEÇÕES (ERROS) Configurar o servidor para tratar exceções não tratadas de forma não informativa Ex.: Ao ocorrer um erro não tratado ir para a página de erros, que simplesmente diz que ocorreu uma falha Mas e as informações sobre o erro? Deve-se utilizar uma ferramenta de log que armazene todas essas informações de maneira detalhada internamente a aplicação, para ser consultada posteriormente

11 LOGS DE AUDITORIA Arquivos valiosos para investigação de intrusões ou de crashes da aplicação Quando foi o ocorrido, quais vulnerabilidades foram exploradas, quais ações foram tomadas... Algumas informações que devem ser armazenadas quanto a segurança

12 LOGS DE AUDITORIA Arquivos valiosos para investigação de intrusões ou de crashes da aplicação Quando foi o ocorrido, quais vulnerabilidades foram exploradas, quais ações foram tomadas... Algumas informações que devem ser armazenadas quanto a segurança Eventos relacionados com as funcionalidades de autenticação Logins, falhas de Logins, mudanças de senhas,... Transações chave Pagamentos de cartão de crédito, remoção de dados,... Qualquer transação que contenha strings conhecidas de ataques Informações sobre o atacante como IP, MAC, conta de usuário utilizada (se o usuário está autenticado), etc.

13 LOGS DE AUDITORIA Logs devem ser altamente protegidos de qualquer acesso indevido Logs são uma mina de outro quando acessados por craackers Possuem todo tipo de informação como parâmetros de requests e hash de seções Gravar em uma área do sistema que seja inacessível de maneira online (no caso de sistemas web)

14 LOGS DE AUDITORIA

15 ALERTANDO ADMINISTRADORES Logs servem para análise de dados históricos Alarmes são implementados para reação rápida a ataques que estão acontecendo Ex.: Para que os administradores possam bloquear o ip ou a conta que está sendo utilizada para a tentativa de invasão Um sistema de alarmes deve ser balanceado para alertar o máximo possível de ataques gerando um número de falsos alarmes aceitável

16 ALERTANDO ADMINISTRADORES Algumas anomalias que podem servir de alerta Uso do sistema, como um grande número de requisições vindas de um mesmo IP ou usuário Anomalias relacionadas ao negócio Ex.: o cliente de um banco fazendo grandes transferências Requisições contendo padrões de ataques conhecidos Requisições com dados de campos submetidos modificados

17 ALGUNS POSSÍVEIS TESTES

18 ALGUNS POSSÍVEIS TESTES Verificar o sistema de envio de mensagens de erro Verificar se erros de entrada do usuário são exibidos corretamente Verificar se erros do sistema são exibidos de maneira menos informativa possíveis Exemplos: O usuário digita uma idade inválida; O campo idade deve ser preenchido com um valor maior que 18 O sistema encontra uma falha ao conectar a um webservice: O sistema encontrou um erro

19 ALGUNS POSSÍVEIS TESTES Logs Verificar se todos os logs necessários estão sendo gravados corretamente Verificar se as informações gravadas nos logs são as especificadas, e se elas estão sendo gravadas corretamente Verificar se transações chave são logadas Enviar strings potencialmente maliciosas a aplicação e verificar se elas são logadas Verificar se os arquivos de log são inacessíveis para pessoas não autorizadas

20 ALGUNS POSSÍVEIS TESTES Sistemas de alerta Verificar se strings potencialmente maliciosas geram alertas Verificar se um possível ataque de força bruta gera um alerta Verificar se as demais anomalias (de acordo com as regras de negócio) geram alertas Verificar se o número de falso positivos é aceitável