Engenharia na Barracuda

A história por detrás do Barracuda Active Threat Intelligence

Há algum tempo, numa das nossas sessões de brainstorming, enquanto as equipas discutiam o próximo nível de evolução dos nossos produtos, tornou-se evidente que a deteção e proteção contra novas e emergentes ameaças exigiam uma análise intensiva de dados em grande escala. A análise precisaria prever o risco dos clientes e fazê-lo de forma eficiente e rápida, caso quiséssemos evitar que ações hostis ocorressem.

Ao analisarmos os requisitos, percebemos que, para proteger contra atacantes avançados como bots, precisávamos construir uma plataforma que pudesse analisar o tráfego das sessões web, correlacioná-lo com dados entre sessões e, para muitas coisas, em toda a base de clientes. Também descobrimos que muitas partes do sistema precisavam de ser em tempo real, algumas quase em tempo real e outras poderiam ter uma fase de análise muito mais longa.

Há alguns anos, introduzimos o Barracuda Advanced Threat Protection (BATP) para proteção contra ataques de malware zero-day em toda a linha de produtos Barracuda. Esta funcionalidade — analisar ficheiros para detetar malware utilizando vários motores além de sandboxing — foi introduzida nos produtos de segurança de aplicações da Barracuda para proteger aplicações como sistemas de processamento de encomendas onde os ficheiros eram carregados por terceiros. Esta foi a primeira tentativa de utilizar uma camada baseada em nuvem para análises avançadas que seriam difíceis de incorporar em appliances de web application firewall.

Embora a camada cloud BATP pudesse lidar com milhões de verificações de ficheiros, precisávamos de um sistema que pudesse armazenar grandes quantidades de meta-informações para que pudessem ser analisadas para descobrir ameaças novas e em evolução. Isto iniciou-nos na jornada em direção à próxima plataforma de inteligência de ameaças.

Como funciona o Active Threat Intelligence

A plataforma Barracuda Active Threat Intelligence é a nossa resposta. A plataforma é construída num enorme data lake,  que pode lidar com o processamento de fluxo, bem como o processamento de dados em lote. Processa milhões de eventos por minuto, em várias regiões geográficas, e fornece inteligência utilizada para detetar bots e ataques do lado do cliente, além de fornecer informações para proteger contra esses vetores de ameaças. O Barracuda Active Threat Intelligence foi desenvolvido com uma arquitetura aberta para poder evoluir rapidamente e lidar com ameaças mais recentes.

Atualmente, a plataforma Barracuda Active Threat Intelligence recebe dados dos motores de segurança do Barracuda Web Application Firewall e do WAF-as-a-Service, assim como de outras fontes. À medida que os eventos são recebidos, são enriquecidos com feeds de ameaças obtidos por crowdsourcing e outras bases de dados de inteligência. A análise detalhada desses eventos, tanto individualmente quanto como parte de uma sessão de utilizador, é utilizada para categorizar os clientes como humanos ou bots.

Os pipelines de análise de dados utilizam vários motores e modelos de aprendizagem automática para analisar múltiplos aspetos do tráfego e chegar às suas recomendações, que são finalmente reconciliadas para produzir o veredicto final.

Maneiras como o Active Threat Intelligence ajuda a proteger as suas aplicações

Para além de suportar toda a análise necessária para a Proteção Avançada contra bots, a plataforma Active Threat Intelligence está a ser utilizada para as nossas mais recentes ofertas: Proteção do Lado do Cliente e o Motor de Configuração Automatizada.

O Active Intelligence de ameaça monitoriza quaisquer recursos externos que possam ser usados pela aplicação, como um JavaScript externo ou uma folha de estilo. A monitorização de recursos externos garante que estamos cientes da superfície de ameaças e que podemos proteger-nos contra ataques como o MageCart e outros.

Como os metadados que são recolhidos são extremamente ricos, podemos extrair informações adicionais deles para ajudar os administradores, fornecendo recomendações de configuração com base no tráfego real que chega às suas aplicações.

Esta plataforma tem sido instrumental para nos ajudar a construir a próxima geração de capacidades de proteção que os nossos clientes requerem. Continuamos a aproveitar esta plataforma escalável para reunir insights profundos sobre padrões de tráfego, consumo de aplicações e mais. Fique atento aos blogs das nossas equipas de engenharia que falarão sobre como criámos o Barracuda Advanced Threat Intelligence.

Anshuman Singh

Anshuman Singh é Senior Director Product Management na Barracuda. Conecte-se com ele no LinkedIn aqui.

