Ola pessoal,
No último post (Bloqueando ataques com o IPS/IDS do NSX-T (vbrain.com.br) ), falei um pouco sobre como bloquear alguns tipos de ataques com a feature de IDS/IPS do NSX-T.
Hoje, farei um post falando um pouco da feature de WAF (Web Application Firewall) presente no AVI – NSX Advanced Load Balancer) da VMware, o intuito aqui é mostrar como é simples bloquear algumas das vulnerabilidades mais conhecidas em ambientes WEB pelo AVI, então, não espere aqui nenhum ataque avançado ou configuração manual de políticas, o que queremos concluir aqui é que com a configuração praticamente automatica do AVI ja é possível bloquear dezenas de vulnerábilidades.
O NSX Advanced Load Balancer, formalmente conhecido como Avi, é uma solução da VMware para balanceamento de carga de aplicações, sejam elas Web ou não, e como costumeiramente encontrado em grandes ferramentas de Load Balancer, o AVI também possui feature de WAF, o qual pode ser utilizada para bloquear os mais diversos tipos de ataques e vulnerabilidades encontradas em aplicações Web.
Nos próximos posts falaremos mais sobre o AVI, sua arquitetura e seus principais benefícios além de mais testes da feature de WAF
fonte : www.avinetworks.com.br
Como aplicação Web vulnerável, utilizarei novamente o DVWA (DamnVulnerable Web App), DamnVulnerable Web Application é uma ferramenta desenvolvida em PHP/MySQL que pode ser facilmente instalada em uma maquina virtual, a maioria das vulnerabilidades são classificadas como Top 10 vulnerabilidades encontradas pelo OWASP, essa ferramenta possui diversos tipos de vulnerabilidades Web e é muito utilizada para aprendizado em cursos de pentest, e também para testes de ferramentas do tipo IPS, WAF, etc.
No topo das vulnerabilidades classificadas pelo OWASP, estão as vulnerabilidades por injeção SQL, de acordo com o próprio OWASP, ataques de SQL Injection consistem na injeção de query SQL por imput de dados de um client à uma aplicação, um SQL Injection Exploit pode ler dados sensíveis de uma database, modificar dados (Insert/Update/Delete), executar operações em uma base de dados como administrador, como realizar o shutdown do Banco entre outras vulnerabilidades.
Fonte: SQL Injection | OWASP
Mãos à obra, utilizarei a mesma imagem DVWA utilizada no post sobre IDS/IPS.
A primeira ação que faremos, é configurar o nível de segurança do DVWA como low profile:
Logo após, faremos o primeiro teste de SQL Injection, no próprio menu do DVWA existe uma opção para tal, conforme o teste que fizemos no post de IDS/IPS, iremos inserir no campo os valores “2 or 2 = 2” e então clicar em Submit, veja que a vulnerabilidade foi explorada e dados sensíveis são informados na tela.
Para esse teste, eu criei um Virtual Server simples no AVI, no próximo post sobre a estrutura do AVI falaremos mais sobre isso, neste momento, existe apenas uma VS que encaminha todas as requisições para um único servidor DVWA, ou seja, não estamos testando aqui balanceamento de carga, o intuito é apenas testes com WAF.
Dentro das configurações deste Virtual Server, em WAF Policy, utilizaremos uma policy que eu havia criado previamente, essa policy está configurada apenas como Detection por enquanto, ou seja, ataques e exploração de vulnerabilidades neste momento serão apenas gravadas nos logs.
E então, configuramos essa policy no Virtual Server do DVWA
Veja que um símbolo de escudo é atrelado à esse VS informando que agora temos políticas de WAF atreladas ao VS:
Veja que na aba “WAF” do virtual server, já é possível validar que um ataque por injeção SQL foi utilizado, informando aqui a assinatura que validou esse ataque, veja também que na parte de Tags, podemos ver algumas informações interessantes como “OWASP_TOP_10” , ou seja, essa vulnerabilidade é uma das Top 10 classificadas pelo OWASP.
Na aba de Logs também é possível verificar mais informações sobre o ataque, veja que nada foi bloqueado, apenas verificado que existe aqui uma vulnerabilidade sendo explorada (FLAGGED).
Agora, voltando nas configurações da política de WAF, vamos alterar de Detection para Enforcement, ou seja, agora queremos que todas as assinaturas habilitadas sejam bloqueadas quando a exploração das vulnerabilidades forem detectadas:
Na aba assinaturas, eu validei que as assinaturas referentes à SQL Injection (Core Rule Set CRS_942) estão habilitadas.
Agora, retornando ao DVWA, faremos novamente o mesmo testes de SQL Injection:
Veja que agora, quando clicamos em “Submit”, recebemos uma resposta com erro 403 vindo do AVI:
Voltando a aba de Logs, veja que temos agora a informação de que essa conexão foi rejeitada (REJECTED):
É isso pessoal, o intuito aqui foi mostrar de forma simples como é fácil bloquear uma das vulnerabilidades classificadas como Top 10 pelo OWASP no AVI.
Até a próxima pessoal.