Demonstração de Produto: Magic Transit
Presented by: Bruna Villalon, Geison Porfirio, Jorge Verges Cappa Jr.
Originally aired on August 20 @ 12:00 PM - 12:30 PM EDT
Junte-se a nós para aprender mais sobre o Magic Transit, que oferece funções de rede em escala de Cloudflare - proteção DDoS, aceleração de tráfego e muito mais!
Tune in to learn more about Magic Transit, which delivers network functions at Cloudflare Scale — DDoS Protection, traffic acceleration, and much more!
Portuguese
Product Demo
Transcript (Beta)
Opa, boa tarde. Aqui com a gente hoje está o nosso gerente de contas, nosso diretor comercial, Jorge Verges e o Geison, ele é nosso SE, nosso Solutions Engineer, e hoje a gente vai apresentar uma função que tem chamado bastante atenção, uma função que tem gerado bastante conversa, que é o Magic Transit.
Oi Bruna, obrigado pela introdução, obrigado a todos, boa tarde.
Olá, meu nome é Jorge Verges, sou o responsável pela área comercial da Cloudflare no Brasil, e a ideia aqui é a gente falar um pouquinho sobre Magic Transit.
A Magic Transit é um produto já maduro, é um produto proprietário da Cloudflare, a Cloudflare já usa esse produto para a sua própria rede há muitos anos.
Em 2019 essa solução já vem sendo oferecida aos nossos clientes, e a principal funcionalidade dessa ferramenta, desse serviço, é oferecer uma mitigação de DDoS para a camada de rede, é um produto específico na camada 3, ele tem a funcionalidade de proteger, anunciar e proteger os prefixos, os IPs dos nossos clientes através de nossa rede com algumas particularidades.
É uma solução 100% em nuvem, não requer instalação de equipamento, assim como todo o nosso portfólio.
A conexão ou a necessidade para que a gente efetivamente comece a anunciar os prefixos dos nossos clientes é através de BGP e GRE, é uma característica dos nossos servidores, e uma vez feita essa conexão, seja por um túnel GRE tradicional ou um PNI, alguns clientes, quando ele já tem uma demanda ou uma capacidade de clean pipe um pouco mais alta, já preferem fazer uma conexão PNI em um dos vários data centers da Cloudflare no Brasil e no mundo também, para que a gente tenha um nível de proteção, um nível de confiança de conexão mais alto para poder fazer o anúncio e retornar esse clean pipe para os clientes.
Tento da questão das particularidades, acho que vale aqui frisar alguns pontos importantes.
Nós hoje temos uma rede N -Cast, temos mais de 8 mil peerings, entre peerings públicos e privados, isso ajuda muito a questão da performance, a principal funcionalidade obviamente é a proteção contra ataques de alta volumetria, mas a gente consegue também muitas vezes acelerar o tráfego, justamente porque é uma rede extremamente conectada com os principais conteúdos e players da Internet, e por ser N-Cast, isso também gera um impacto de performance bem importante, bem interessante.
As formas de mitigação ou as particularidades da forma como a Cloudflare mitiga os ataques, são as seguintes, a partir do momento que a gente anuncia isso, a partir do momento que nós anunciamos o seu prefixo do nosso cliente através da nossa plataforma, nós temos todos os nossos nós que são full stack, capazes de resolver qualquer questão de segurança e performance de forma totalmente independente, monitorando tudo o que vem direcionado à sua rede, e de forma totalmente independente, qualquer nó da Cloudflare é capaz, por um processo de filtragem, monitorar e iniciar uma ação de bloqueio, entregando o clean pipe para você de forma constante, sem a adição de latência.
Então acho que o principal diferencial da Cloudflare é poder mitigar ataques de forma totalmente descentralizada, nós temos uma rede hoje com presença em mais de 200 cidades, em mais de 100 países, hoje no Brasil nós já temos 12 data centers implementados em todo o território nacional, e eles funcionam na verdade como se fossem scrub centers totalmente independentes, capazes de mitigar já na origem do direcionamento desse ataque à sua rede, um comportamento malicioso, uma exploração de vulnerabilidade, um ataque volumétrico então isso reflete em uma mitigação totalmente descentralizada e sem a adição de latência, nós não temos que fazer aquele fluxo de direcionamento do tráfego para um scrub center, que não necessariamente pode estar próximo à sua rede, para retornar esse tráfego limpo para você, que muitas vezes funciona com uma certa limitação, mas adiciona latência e pode inclusive gerar uma reclamação do usuário, de um cliente que esteja utilizando a sua rede para acesso à Internet.
Então são dois pontos bem interessantes, a gente tem tido destaque nas avaliações do Gartner, da Forrester, da IDC, nos últimos anos, a gente vem despontando como a solução com o maior número de ratings positivos, quando analisado o item a item da nossa solução de mitigação DDOS, isso vale também para o Magic Transit, além de toda a proteção que a gente oferece de DDOS na camada 7 também, e a nossa capacidade de mitigação.
Hoje, globalmente, nós já operamos acima dos 60 terabits de capacidade, o que nos dá um grau de conforto muito grande em poder garantir ao nosso cliente que nós teremos a capacidade de mitigar ataques de alta volumetria, de alta duração ou de alta repetição.
Então, hoje a gente tem uma solução bem descentralizada, bem robusta, para mitigar todo e qualquer tipo de ataque DDOS.
Como uma introdução rápida do produto, é isso, eu vou passar aqui para o nosso amigo Jason, para ele entrar um pouco nas questões técnicas e apresentar alguns detalhes técnicos da solução para todos vocês.
Obrigado! Obrigado Jorge!
Eu acredito que é uma das frases mais repetidas nesse último ano. Vamos lá, primeiramente é um prazer estar aqui, podendo falar um pouco mais do Magic Transit, como o Jorge estava comentando, é uma solução para mitigação de DDoS em camada 3 e também criar filtros e files em camada 4, até a camada 4 também.
O Magic Transit, tecnicamente falando, ele consiste em clientes que têm uma ASN e um prefixo de IPv4, no mínimo um barra 24, que pode ser anunciado na Internet, ou também IPv6, ou só um IPv6, ou também IPv6.
O Magic Transit é compatível com os dois protocolos de IP.
Então, como isso vai funcionar? Você vai criar um túnel GRE do seu roteador de borda até a Cloudflare.
A Cloudflare vai usar uma Redenecast, então você não tem que se preocupar que você sempre vai acabar caindo num datacenter que está mais próximo de você, ou que está mais rápido ali, atendendo mais de acordo com o roteamento que está ali adotado.
Existe toda alta disponibilidade do lado da Cloudflare, não só de infraestrutura dentro desse datacenter onde ela está, como também com outros datacenters devido ao formato NKS da rede.
Você pode ter somente um datacenter com dois roteadores, ou somente com um roteador, ou mais datacenters e proteger ambos de uma forma única em Cloudflare.
Você pode ter muitos prefixos, ou somente um prefixo, enfim, você pode ser tanto um cliente pequeno como um cliente grande, a solução vai ser exatamente a mesma de uma forma extremamente simples de ser configurada.
Então, uma vez que você tem esse GRE, esse GRE pode ser utilizado sobre a Internet ou por um PNI, para clientes que têm essa necessidade e a viabilidade de poder fazer uma conexão direta com a estrutura da Cloudflare, com isso baixando ainda mais a latência, deixando a conexão ainda mais estável e rápida.
Uma vez estabelecido esse túnel, a Cloudflare o que ela vai começar a fazer?
Ela vai começar a repetir esse seu prefixo para a Internet utilizando a rede de inquérito da Cloudflare, ou seja, o teu bloco de IP vai estar presente em todos os nós da Cloudflare, em todos os datacenters que a Cloudflare está presente no mundo todo, sem exceção, a não ser que você queira algum tipo de customização.
Por padrão, isso vai ser disponibilizado em todo o cenário e não se preocupe que isso também não tem nenhum tipo de diferença de custo quanto a isso.
Você não vai comprar, você vai ter mitigação só na Europa, você vai ter mitigação.
Não, a Cloudflare ela trabalha com os datacenters dela no formato full stack, ou seja, todos os datacenters da Cloudflare fazem todos os serviços da Cloudflare, não existe scrum sharing, então o seu tráfego nunca vai ser roteado no ato de uma mitigação, no ato de um ataque.
Até mesmo a experiência que os nossos clientes de Magic Transit têm é que quando ele ativa a mitigação e começa efetivamente a utilizar a rede da Cloudflare, a experiência do usuário é muito melhor, o tráfego acaba sendo bem mais rápido, a latência baixa consideravelmente e a experiência do usuário, dos clientes deles é bastante interessante porque não se nota nenhum tipo de mitigação.
O formato que a Cloudflare utiliza para mitigação de dose é um formato todo desenvolvido em house, não vem dos procedimentos que anteriormente estavam sendo usados pelas antigas soluções, então eu costumo dizer que o nível de falso positivo é baixíssimo, se não muito próximo do nulo.
Então a experiência que realmente os clientes têm é bastante positiva porque é uma outra tecnologia desenvolvida e nova reinventando o que antes já era bom.
Toda a solução do Magic Transit implementada vem baseada em alguns pontos, esse é o dashboard da solução, então deixa eu mostrar aqui para vocês um pouquinho, aqui eu vou ter o dashboard do Magic Transit C, onde eu consigo ver a saúde e a disponibilidade dos meus túneis GRS, nesse caso aqui é um ambiente de lab, então eu tenho aqui configurações que não estão em produção, é só mesmo para demonstração de clientes e experimentos para demonstração.
Eu também vou ter aqui os prefixos, então aqui eu consigo ver, nesse caso aqui eu estou com dois prefixos barra 24, um deles está ativo e outros não, esse é um ponto muito interessante, clientes Magic Transit pode estar utilizando a Cloudflare em duas modalidades, uma always online, ou seja, ele sempre está ativo utilizando a Cloudflare, então não necessita de um critério de fazer uma mitigação, ele sempre está protegido e todo o trânsito sempre vai passar pela Cloudflare, e on -demand, então quando você sofre um ataque você ativa a mitigação e a Cloudflare vai começar a fazer essa mitigação.
Lembrando que enquanto isso se vocês tiverem perguntas, podem mandar perguntas e a gente vai ter uma sessão de responder perguntas no final, ok?
Bem, vamos lá, então eu poderia acessar pelo próprio dashboard, ativando essa mitigação, lembrando que todo o dashboard da Cloudflare é API first, então o que que isso significa?
Que tudo que você faz via dashboard você está utilizando as APIs disponibilizadas para os clientes, então se você faz isso no dashboard, então você consegue fazer isso via API também, ok?
Então aqui eu ativaria e desativaria a mitigação, eu vou ter também a possibilidade de criar regras de Faro, onde eu consigo trabalhar tanto a camada 3 como camada 4, especificando um protocolo, uma porta, se eu vou permitir TCP, todas as configurações aqui, por exemplo, eu estou aqui, eu estou colocando o tamanho do pacote, mas eu poderia, por exemplo, estar bloqueando uma região, vamos supor, eu quero bloquear aqui, não sei, eu vou deixar somente South America, ou até mesmo eu poderia colocar uma negativa, para quem já é cliente de Cloudflare, está muito familiarizado com esse tipo de dashboard, o conceito é o mesmo, e aqui eu vou tomar ação, se eu vou bloquear ou se eu vou permitir, ok?
Então você pode criar aqui regras e da mesma forma você vai ter um dashboard onde você vai ter a análise do seu tráfego, ok?
Então você pode colocar aqui por IP de destino, você pode olhar pela ação, se foi permitido ou bloqueado, o tipo de ataque, e mais aqui para baixo você vai ter uma visão mais detalhada dos eventos e tudo que contém no evento, você pode fazer o filtro de acordo com os campos aqui, então, dessa maneira, uma vez que o filtro está pronto, você pode imprimir e gerar dali um report para você, e também de acordo com o período que você quer, é por isso que é possível também fazer, ok?
Não só pelo número de pacotes, mas também pelo consumo de banda, ok?
Exato, aqui então eu consigo ver pelos IPs, os principais IPs que geraram aqui ataques para minha rede, e a mitigação e os detalhes de cada uma dessas mitigações, os países de onde vieram esse ataque, os ASNs, onde proveu a versão do ataque do protocolo IP, as portas onde foram atacados, e o tipo de flag que foi encontrada no TCP, ok?
Eu acredito que da parte técnica, basicamente é isso, eu queria deixar para algum comentário a mais, alguma pergunta?
Bom Jason, eu ia só adicionar um detalhe aqui, quando você explicou as duas modalidades às quais nós ofertamos esse serviço, no modo Always On, o cliente anuncia constantemente os seus prefixos via Cloudflare, que é uma das formas que a Cloudflare pode oferecer esse serviço, anúncio de prefixos constante, aí nós teríamos um papel de trânsito e de proteção a todos os prefixos do cliente, o tempo de mitigação sob o modo Always On é extremamente baixo, a gente garante uma mitigação nesse modo de em até 3 segundos para fazer a efetiva mitigação do ataque, no modo On Demand é muito comum nós trabalharmos com clientes que já possuem uma ou mais ferramentas de mitigação, e ele ali dentro das ferramentas ele também quer ter uma solução com a Cloudflare para utilizar sob demanda em alguns casos específicos ou em alguns cenários de ataque específicos, ou até para proteger alguns blocos de IP de forma mais específica, e aí você consegue, nós conseguimos dentro desse cenário sob demanda, trabalhar, fazer um trabalho junto com inclusive um sistema de detecção de ataque desse cliente, que não necessariamente precisa ser o nosso, e via API ou via comando ele consegue acionar a nossa ferramenta de mitigação sob demanda, por isso que ele é colocado aí, o nome da solução é o modo On Demand, então existe também essa flexibilização na forma de como o serviço é ofertado, ele pode ser ajustado aí dependendo da necessidade de cada cliente.
Perfeito, um outro ponto também que eu acabei me recordando, é que clientes por exemplo que utilizam o Always Online, lembrando que você está, todo o seu trânsito que está chegando até a sua rede, primeiro vai passar pela Cloudflare, e uma vez que você utiliza, por exemplo, os firewalls, já permitindo o tipo de trânsito que você vai ter, por exemplo, para um IP específico, eu só espero ter um web server trabalhando na porta 80 e na 443, e talvez, se for um Linux, por exemplo, um SSH, então você consegue criar essas regras ali, e lembrando que a Cloudflare não vai te cobrar por tráfego sujo, ou seja, ela não vai te cobrar pelo ataque que você recebe, então, dessa maneira, qualquer outra coisa que você espera receber vai ser bloqueado já na nuvem, na Cloudflare, ou seja, não vai chegar até você, com isso vai desonerar o seu link de Internet, vai desonerar o seu roteador, o seu firewall de borda que você tem dentro da sua infraestrutura, enfim, tem uma série de valores agregados que eu acho que é bem interessante, elevando ainda mais a qualidade do link de Internet, da qualidade do seu serviço, e a segurança, obviamente.
Sem dúvida.
E Jason, acho que você podia até explorar um pouquinho esse cenário de integração via API, inclusive para o modo on-demand, para quem possui hoje uma ferramenta de detecção e quer fazer uma call de API, um processo totalmente automatizado para acionar o nosso sistema de mitigação, você poderia dar um breve resumo, em uma linguagem mais técnica.
Sim, bem, aqui eu vou ter os detalhes da API, o tag que eu vou usar para fazer essa chamada, e com isso eu vou utilizar um tipo de integração muito simples em API, a documentação da API da Cloudflare, não só do Magic Transit, mas de toda, ela está aqui em api.Cloudflare.com, aqui eu vou ter todo o conteúdo, na verdade toda a documentação baseada em API vai estar aqui, então aqui eu vou poder explorar e não é nada muito complexo, eu sei que normalmente o pessoal de rede quando fala em fazer integração em API, então vai envolver um desenvolvedor, mas é algo muito trivial, é muito fácil, e obviamente uma vez tendo o suporte nosso aqui, nós vamos te ajudar e orientar você até mesmo colocar o modelo certinho, com o teu caso, com o teu prefixo, qual seria a chamada que você tem que executar para iniciar a mitigação e remover a mitigação, é algo que você pode colocar dentro de um detector, de um sistema de monitoramento seu, executando aquela ação, quando encontrar uma anomalia ou algo suspeito, então ele executa, só executa aquele comando e pronto, sua mitigação já iniciou.
Lembrando que devido a propagação de BGP, o tempo de iniciar uma mitigação em on-demand, no método on-demand, ela leva até 5 minutos e para desativar a mitigação ela pode levar até 15 minutos, isso não é por causa da Cloudflare, isso é a propagação BGP mesmo pela Internet, e como o Jorge falou, eu gostaria de reançar que o nosso tempo de mitigação de um ataque já online, já ativo, já passando pela Cloudflare, é de menos de 3 segundos, então é muito rápido, e outro ponto que eu reassalto é a incidência de mitigação de falso positivo, quando está recebendo um ataque, eu acho bastante relevante pela experiência que eu tenho de vida em ambientes sofrendo ataque de dose, eu gosto de ressaltar que a solução do Magic Transit da Cloudflare é muito interessante.
Vou ressaltar aqui, Jason, um pouco a nossa presença no Brasil, a gente tem uma presença global bem consolidada no Brasil, um crescimento muito grande, hoje no Brasil nós temos nós nos principais datacenters de São Paulo capital, são 4 nós totalmente independentes em cages dentro dos principais datacenters, Campinas, Ribeirão Preto, Rio de Janeiro, dentro dos principais datacenters do Rio, temos Brasília, Fortaleza Salvador, Curitiba, Porto Alegre, e o plano é terminar 2021 com pelo menos 22 nós em todo o território nacional, ou seja, para aqueles clientes que por requisito ou por preferência querem uma conexão via P&I, uma conexão porta com porta, hoje nós já temos um leque de expansão, uma cobertura, perdão, uma cobertura bem grande nos principais eixos e de norte a sul também, o nosso produto, a nossa solução permite que você possa fazer uma conexão, a gente chama de home ou multi-home, seria por exemplo mais de uma conexão se você anuncia, por exemplo, seus prefixos globalmente, quer ter uma conexão no Brasil e uma segunda conexão nos Estados Unidos, na Europa, na Ásia, para ter uma maior resiliência, você também pode optar por essa solução, a gente facilita essa conexão direta em mais de um ponto, para que você não fique sujeito a um problema de porta e ter, por exemplo, o seu sistema de mitigação comprometido.
Então a arquitetura é bem eficiente e flexível também, tanto do ponto de vista local, regional, global, e acho que o mais importante hoje, um dos principais diferenciais é poder realizar essa mitigação de forma efetiva, totalmente descentralizada, cada nó agindo de forma totalmente independente, para mitigar na origem do ataque, toda vez que a gente detectar algo que venha direcionado para a sua rede, sem a adição de latência.
A gente tem algumas perguntas aqui, vamos lá, acabou de chegar uma pergunta aqui também, bem, estou começando aqui de baixo para cima, está mais fácil, quais os tipos de planos e serviços são disponibilizados a essa funcionalidade?
Bem, o Magic Transit pode estar no modo On Demand ou no Always Online, então você vai utilizar só quando você sofre um ataque e você inicia essa mitigação, e uma vez que você nota que esse ataque parou, você remove a mitigação, então você só usa quando você precisa.
E a segunda é o Always Online, você vai utilizar o tempo todo, sempre sendo protegido pela Cloudflare e utilizando os recursos como o Fire, o gráfico, enfim, a análise e proteção de performance também que você pode utilizar.
E a precificação vai ser obviamente de acordo com a sua infraestrutura, sua necessidade, então é um preço bem customizado para cada cliente.
Outra é a diferença entre Magic Transit e Spectrum, bem, o Spectrum basicamente vai utilizar as redes de IP da Cloudflare, onde a Cloudflare vai fazer um proxy até você, então você vai precisar de uma conexão, que a Cloudflare vai receber essa conexão, vai fazer o proxy e vai entregar até você em diferentes portas, em diferentes protocolos, TCP, UDP.
O Magic Transit não, ele é um transporte, então aquele IP seu, a Cloudflare só está anunciando ele, recebe esse transit e entrega para você, então esse IP permanece com você e na Cloudflare, utilizando na verdade uma camada de transporte em BGP.
Por que eu não consigo trabalhar com o barra 32?
Porque infelizmente é as regras da BGP na Internet, então a gente só pode trabalhar, fazer um anúncio de no mínimo um barra 24.
Quando você está dentro da sua infraestrutura, você consegue fazer um roteamento interno utilizando o barra 32, para a Internet o mínimo é um barra 24.
Como o cliente sabe que ele precisa do Magic Transit?
Na verdade, se ele está sofrendo de ataque de DDoS e ele tem um ESN e tem um prefixo de no mínimo barra 24 IPv4, ele pode utilizar o Magic Transit para solucionar e resolver o problema dele de performance.
Então esse é um caso muito comum, principalmente em empresas que tem uma infraestrutura on-premise, que estão dentro de um data center, até mesmo tem o seu próprio data center, provedores de Internet, gamers, site de infraestrutura para games, fintechs, que ainda utilizam parte em ambiente on-premise, parte em ambiente na nuvem, eu vejo que qualquer cliente que tem um ESN, que tem o seu roteador anunciando um prefixo para a Internet, ele pode sim ser um cliente que está sofrendo, está suscetível a qualquer momento, sofrer um ataque de negação de serviço e isso pode causar bastante dano e bastante prejuízo, porque muitas vezes é só o servidor que cai, mas outras vezes o ataque de DDoS vem derrubando tudo que está no caminho, desde o teu firewall, stateful de borda, se derrubou seu firewall, automaticamente tudo que está atrás também cai, se o ataque for maior ainda pode derrubar o seu roteador, se não derrubar seu roteador pode estourar a capacidade de banda que você tem com isso, deixando todo o seu serviço, todos os seus clientes em formato de não serem atendidos, negando o serviço, então eu vejo que é bastante interessante contar com esse tipo de proteção e principalmente você não tem que ter nenhum tipo de gasto em mudança na sua infraestrutura, você vai terceirizar, vamos dizer assim, levar essa mitigação para a Cloudflare, você deixa tudo isso na nuvem.
Bem pessoal, eu acho que é isso, nós estamos chegando no final aqui, eu queria agradecer de verdade toda a presença de vocês, obrigado pelas perguntas, eu espero deixar a oportunidade, estamos à disposição para conversar com vocês, Jorge, Bruna.
Minha parte aqui também, obrigado Jason, Bruna, obrigado a todos pela oportunidade, permanecemos à disposição para qualquer questionamento adicional, um abraço e boa tarde.