www.barracuda.com

Registo de eventos altamente escalável para AWS

A maioria das aplicações gera eventos de configuração e de acesso. É importante que os administradores tenham visibilidade sobre estes eventos. O Serviço de Segurança de E-mail Barracuda fornece transparência e visibilidade em muitos destes eventos para ajudar os administradores a afinar e compreender o sistema. Por exemplo, saber quem iniciou sessão na conta e quando. Ou saber quem adicionou, alterou ou eliminou a configuração de uma determinada política.

Para construir este sistema distribuído e pesquisável, surgem muitas questões, tais como:

• Como deve gravar estes logs de todas as aplicações, serviços e máquinas num local central?
• Qual deve ser o formato padrão dos ficheiros de log?
• Por quanto tempo deve reter esses registos?
• Como deve correlacionar eventos de diferentes aplicações?
• Como fornece um mecanismo de pesquisa simples e rápido através de uma interface de utilizador para o administrador?
• Como disponibiliza estes logs através de uma API?

Quando se pensa em um mecanismo de pesquisa distribuído, a primeira coisa que vem à mente é o Elasticsearch. É altamente escalável com pesquisa quase em tempo real e está disponível como um serviço totalmente gerido na AWS. Assim, a jornada começou com a ideia de armazenar esses logs de eventos no Elasticsearch e todas as diferentes aplicações enviando logs para o Elasticsearch usando o Kinesis Data Firehose.

Componentes envolvidos nesta arquitetura

1. Kinesis Agent – O Amazon Kinesis Agent é uma aplicação Java independente que oferece uma forma fácil de recolher e enviar dados para o Kinesis Data Firehose. O agente monitoriza continuamente os ficheiros de log de eventos nas instâncias do EC2 Linux e envia-os para o fluxo de entrega do Kinesis Data Firehose configurado. O agente gere a rotação de ficheiros, pontos de verificação e repetições em caso de falhas. Fornece todos os seus dados de forma fiável, atempada e simples. Nota: Se a aplicação que precisa de escrever no Kinesis Firehose for um contentor Fargate, será necessário um contentor Fluentd. No entanto, este artigo foca-se em aplicações que correm em instâncias Amazon EC2.
2. Kinesis Data Firehose – O método de inserção direta do Amazon Kinesis Data Firehose pode gravar dados formatados em JSON no Elasticsearch. Desta forma, não armazena dados no fluxo.
3. S3 – Um bucket S3 pode ser usado para fazer backup de todos os registos ou dos registos que falham na entrega ao Elasticsearch. As políticas de ciclo de vida também podem ser configuradas para o arquivamento automático dos registos.
4. Elasticsearch – Elasticsearch hospedado na Amazon. O acesso ao Kibana pode ser ativado para auxiliar na consulta e pesquisa dos logs para fins de depuração.
5. Curator – A AWS recomenda usar o Lambda e o Curator para gerir os índices e instantâneos do cluster Elasticsearch. A AWS tem mais detalhes e exemplos de implementação que podem ser encontrados aqui
6. Interface REST API – Pode criar uma API como uma abstração para o Elasticsearch que se integra bem com a interface do utilizador. As arquiteturas de micro serviços orientadas por API são comprovadamente as melhores em muitos aspetos, como segurança, conformidade e integração com outros serviços.

Escalonamento

• Kinesis Data Firehose: Por predefinição, os fluxos de entrega firehose podem ser escalonados até 1 000 registos/segundo ou 1 MiB/segundo para a região Leste dos EUA (Ohio). Este é um limite flexível e pode ser aumentado até 10 000 registos/segundo. Isto é específico da região.
• Elasticsearch: O cluster Elasticsearch pode ser escalado tanto em termos de armazenamento quanto de poder de computação na AWS. Também é possível realizar atualizações de versão. O Amazon ES utiliza um processo de implementação blue/green ao atualizar domínios. Isso significa que o número de nós no cluster pode aumentar temporariamente enquanto as suas alterações são aplicadas.

Vantagens desta Arquitetura

1. A arquitetura do pipeline é completamente gerida de forma eficaz e requer muito pouca manutenção.
2. Se o cluster Elasticsearch falhar, o Kinesis Firehose pode reter registos por até 24 horas. Além disso, os registos que não são entregues também são copiados para o S3.

As probabilidades de perda de dados são baixas com estas opções disponíveis.

3. O controlo de acesso detalhado é possível tanto para o Kibana como para a API do Elasticsearch através de políticas de IAM.

