Qual é a necessidade do WAF?
Por que precisamos proteger os aplicativos da web contra ataques e por que os aplicativos da web são alvo de tantos ataques?
O primeiro motivo é o fato de estarmos utilizando tecnologias conhecidas para desenvolver aplicações web. Muitas plataformas de desenvolvimento web conhecidas, como PHP e ASP, têm falhas de segurança conhecidas, e os invasores usam esses pontos fracos para explorar o aplicativo. O mesmo acontece com os mecanismos de banco de dados que esses aplicativos usam no backend.
A segunda razão é a ampla superfície dos ataques. Os principais usuários de aplicativos da web estão se conectando a partir da Internet. Qualquer pessoa pode tentar usar ou atacar seu aplicativo da Internet.
Quase todos esses ataques podem ser categorizados em alguns grupos, ataques de injeção de SQL, cross-site scripting, remote file inclusion, missing HTTP headers, bots, crawlers e scanners navegando na Internet tentando encontrar aplicativos web fracos, solicitações excessivas e muito mais.
Todos esses ataques podem ser evitados. Uma maneira é prevenir no nível do código, o que é bastante desafiador e é responsabilidade do desenvolvedor fazer isso. Além disso, requer alta manutenção, aplicação de patches e monitoramento em várias camadas do aplicativo. A outra maneira, muito mais simples, é comprar o web application firewall firewalls (WAFs) e implantá-los na frente do servidor da web para bloquear ataques comuns. Isso fornece proteção centralizada para seu aplicativo da web contra exploits e vulnerabilidades comuns.
Um web application firewall (WAF) é uma forma específica de sistema de segurança de rede que filtra, monitora e bloqueia o tráfego HTTP e HTTPs de entrada e saída de e para um serviço da web, com base em uma política configurada, geralmente com conjuntos de regras predefinidos para escolher.
O que é o Azure Web Application Firewall?
O Microsoft Azure também tem um serviço WAF que fornece proteção centralizada de seus aplicativos da Web contra explorações e vulnerabilidades comuns. O Azure Application Firewall é um dos recursos do Azure Application Gateway (balanceador de carga da camada 7) e Azure Front Door, seu objetivo principal é proteger um aplicativo da Web contra ataques comuns, como SQL injections, cross-site scripting e outros. Também está seguindo o conjunto de regras principais do Open Web Application Security Project (OWASP) . O serviço WAF do Azure oferece a você a seleção de algumas ou todas as regras do conjunto de regras básicas OWASP.
O Azure Application Gateway tem um IP público, ou frontend, e os usuários do seu aplicativo usarão esse endereço IP para se conectar ao seu Application gateway. O Application gateway receberá o tráfego de entrada e, com base em algumas regras, redirecionará o tráfego para o backend apropriado no pool de backend. Você pode ter app services, virtual machine scale sets ou até mesmo outros endereços IP nos pools de backend.
Benefícios
- Ele pode ser configurado, implantado e gerenciado por meio do Portal do Azure, APIs REST, PowerShell e CLI.
- Funciona com todos os tipos de aplicativos da web (ASP.NET, PHP, JSP, etc.)
- Nenhuma mudança de código é necessária na camada de aplicativo.
- Registros de monitoramento de proteção em tempo real.
- Personalização de regras de acordo com os requisitos do aplicativo.
Você encontra aqui todas as demais funcionalidades do serviço.
Modos WAF
- Detection: monitora e registra todos os alertas de ameaças em um arquivo de log se executarmos o WAF no modo “Detecção”. Nesse modo, nenhuma solicitação de entrada será bloqueada e será registrada em logs WAF.
- Prevention: Detecta e bloqueia as solicitações de entrada contra ataques, e o invasor simplesmente recebe 403 Erro Proibido no modo “Prevenção”. Este modo também registra tais ataques nos logs WAF.
Para qualquer aplicação, é recomendado começar com o modo de detecção de WAF. Monitore inicialmente os logs WAF para as regras selecionadas, analise os logs e revisite o conjunto de regras para decidir se o conjunto de regras selecionado é uma combinação correta para o tráfego a ser bloqueado no modo de prevenção.
Preços WAF
As cobranças do firewall do aplicativo da web do Azure são baseadas na versão que escolhemos durante a implantação:
- Firewall de aplicativo da Web: aqui você terá o preço por hora de um Gateway de Aplicativo do Azure com um tamanho médio, pelo menos. Além disso, o preço é baseado na quantidade de dados que o WAF irá processar.
- Web Application Firewall V2: Aqui você terá o preço por hora e um custo baseado na quantidade de “Unidades de capacidade”. Você pode aprender mais sobre a unidade de capacidade aqui
Aqui está a comparação entre WAF e WAF V2, em termos de recursos. Você também pode fazer sua própria estimativa de preço aqui.
Passo a Passo
Neste artigo usaremos o aplicativo Damn Vulnerable Web App (DVWA) que será publicado em uma máquina virtual Windows, para testarmos o acesso da aplicação vulnerável com WAF, e como o WAF irá tratar essas vulnerabilidades da aplicação.
Publicando a aplicação DVWA no Windows
O Damn Vulnerable Web App (DVWA) é um aplicativo da web PHP/MySQL que é extremamente vulnerável. Seus principais objetivos são ajudar os profissionais de segurança a testar suas habilidades e ferramentas em um ambiente legal, ajudar os desenvolvedores da web a entender melhor os processos de proteção de aplicativos da web e auxiliar professores/alunos a ensinar/aprender a segurança de aplicativos da web em um ambiente de sala de aula .
A aplicação está disponível para download no link abaixo.
01 – Baixe o DVWA, clicando em DOWNLOAD.
Baixar e instalar o XAMPP
XAMPP é uma distribuição Apache muito fácil de instalar para Linux, Solaris, Windows e Mac OS X. O pacote inclui o servidor web Apache, MySQL, PHP, Perl, um servidor FTP e phpMyAdmin.
02 – Acesse o link abaixo para baixar o XAMPP.
https://www.apachefriends.org/index.html
03 – No site XAMPP clique em Download.
04 – Na tela de Download selecione a versão do seu sistema operacional e clique em Download.
05 – Após realizar o download do XAMPP, clique em xampp-windows-x64-7.3.30-0-VC15-installer.exe para iniciar o processo de instalação.
06 – No vídeo abaixo mostro como instalar o XAMPP.
07 – Inicie os serviços Apache e MySQL.
08 – Após instalar o XAMPP e iniciar o Apache e MySQL, navegue até o caminho C:\xampp\htdocs e delete todo o conteúdo da pasta.
09 – No caminho C:\xampp\htdocs crie uma pasta chamada dvwa e cole o conteúdo do arquivo DVWA que fizemos o download.
10 – Dentro da pasta dvwa no seguinte caminho C:\xampp\htdocs\dvwa, entre na pasta config.
11 – Dentro da pasta config, clique em View e selecione File name extensions.
12 – Renomeei o arquivo config.inc.php.dist para config.inc.php, na tela de confirmação clique em Yes.
13 – Abra o arquivo config.inc.php, para a opção $_DVWA[ ‘db_password’ ] = ‘p@ssw0rd’ deixe esse valor vazio, em altere $_DVWA[ ‘db_user’ ] = ‘dvwa’ altere o valor para root, em seguida salve o arquivo.
14 – Abra um navegado e digite o seguinte caminho para acessar a aplicação localhost/dvwa
15 – Nosso próximo passo será altera o PHP function allow_url_include que está como Disabled, no XAMPP Control em Apache clique em Config e selecione PHP (php.ini).
16 – Pressione Control + F e digite url_include em seguida clique em Find Next.
17 – Altere o valor allow_url_include=Off para allow_url_include=On, em seguida clique em Save.
18 – No Apache clique em Stop e Start.
19 – Atualize a página de setup da aplicação, e como podemos observar o status do PHP function allow_url_include foi alterado para Enabled.
20 – Na tela da aplicação dvwa, role a barra de rolagem até o fim da página e clique em Create/Reset Database.
21 – Após clicar em Create/Reset Database o banco de dados será criado e automaticamente seremos redirecionados para tela de login.
22 – Na tela de login digite o usuário admin e a senha password, em seguida clique em Login.
Usuário: admin
Senha: password
Implantar o Web Application Firewall (WAF)
23 – Faça login no portal do Azure.
24 – No portal do Azure pesquise por Application gateways.
25 – Na tela do Application Gateway clique em + Create.
26 – Na tela Create application gateway na opção Basics, selecione a assinatura e grupo de recursos.
Em Instance details, para a opção Application gateway name digite um nome para o recurso, em Region selecione a região de criação do recurso, em Tier podemos selecionar tanto WAF e WAF V2, selecione WAF V2, para a opção Enabled autoscaling selecione No, em Firewall status deixe selecionado Enabled, em Fariwall mode vamos selecionar Prevention para bloquear todas as solicitações maliciosas, para a opção Avaibility zone selecione None e para a opção HTTP2 vamos deixar selecionado Disabled.
OBSERVAÇÃO: O WAF V2 da suporte ao autoscaling e WAF não tem suporte.
Para o Azure se comunicar entre os recursos que você cria, ele precisa de uma rede virtual. Você pode criar uma nova rede virtual ou usar uma existente, como já tenho uma vnet criada vamos selecionar essa vnet e criar uma subnet para o Application gateway. em Virtual network selecione a vnet que deseja, em Subnet caso já tenha criado selecione a subnet desejada, clique em Manage subnet configuration.
A tela Subnet será aberta, clique em + Subnet, a tela Add subnet será exibida digite um nome para a subnet em Subnet address range digite o range de ips para a subnet, deixe as demais configurações como padrão e clique em Save.
Ainda na tela de criação da subnet clique em Create application gateway para retornar a tela de criação do application gateway.
De volta a tela Create application gateway em virtual network, selecione a subnet que criamos subnet-application_gateway, em seguida clique em Netx: Frontends.
27 – Na tela Frontends podemos selecionar os tipos Public, Private e Both, vamos selecionar Public em seguida clique em Add new, a tela Add a public IP será aberta, digite um nome para o recurso e clique em OK, em seguida clique em Next: Backends.
OBSERVAÇÃO: Não podemos utilizar a opção Private ou Both com WAF 2.
28 – Na tela Backends clique em Add a backend pool, a tela Add a backend pool será aberta digite um nome, em Target type vamos selecionar Virtual machine em Target selecione a máquina virtual que deseja adicionar, em seguida clique em Add.
OBSERVAÇÃO: Em backend podemos adicionar IP addres or FQDN, Virtual machine, VMSS e App Services.
Em seguida clique em Next: Configuration.
29 – Na tela Configuration clique em + Add a routing rule.
30 – Na tela Add a routing rule, em Rule name digite um nome para regra, em Lister name digite um nome, para a opção Frontend IP selecione o Public, em Protocol podemos selecione HTTP ou HTTPS, se você selecionar HTTPS, insira o número da porta, escolha uma opção de certificado “Upload a certificate” ou “Choose a certificate from Key Vault”, se você selecionar Upload a certificate, selecione o arquivo PFX certificate de sua máquina local e também insira o nome do certificado e senha.
Nesse artigo vamos utilizar o protocolo HTTP, selecione o protocolo HTTP e a porta 80 em Additional settings mais deixar selecionado a opção Basic, marcando a opção Error page url com yes podemos personalizar as mensagens de erro Bag gateway – 502 e Forbiddend – 403 vamos deixar selecionado o No, em seguida clique em Backend targets.
Observação: Se você estiver hospedando um único site por trás desse gateway de aplicativo, escolha um ouvinte básico. Se você estiver configurando mais de um aplicativo da web ou vários subdomínios do mesmo domínio pai, escolha um ouvinte de vários sites
Habilitar o Diagnostics Settings do Web Application Firewall
35 – No portal do Azure pesquise por Application gateways.
Web Application Firewall policies
A associação de uma política do WAF (Firewall de Aplicativo Web) com ouvintes permite que vários sites por trás de um único WAF sejam protegidos por políticas diferentes. Por exemplo, se houver cinco sites por trás de seu WAF, você poderá ter cinco políticas do WAF separadas (uma para cada ouvinte) para personalizar as exclusões, as regras personalizadas e os conjuntos de regras gerenciadas para um site sem afetar os outros quatro. Se você quiser que uma única política se aplique a todos os sites, basta associar a política ao Gateway de Aplicativo, em vez de aos ouvintes individuais, para que ela se aplique globalmente. As políticas também podem ser aplicadas a uma regra de roteamento com base em caminho.
41 – No portal pesquise por Web Application Firewall policies (WAF).
42 – Na tela Web Application Firewall policies (WAF) clique em Create.
43 – Na tela Create a WAF policy, em Policy for selecione Regional WAF (Application Gateway), selecione a subscription e Resource group, em Instance details selecione um nome para a policy, em location selecione a região onde o recurso será criado, deixe a opção Policy state habilitado, em Policy mode selecione Prevention em seguida clique em Next: Managed rules.
Ao criar uma política de WAF, por padrão, ela fica em modo de Detecção. No modo de Detecção, o WAF não bloqueia nenhuma solicitação. Em vez disso, as regras de WAF correspondentes são registradas nos logs do WAF. Para ver o WAF na prática, altere as configurações de modo para Prevenção. No modo Prevenção, as regras de correspondência definidas no conjunto de regras do CRS que você selecionou são bloqueadas e/ou registradas nos logs do WAF.
44 – Para a opção Managed rules, em Managed rule set podemos escolher entre as opções OWASP_.2 (preview), OWASP_3.1, OWASP_3.0, OWASP_2.2.9 e Microsoft_BotManageRuleSet_0.1, vamos deixar o valor padrão selecionado. As regras de OWASP gerenciadas pelo Azure são habilitadas por padrão. Para desabilitar uma regra individual em um grupo de regras, clique em Expand all, marque a caixa de seleção ao lado do número da regra e clique em Desable na guia acima. Para essa configuração vamos deixar os valores padrão clique em Next : Policy settings.
45 – Na tela Policy settings não vamos configurar exclusões para a regra, clique em Next : Custom rules.
46 – Na tela Custom rule, clique em + Add custom rule.
O Firewall de Aplicativo Web do Gateway de Aplicativo do Azure (WAF) v2 vem com um conjunto de regras gerenciado por plataforma pré-configurado que oferece proteção contra muitos tipos diferentes de ataques. Esses ataques incluem script entre sites, injeção de SQL e outros. Se você for um administrador WAF, talvez queira escrever suas próprias regras para aumentar as regras do conjunto de regras básicas (CRS). Suas regras podem bloquear ou permitir o tráfego solicitado com base em critérios de correspondência.
As regras personalizadas permitem que você crie suas próprias regras que são avaliadas para cada solicitação que passa pelo WAF. Essas regras têm uma prioridade mais alta do que o resto das regras nos conjuntos de regras gerenciados. As regras personalizadas contêm um nome de regra, prioridade de regra e uma série de condições correspondentes. Se essas condições forem atendidas, uma ação será executada (para permitir ou bloquear).
Por exemplo, você pode bloquear todas as solicitações de um endereço IP no intervalo 192.168.5.4/24. Nessa regra, o operador é IPMatch , o matchValues é a faixa de endereços IP (192.168.5.4/24), e a ação é bloquear o tráfego. Você também define o nome e a prioridade da regra.
As regras personalizadas oferecem suporte ao uso de lógica de composição para criar regras mais avançadas que atendam às suas necessidades de segurança. Por exemplo, ((Condição 1 e Condição 2) ou Condição 3). Isso significa que se a Condição 1 e a Condição 2 forem atendidas, ou se a Condição 3 for atendida, o WAF deve executar a ação especificada na regra personalizada.
Diferentes condições de correspondência dentro da mesma regra são sempre combinadas usando e . Por exemplo, bloqueie o tráfego de um endereço IP específico e apenas se estiver usando um determinado navegador.
Se você deseja usar ou entre duas condições diferentes, as duas condições devem estar em regras diferentes. Por exemplo, bloqueie o tráfego de um endereço IP específico ou bloqueie o tráfego se estiver usando um navegador específico.
OBSERVAÇÃO: O número máximo de regras personalizadas WAF é 100.
54 – Caso seja necessário podemos criar ou modificar as configurações existentes.
Testando as funcionalidades do Web Application Firewall
O que é vulnerabilidade de XSS Stored?
O XSS Stored é a vulnerabilidade de script entre sites mais perigosa. Esse tipo de vulnerabilidade surge sempre que um aplicativo da web armazena dados fornecidos pelo usuário para uso posterior no backend sem realizar nenhum filtro ou sanitização de entrada . Como o aplicativo da web não aplica nenhum filtro, um invasor pode injetar algum código malicioso neste campo de entrada. Este código malicioso também pode ser uma carga útil XSS válida. Portanto, sempre que qualquer pessoa visitar a página vulnerável onde o código malicioso foi injetado, ela receberá um pop-up na janela do navegador. Isso provará que a página da Web fornecida é vulnerável à vulnerabilidade de XSS armazenado.
55 – Copie o IP Publico do Application Gateway e cole em seu navegado.
56 – Em seguida faça login na aplicação.
Usuário: admin
Senha: password
57 – Na tela da aplicação clique em XSS (Stored).
58 – Em Name digite test1 para a opção Message digite <script>alert()</script> em seguida clique em Sign Guestbook.
59 – Após clicar em Sign Guestbook o WAF faz o bloqueio do ataque, como podemos observar na imagem abaixo.
O que é vulnerabilidade SQL Inject
A injeção de SQL é considerada uma vulnerabilidade de alto risco devido ao fato de que pode levar ao comprometimento total do sistema remoto. É por isso que em quase todos os trabalhos de teste de penetração de aplicativos da Web, os aplicativos são sempre verificados quanto a falhas de injeção de SQL. Uma definição geral e simples Quando um aplicativo é vulnerável à injeção de SQL é quando o aplicativo permite que você interaja com o banco de dados e execute consultas no banco de dados, então ele fica vulnerável a ataques de injeção de SQL.
60 – Na aplicação clique em SQL Injection.
61 – Usaremos a instrução UNION para juntar duas consultas e poder descobrir a versão do banco de dados, digite o comando abaixo na aplicação e clique em Submit.
‘union select @@ version #
Também podemos tentar consultar as colunas disponíveis da tabela usando a ordem por sintaxe, com o seguinte comando:
SELECIONE First_Name, Last_Name FROM usuários WHERE ID = ” ordenar por 1 #
62 – Como podemos observar o WAF fez o bloqueio dos ataques SQL Inject na aplicação.
Verificando os logs do Web Application Firewall
63 – No portal pesquise por Applications gateways, em Applications Gateway selecione o recurso que criamos.
64 – Em Monitoring clique em Logs.
65 – Digite a query abaixo para trazer todas as informações relacionada ao Application Gateway Firewall, em seguida clique em Run.
AzureDiagnostics
| where ResourceProvider == “MICROSOFT.NETWORK” and Category == “ApplicationGatewayFirewallLog”
66 – Em Results nos campos requestUri_s e Message perca que temos as informações dos ataques sqli inject e xss.
Comente suas sugestões e observações!
Forte abraço, obrigado e até o próximo post.
Carreira desenvolvida na área de tecnologia da informação, com ampla experiência em Cloud
Computing e Cloud Security.
Forte atuação em projetos de Cloud Security no Microsoft Azure e com tecnologias de
segurança do Microsoft 365.
Tenho Experiência em Microsoft Azure, Microsoft 365, AWS e Windows Server.
Sou Microsoft MVP na categoria Microsoft Azure, AWS Communit Builder Security & Identity e
MCT.