{"id":55733,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/evolyutsiya-web-application-firewall-ot-setevyh-ekranov-do-oblachnyh-sistem-zashhity-s-mashinnym-obucheniem","title":{"rendered":"A Evolu\u00e7\u00e3o do Web Application Firewall: de firewalls tradicionais a sistemas de prote\u00e7\u00e3o em nuvem com aprendizado de m\u00e1quina","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

No nosso material anterior sobre o tema da nuvem, discutimos falamos<\/a><\/noindex>, como proteger recursos de TI na nuvem p\u00fablica e por que os antiv\u00edrus tradicionais n\u00e3o s\u00e3o adequados para esses fins. Neste post, continuaremos a discutir seguran\u00e7a em nuvem e falaremos sobre a evolu\u00e7\u00e3o do WAF e o que \u00e9 melhor escolher: hardware, software ou nuvem.\u00a0<\/b><\/p>\n

\"A
\n<\/p>\n

O que \u00e9 WAF<\/h3>\n

\nMais de 75% dos ataques de hackers s\u00e3o direcionados a vulnerabilidades de aplicativos web e sites: esses ataques s\u00e3o geralmente invis\u00edveis para a infraestrutura de seguran\u00e7a da informa\u00e7\u00e3o e para os servi\u00e7os de seguran\u00e7a. As vulnerabilidades de aplicativos web, por sua vez, acarretam riscos de comprometimento e fraude de contas e dados pessoais dos usu\u00e1rios, senhas e n\u00fameros de cart\u00f5es de cr\u00e9dito. Al\u00e9m disso, as vulnerabilidades em um site servem como ponto de entrada para os invasores na rede corporativa.<\/p>\n

O Web Application Firewall (WAF) \u00e9 uma camada de prote\u00e7\u00e3o que bloqueia ataques a aplicativos web: inje\u00e7\u00f5es SQL, cross-site scripting, execu\u00e7\u00e3o remota de c\u00f3digo, for\u00e7a bruta e bypass de autentica\u00e7\u00e3o. Isso inclui ataques que utilizam vulnerabilidades zero-day. Os firewalls de aplicativos fornecem prote\u00e7\u00e3o monitorando o conte\u00fado das p\u00e1ginas web, incluindo HTML, DHTML e CSS, e filtrando solicita\u00e7\u00f5es potencialmente maliciosas via HTTP\/HTTPS.
\n<\/a><\/noindex><\/p>\n

Quais foram as primeiras solu\u00e7\u00f5es?<\/h3>\n

\nAs primeiras tentativas de criar um Web Application Firewall ocorreram no in\u00edcio dos anos 90. Sabe-se de pelo menos tr\u00eas engenheiros que trabalharam nesta \u00e1rea. O primeiro deles foi o professor de ci\u00eancia da computa\u00e7\u00e3o Gene Spafford da Universidade Purdue. Ele descreveu a arquitetura de um firewall de aplicativos com proxy e publicou isso em 1991 no livro Seguran\u00e7a UNIX na pr\u00e1tica<\/a><\/noindex>.<\/p>\n

Os segundo e terceiro foram os especialistas em seguran\u00e7a da informa\u00e7\u00e3o William Cheswick e Marcus Ranum dos Bell Labs. Eles desenvolveram um dos primeiros prot\u00f3tipos de firewalls de aplicativos. A empresa DEC comercializou essa solu\u00e7\u00e3o com o nome de SEAL (Secure External Access Link). <\/p>\n

Mas o SEAL n\u00e3o era uma solu\u00e7\u00e3o WAF completa. Ele era um firewall de rede cl\u00e1ssico com funcionalidades ampliadas \u2014 a capacidade de bloquear ataques a FTP e RSH. Por essa raz\u00e3o, a primeira solu\u00e7\u00e3o WAF hoje \u00e9 considerada o produto da Perfecto Technologies (depois Sanctum). Em 1999, ela apresentou<\/a><\/noindex> o sistema AppShield. Na \u00e9poca, a Perfecto Technologies estava desenvolvendo solu\u00e7\u00f5es de seguran\u00e7a da informa\u00e7\u00e3o para e-commerce, e o p\u00fablico-alvo de seu novo produto eram lojas online. O AppShield era capaz de analisar solicita\u00e7\u00f5es HTTP e bloqueava ataques com base em pol\u00edticas din\u00e2micas de seguran\u00e7a da informa\u00e7\u00e3o.<\/p>\n

Por volta da mesma \u00e9poca do AppShield (em 2002), surgiu o primeiro WAF de c\u00f3digo aberto. Ele tornou-se ModSecurity<\/a><\/noindex>. Foi criado com o objetivo de popularizar as tecnologias WAF e ainda \u00e9 mantido pela comunidade de TI (aqui est\u00e1 seu reposit\u00f3rio no GitHub<\/a><\/noindex>). O ModSecurity bloqueia ataques a aplicativos com base em um conjunto padr\u00e3o de express\u00f5es regulares (assinaturas) \u2014 ferramentas para verificar solicita\u00e7\u00f5es de acordo com um padr\u00e3o \u2014 OWASP Core Rule Set<\/a><\/noindex>.<\/p>\n

No final, os desenvolvedores conseguiram alcan\u00e7ar seu objetivo \u2014 novas solu\u00e7\u00f5es de WAF come\u00e7aram a surgir no mercado, incluindo aquelas constru\u00eddas com base no ModSecurity.<\/p>\n

Tr\u00eas gera\u00e7\u00f5es \u2014 j\u00e1 \u00e9 hist\u00f3ria<\/h3>\n

\n\u00c9 comum distinguir tr\u00eas gera\u00e7\u00f5es de sistemas WAF, que evolu\u00edram \u00e0 medida que as tecnologias se desenvolveram.<\/p>\n

A primeira gera\u00e7\u00e3o<\/b>. Funciona com express\u00f5es regulares (ou gram\u00e1ticas). Isso inclui o ModSecurity. O fornecedor do sistema estuda os tipos de ataques a aplicativos e cria padr\u00f5es que descrevem solicita\u00e7\u00f5es leg\u00edtimas e potencialmente maliciosas. O WAF compara essas listas e decide o que fazer em uma situa\u00e7\u00e3o espec\u00edfica \u2014 bloquear o tr\u00e1fego ou n\u00e3o.<\/p>\n

Um exemplo de detec\u00e7\u00e3o baseada em express\u00f5es regulares \u00e9 o j\u00e1 mencionado projeto Core Rule Set<\/a><\/noindex> de c\u00f3digo aberto. Outro exemplo \u00e9 Naxsi<\/a><\/noindex>, que tamb\u00e9m \u00e9 de c\u00f3digo aberto. Sistemas baseados em express\u00f5es regulares t\u00eam uma s\u00e9rie de desvantagens, especialmente quando uma nova vulnerabilidade \u00e9 descoberta, o administrador precisa criar regras adicionais manualmente. No caso de uma infraestrutura de TI em larga escala, pode haver milhares de regras. Gerenciar essa quantidade de express\u00f5es regulares \u00e9 bastante complicado, sem mencionar que a verifica\u00e7\u00e3o delas pode diminuir o desempenho da rede.<\/p>\n

As express\u00f5es regulares tamb\u00e9m t\u00eam um n\u00edvel bastante alto de falsos positivos. O famoso linguista Noam Chomsky prop\u00f4s uma classifica\u00e7\u00e3o das gram\u00e1ticas, dividindo-as em quatro n\u00edveis condicionais de complexidade. De acordo com essa classifica\u00e7\u00e3o, as express\u00f5es regulares podem descrever apenas as regras de firewall que n\u00e3o preveem desvios do padr\u00e3o. Isso significa que invasores podem facilmente \"enganar\" um WAF de primeira gera\u00e7\u00e3o. Um dos m\u00e9todos de combate a isso \u00e9 adicionar caracteres especiais \u00e0s requisi\u00e7\u00f5es para os aplicativos que n\u00e3o afetam a l\u00f3gica dos dados maliciosos, mas que quebram a regra de assinatura.<\/p>\n

\"A
\n
\nSegunda gera\u00e7\u00e3o<\/b>. Para contornar os problemas relacionados ao desempenho e \u00e0 precis\u00e3o dos WAFs, foram desenvolvidos firewalls de aplica\u00e7\u00f5es de segunda gera\u00e7\u00e3o. Neles, surgiram os analisadores, que s\u00e3o respons\u00e1veis por identificar tipos espec\u00edficos de ataques (como HTML, JS, etc.). Esses analisadores trabalham com tokens especiais que descrevem as requisi\u00e7\u00f5es (por exemplo, vari\u00e1vel, string, desconhecido, n\u00famero). Sequ\u00eancias potencialmente maliciosas de tokens s\u00e3o colocadas em uma lista separada, que \u00e9 verificada regularmente pelo sistema WAF. Esse conceito foi demonstrado pela primeira vez na confer\u00eancia Black Hat 2012 na forma da biblioteca C\/C++\u00a0libinjection<\/a><\/noindex>, que permite detectar inje\u00e7\u00f5es de SQL.<\/p>\n

Comparado aos WAFs de primeira gera\u00e7\u00e3o, os analisadores especializados podem operar mais rapidamente. No entanto, eles n\u00e3o resolveram as dificuldades relacionadas \u00e0 configura\u00e7\u00e3o manual do sistema diante de novos ataques maliciosos. <\/p>\n

\"A
\n
\nTerceira gera\u00e7\u00e3o<\/b>. A evolu\u00e7\u00e3o na l\u00f3gica de detec\u00e7\u00e3o da terceira gera\u00e7\u00e3o consiste na aplica\u00e7\u00e3o de m\u00e9todos de aprendizagem de m\u00e1quina, permitindo aproximar ao m\u00e1ximo a gram\u00e1tica de detec\u00e7\u00e3o da gram\u00e1tica real de SQL\/HTML\/JS dos sistemas protegidos. Essa l\u00f3gica de detec\u00e7\u00e3o tem a capacidade de adaptar uma m\u00e1quina de Turing para abranger gram\u00e1ticas recursivamente enumer\u00e1veis. Anteriormente, a tarefa de criar uma m\u00e1quina de Turing adapt\u00e1vel era insol\u00favel, at\u00e9 que as primeiras pesquisas em m\u00e1quinas de Turing neurais foram publicadas.<\/p>\n

O aprendizado de m\u00e1quina oferece uma oportunidade \u00fanica de adaptar qualquer gram\u00e1tica para abranger qualquer tipo de ataque sem a necessidade de criar listas de assinaturas manualmente, como era exigido na detec\u00e7\u00e3o de primeira gera\u00e7\u00e3o, e sem a necessidade de desenvolver novos tokenizadores\/analisadores para novos tipos de ataques, como inje\u00e7\u00f5es Memcached, Redis, Cassandra, SSRF, conforme requerido pela metodologia de segunda gera\u00e7\u00e3o. <\/p>\n

Ao combinar todas as tr\u00eas gera\u00e7\u00f5es de l\u00f3gica de detec\u00e7\u00e3o, podemos desenhar um novo diagrama, no qual a terceira gera\u00e7\u00e3o de detec\u00e7\u00e3o \u00e9 destacada com um contorno vermelho (ver Fig. 3). Esta gera\u00e7\u00e3o inclui uma das solu\u00e7\u00f5es que estamos implementando na nuvem em parceria com a 'OnSec', desenvolvedora da plataforma de prote\u00e7\u00e3o adaptativa de aplica\u00e7\u00f5es web e API Valarm. <\/p>\n

Agora, na l\u00f3gica de detec\u00e7\u00e3o, utiliza-se o feedback da aplica\u00e7\u00e3o para autoconfigura\u00e7\u00e3o. Dentro do aprendizado de m\u00e1quina, esse ciclo de feedback \u00e9 chamado de 'refor\u00e7o'. Normalmente, existem um ou mais tipos desse refor\u00e7o:<\/p>\n