Deficiências

1. Os preços devem ser cuidadosamente considerados e monitorizados. O Kinesis Data Firehose pode lidar com grandes quantidades de ingestão de dados com facilidade e, se um agente malicioso começar a registar grandes quantidades de dados, o Kinesis Data Firehose irá entregá-los sem problemas. Isso pode acarretar custos elevados.
2. A integração do Kinesis Data Firehose com o Elasticsearch é suportada apenas para clusters Elasticsearch não-vpc.
3. Atualmente, o Kinesis Data Firehose não pode entregar logs para clusters Elasticsearch que não sejam hospedados pela AWS. Se pretender hospedar clusters do Elasticsearch por conta própria, esta configuração não funcionará.

Conclusão

Se procura uma solução totalmente gerida e que (na sua maioria) escala sem intervenção, esta seria uma boa opção a considerar. O backup automático para o S3 com políticas de ciclo de vida também resolve facilmente o problema de retenção e arquivamento de logs.

Sravanthi Gottipati

Sravanthi Gottipati é Engineering Manager de segurança de e-mail na Barracuda Networks. Pode conectar-se com ela no LinkedIn aqui.

www.barracuda.com

DJANGO-EB-SQS: Uma forma mais fácil para as aplicações Django comunicarem com AWS SQS

Os serviços AWS, como Amazon ECS, Amazon S3, Amazon Kinesis, Amazon SQS e Amazon RDS, são amplamente utilizados em todo o mundo. Na Barracuda, utilizamos AWS Simple Queue Service (SQS) para gerir as mensagens dentro e entre os micro serviços que desenvolvemos na framework Django.

O AWS SQS é um serviço de fila de mensagens que pode “enviar, armazenar e receber mensagens entre componentes de software em qualquer volume, sem perder mensagens ou exigir que outros serviços estejam disponíveis.” O SQS foi concebido para ajudar as organizações a dissociar aplicações e dimensionar serviços, sendo a ferramenta perfeita para o nosso trabalho com micro serviços.  No entanto, cada novo micro serviço baseado em Django ou dissociação de um serviço existente utilizando AWS SQS exigia que duplicássemos o nosso código e lógica para comunicar com o AWS SQS. Isso resultou em muito código repetido e encorajou a nossa equipa a construir esta biblioteca GitHub: DJANGO-EB-SQS

Django-EB-SQS é uma biblioteca Python destinada a ajudar os desenvolvedores a integrar rapidamente o AWS SQS com aplicações existentes e/ou novas baseadas em Django. A biblioteca cuida das seguintes tarefas:

• Serialização dos dados
• Adicionar lógica de atraso
• Polling contínuo da fila
• Desserializar os dados de acordo com os padrões da AWS SQS e/ou utilizar bibliotecas de terceiros para comunicar com a AWS SQS.

Em suma, abstrai toda a complexidade envolvida na comunicação com o AWS SQS e permite que os programadores se concentrem apenas na lógica central do negócio.

A biblioteca é baseada no Django ORM framework e na boto3 library.

Como o utilizamos

A nossa equipa trabalha numa solução de proteção de e-mail que utiliza inteligência artificial para detetar spear phishing e outros ataques de social engineering. Integramos com a conta Office 365 do nosso cliente e recebemos notificações sempre que ele recebe novos Emails. Uma das tarefas consiste em determinar se o novo Email está livre de qualquer fraud ou não. Ao receber essas notificações, um dos nossos serviços (Figura 1: Serviço 1) comunica-se com o Office 365 através da API Graph e obtém esses Emails. Para processamento posterior desses Emails e para disponibilizá-los para outros serviços, eles são enviados para a fila AWS SQS (Figura 1: queue_1).

Figura 1

Vamos analisar um caso de uso simples de como utilizamos a biblioteca nas nossas soluções. Um dos nossos serviços (Figura 1: Serviço 2) é responsável por extrair cabeçalhos e conjuntos de recursos de Emails individuais e disponibilizá-los para outros serviços consumirem.

O serviço 2 está configurado para escutar a queue_1 para recuperar os corpos de Email brutos.

Vamos supor que o Serviço 2 realiza as seguintes ações:

# Consumir mensagens de email da queue_1

…

# extrair cabeçalhos e conjuntos de funcionalidades dos Email

…

# submeter uma tarefa

processar_mensagem.atraso(id_locatário=, id_e-mail=, cabeçalhos=, id_locatário=, conjunto_de_recursos=, ….)

Este método process_message não será chamado de forma síncrona, mas sim colocado em fila como uma tarefa e será executado assim que um dos trabalhadores o selecionar. O trabalhador aqui pode ser do mesmo serviço ou de um serviço diferente. O autor da chamada do método não precisa preocupar-se com o comportamento subjacente e como a tarefa será executada.

Vamos ver como o método process_message e definido como uma tarefa.

importar tarefa de eb_sqs.decorators

@task(queue_name='queue_2′, max_retries=3)
def process_message(tenant_id: int, email_id: str, headers: List[dict], feature_set: List[dict], …) :

tente:

# executar alguma ação usando cabeçalhos e conjuntos de funcionalidades
# também pode enfileirar tarefas adicionais, se necessário

except(OperationalError, InterfaceError) as exc:

tente:

process_message.retry()

exceto MaxRetriesReachedException:

logger.error('MaxRetries alcançado para Service2:process_message ex: {exc}')

Quando decoramos o método com o decorador de tarefa, o que acontece por trás é que ele adiciona dados adicionais, como o método de chamada, o método de destino, seus argumentos e alguns metadados adicionais antes de serializar a mensagem e enviá-la para a fila AWS SQS. Quando a mensagem é consumida da fila por um dos trabalhadores, ela contém todas as informações necessárias para executar a tarefa: qual método chamar, quais parâmetros passar e assim por diante.

Também podemos tentar novamente a tarefa em caso de exceção. No entanto, para evitar um cenário de loop infinito, podemos definir um parâmetro opcional max_retries, onde podemos parar o processamento depois de atingir o número máximo de tentativas. Podemos então registar o erro ou enviar a tarefa para uma fila de mensagens não entregues para análise adicional.

O AWS SQS permite atrasar o processamento da mensagem em até 15 minutos. Podemos adicionar uma funcionalidade semelhante à nossa tarefa passando o parâmetro de atraso:

process_message.delay(email_id=, headers=, …., delay=300) # atrasando em 5 minutos

A execução das tarefas pode ser realizada executando o comando Django process_queue. Isso permite ouvir uma ou mais filas, ler as filas indefinidamente e executar as tarefas à medida que elas chegam:

python manage.py process_queue –queues

Acabámos de ver como esta biblioteca facilita a comunicação dentro de um serviço ou entre serviços através das filas AWS SQS.

Mais detalhes sobre como configurar a biblioteca com as definições do Django, a capacidade de ouvir várias filas, a configuração de desenvolvimento e muitas outras funcionalidades podem ser encontrados aqui.

Contribuir

Se pretender contribuir para o projeto, consulte aqui: DJANGO-EB-SQS

Rohan Patil

Rohan Patil é Principal Software Engineer na Barracuda Networks. Atualmente, ele está a trabalhar no Barracuda Sentinel, uma proteção baseada em IA contra phishing e apropriação de contas. Ele trabalhou nos últimos cinco anos com tecnologias de cloud e, na última década, em várias funções relacionadas ao desenvolvimento de software. Ele possui um mestrado em Ciência da Computação pela California State University e um bacharelato em Ciência da Computação pela Universidade de Mumbai, Índia.

Conecte-se com Rohan no LinkedIn aqui.

www.barracuda.com

Utilizar o GraphQL para APIs robustas e flexíveis

O design de API é uma área onde pode haver muita controvérsia entre os desenvolvedores de aplicações cliente e os desenvolvedores de back-end. As APIs REST permitiram-nos projetar servidores sem estado e acesso estruturado a recursos por mais de duas décadas, e continuam a servir a indústria, principalmente devido à sua simplicidade e curva de aprendizagem moderada.

O REST foi desenvolvido por volta do ano 2000, quando as aplicações cliente eram relativamente simples e o ritmo de desenvolvimento não era tão rápido como é hoje.

Com uma abordagem tradicional baseada em REST, o design seria baseado no conceito de recursos que um determinado servidor gere. Em seguida, normalmente utilizamos verbos HTTP, como GET, POST, PATCH, DELETE, para realizar operações CRUD nesses recursos.

Desde os anos 2000, várias coisas mudaram:

• O aumento da utilização de aplicações de página única e aplicações móveis criou a necessidade de um carregamento eficiente de dados.
• Muitas das arquiteturas de back-end passaram de monolíticas para arquiteturas de micro serviços para ciclos de desenvolvimento mais rápidos e eficientes.
• Uma variedade de clientes e consumidores é necessária para as APIs. O REST dificulta a criação de uma API que suporte vários clientes, pois retornaria uma estrutura de dados fixa.
• As empresas esperam lançar funcionalidades no mercado mais rapidamente. Se for necessário fazer uma alteração no lado do cliente, muitas vezes é preciso um ajuste no lado do servidor com REST, o que leva a ciclos de desenvolvimento mais lentos.
• A atenção crescente na experiência do utilizador frequentemente leva ao design de visualizações/widgets que necessitam de dados de múltiplos servidores de recursos da API REST para serem renderizados.

GraphQL como uma alternativa ao REST

GraphQL é uma alternativa moderna ao REST que visa resolver várias deficiências, e a sua arquitetura e ferramentas são construídas para oferecer soluções para as práticas contemporâneas de desenvolvimento de software. Permite que os clientes especifiquem exatamente quais dados são necessários e permite a obtenção de dados de vários recursos em uma única solicitação. Funciona mais como RPC, com consultas nomeadas e mutações em vez de ações obrigatórias padrão baseadas em HTTP. Isso coloca o controlo onde ele deve estar, com o programador da API backend a especificar o que é possível e o cliente/consumidor da API a especificar o que é necessário.

Aqui está um exemplo de consulta GraphQL, que foi uma revelação para mim quando me deparei com isso pela primeira vez. Suponha que estamos a desenvolver um site de microblogging e precisamos consultar as 50 publicações mais recentes.

query recentPosts (count: 50, offset: 0) {
id
title
tags
content
author {
id
name
profile {
email
interests
}
}
}

A consulta GraphQL acima tem como objetivo solicitar:

• 50 publicações recentes
• ID, título, tags e conteúdo de cada publicação do blogue
• Informações do autor contendo id, nome e informações do perfil.

Se tivermos que usar uma abordagem tradicional de API REST para isso, o cliente precisaria fazer 51 solicitações. Se as publicações e os autores forem considerados recursos separados, isso significa um pedido para obter 50 publicações recentes e, em seguida, 50 pedidos para obter informações sobre o autor para cada publicação. Se as informações do autor puderem ser incluídas nos detalhes da publicação, isso também poderia ser uma solicitação com a API REST. No entanto, na maioria dos casos, quando modelamos os nossos dados utilizando as melhores práticas de normalização de bases de dados relacionais, gerimos as informações do autor numa tabela separada, o que faz com que as informações do autor sejam um recurso separado da API REST.

Aqui está a parte interessante do GraphQL. Digamos que, numa visualização móvel, não temos espaço suficiente no ecrã para exibir tanto o conteúdo da publicação como as informações do perfil do autor. Essa consulta agora poderia ser:

query recentPosts(count: 50, offset: 0) {
id
title
tags
author {
id
name
}
}

O cliente móvel agora especifica as informações que deseja, e a API GraphQL fornece exatamente os dados solicitados, nada mais e nada menos. Não tivemos de fazer quaisquer ajustes no lado do servidor, nem o nosso código do lado do cliente teve de mudar significativamente, e o nosso tráfego de rede entre o cliente e o servidor é ideal.

O ponto a destacar aqui é que o GraphQL nos permite projetar APIs flexíveis com base nos requisitos do lado do cliente, em vez de uma perspetiva de gestão de recursos do lado do servidor. A perceção geral é que o GraphQL faz sentido apenas para arquiteturas complexas que envolvem várias dezenas de micro serviços. Isso é verdade até certo ponto, considerando que há uma curva de aprendizagem com o GraphQL em comparação com as arquiteturas REST API. Mas essa lacuna está a diminuir, com um investimento intelectual e financeiro significativo da fundação emergente de fornecedores neutros.

A Barracuda é uma das primeiras a adotar arquiteturas GraphQL. Se este blog despertou o seu interesse, por favor, acompanhe este espaço para os meus próximos blogs, onde aprofundarei mais detalhes técnicos e benefícios arquitetónicos.

Vinay Patnana

Vinay Patnana é o Engineering Manager do serviço de segurança de e-mail da Barracuda.  Nesta função, ele auxilia no design e desenvolvimento de serviços de escalabilidade das soluções de email da Barracuda.

Vinay possui um mestrado em Ciência da Computação pela North Carolina State University e um bacharelato em Engenharia pelo BIT Mesra, na Índia.  Ele está na Barracuda há vários anos e possui mais de uma década de experiência trabalhando com diversas variedades de stacks técnicos.  Pode conectar-se com ele no LinkedIn aqui.

www.barracuda.com