Provedores de internet enfrentam nova onda de ataques DDoS

Falta de cuidados com equipamentos, serviços e a configuração de blocos de endereçamento IP tem colocado ISPs sob risco iminente de ataques distribuídos de negação de serviço Provedores de serviços de internet (ISPs, na sigla em inglês) estão sob risco iminente de ataques distribuídos de negação de serviço (DDoS) em larga escala e isso, em grande parte, se deve à falta de cuidados com equipamentos, serviços e a configuração de blocos de endereçamento IP. No ano passado, diversos provedores brasileiros passaram por momentos difíceis enfrentando ataques de DDoS em sua estrutura, fato que gerou diversas publicações em redes sociais, jornais e programas de TV. Recentemente, no final de fevereiro, uma nova onda de ataques voltou a assolar diversos ISPs, com vários relatos envolvendo provedores do Rio de Janeiro que, inclusive, têm se manifestado publicamente, informando os clientes que estão enfrentando sérios problemas no fornecimento dos serviços devido a esses ataques. A vítima não é necessariamente o alvo Apesar dos transtornos que causam às operações de provimento de internet, os ataques DDoS direcionados aos ISPs, ao contrário do que se imagina, não têm necessariamente como alvo os provedores. Na maioria dos casos, o objetivo dos grupos hackers é usar a infraestrutura dessas empresas para atacar os verdadeiros alvos, que geralmente são as grandes corporações multinacionais. Equipamentos com configurações inadequadas ou incorretas e descuidos humanos, normalmente são fatores que facilitam as explorações e o “recrutamento” dessa infraestrutura para o submundo do crime. Durante ataques DDoS em grande escala, as vítimas costumam ser acometidas por um alto volume de requisições, provenientes de milhares, às vezes, dezenas de milhares, de origens diferentes, geralmente espalhadas pelo mundo todo. Medidas e estratégias de mitigação que dependem do trabalho humano para a identificação das fontes dos ataques se tornam ineficazes diante do enorme poder de fogo dos hackers, já que provêm de milhares de origens maliciosas diferentes, as quais passam a chegar repentinamente na infraestrutura da vítima. Por isso o ideal é contar com a ajuda de um sistema Anti-DDoS. Ataques DDoS espalhados por 181 países No dia 12 do mês passado, cerca de duas semanas antes da nova onda de ataques DDoS ser divulgada publicamente, a Hacknet, rede neural artificial voltada à identificação de atividades hackers no mundo, identificou e mapeou uma grande rede com mais de 40 mil servidores, espalhados por 181 países, que estavam sendo usados para gerar ataques de DDoS. A notícia foi divulgada no site e nas redes sociais da empresa NetSensor, que é a mantenedora dessa rede neural, juntamente com um link para download da lista dos IPs que estavam sendo usados nos ataques, de maneira que os profissionais de segurança pudessem tomar medidas preventivas de proteção. A NetSensor trabalhou a lista de dispositivos que estavam sendo explorados, enriqueceu com mais dados e enviou comunicados privados para os endereços cadastrados como forma de contato para cada um dos blocos de endereçamentos IP. No Brasil foram mais de mil empresas envolvidas, o que resultou em mais de 1.600 e-mails de contato, nos quais a NetSensor emitiu o alerta, passou informação sobre o dispositivo e se colocou à disposição para maiores esclarecimentos. O resultado das notificações surpreendeu negativamente, com coisas como: O retorno mais triste foi o do responsável pelo bloco de um provedor, que apenas escreveu: “remova meu e-mail da lista por gentileza”. Poucas empresas adotam postura séria Houve também algumas empresas que retornaram de forma positiva ao alerta. Algumas encaminharam o caso para o responsável pelo dispositivo que estava usando o IP, outras pediram mais informações sobre o caso e, ainda, algumas agradeceram o alerta e disseram que iriam analisar o caso e tomar as medidas necessárias. Infelizmente o percentual de empresas com essa postura mais séria e profissional ficou por volta de 0,5%. Diante desse cenário, as empresas de modo geral precisam ter em mente que o crime cibernético se especializou muito nos últimos anos, se tornou altamente organizado, estruturado, inteligente e rentável. Portanto, para estar à altura de enfrentar e se defender desses cibercriminosos, é preciso desenvolver técnicas, conhecimento e lançar mão de recursos com inteligência que se equiparem ao nível dos nossos ofensores. Ou seja, buscar novas abordagens e tecnologias capazes de ajudar na defesa contra as novas ameaças, que, atualmente, não se consegue enfrentar de maneira eficaz. Além disso, os descasos, imperícias e negligências que se verifica em relação às redes, equipamentos e serviços, não podem mais ser admitidos. Só assim haverá chances de êxito para enfrentar as ameaças que nos rondam, vindas do submundo da internet. Fonte: https://www.cisoadvisor.com.br/provedores-de-internet-enfrentam-nova-onda-de-ataques-ddos/ Como proteger o seu provedor de ataques DDoS Assim como existem as ferramentas do atacante, também temos ferramentas e meios para proteger o provedor. O que precisamos é mitigar o ataque, que consiste em proteger o alvo dos ataques DDoS. A Made4it possui a ferramenta certa para você, o Made4Flow!Com o Made4Flow você consegue detectar os ataques e tomar uma ação para proteger o seu provedor. Conheça os benefícios do anti-DDoS para provedores de internet:

O que há de novo no Zabbix 6.4?

A nova versão se concentra na simplificação da configuração do Zabbix, permitindo que o Zabbix propague instantaneamente as alterações de configuração em ambientes grandes e distribuídos, além de simplificar os fluxos de trabalho de atualização do software. As organizações que utilizam LDAP ou SAML se beneficiarão dos novos recursos de provisionamento de usuários Just-in-time (JIT), permitindo que os administradores de TI propaguem os usuários do Zabbix utilizando mecanismos centralizados de autenticação de usuários. Esta atualização também contém vários templates e integrações para os fornecedores e provedores de nuvem mais populares, como Veeam, AWS, Azure, Cisco e muitos outros. Provisionamento de usuários Just-in-time (JIT) Crie e atualize automaticamente seus usuários do Zabbix com o novo recurso de provisionamento de usuários Just-in-time para LDAP e SAML: Eventos de causa e sintomas Para permitir uma visão geral dos problemas e opções de filtragem melhor, bem como identificar causa raiz de problemas, os eventos de problema agora podem ser marcados como eventos de causa ou sintoma: Propagação instantânea de alterações na configuração Sincronize instantaneamente suas alterações de configuração para Zabbix Agent e Proxy, executando em modos ativo ou passivo. Os proxies ativos e passivos do Zabbix agora podem capturar qualquer alteração de configuração feita em sua instância do Zabbix quase que instantaneamente: O agente ativo do Zabbix agora recebe uma cópia completa de configuração somente quando são feitas alterações de configuração entre os intervalos de sincronização de configuração: Atualização do Zabbix sem downtime Para melhorar os fluxos de atualização de componentes do Zabbix (especialmente para ambientes grandes), os proxies agora são retrocompatíveis dentro do mesmo ciclo de lançamento LTS: Melhorias de velocidade e desempenho na descoberta e coleta de dados SNMP em massa Uma nova maneira de coletar uma grande quantidade de métricas SNMP em massa com o mínimo impacto de desempenho no endpoint monitorado, utilizando solicitações GetBulk: Novo layout do menu O layout do menu do Zabbix foi redesenhado. O objetivo do novo layout do menu é fornecer acesso lógico e consistente aos principais recursos do Zabbix: Transmissão em tempo real de métricas e eventos HTTP Transmita em tempo real métricas e eventos do Zabbix para sistemas externos via HTTP: Versionamento de Template O versionamento de templates foi introduzido para melhorar e tornar mais fácil o gerenciamento de templates: Framework de desenvolvimento para criação de widgets do Zabbix Foram feitas várias mudanças de design com o objetivo de simplificar o fluxo de trabalho para a criação de widgets personalizados no Zabbix: Interfaces opcionais para verificações originadas pelo servidor. Uma interface de host não é mais necessária para tipos de itens relacionados a coletas iniciadas diretamente do Zabbix Server ou Zabbix Proxy: Configuração simplificada de tipos de mídia para vários provedores de serviço de e-mail O Zabbix 6.4 simplifica o fluxo de trabalho de configuração de um novo tipo de mídia de e-mail, permitindo que você selecione entre vários provedores de serviços de e-mail pré-configurados: Templates e integrações adicionais O Zabbix 6.4 chega com muitos templates novos para os provedores de nuvem e fornecedores mais populares: O Zabbix 6.4 introduz uma integração de webhook para o aplicativo de mensagens Line, permitindo que os eventos do Zabbix sejam encaminhados para o aplicativo Mudanças e melhorias adicionais A Made4it é uma empresa de tecnologia que se orgulha em ser parceiro certificado da Zabbix, uma das mais renomadas plataformas de monitoramento de redes do mundo. Como parceiros certificados, nossos profissionais estão altamente capacitados para fornecer soluções personalizadas e adequadas às necessidades específicas de cada cliente. Nossas soluções para monitoramento de rede são abrangentes e incluem desde a configuração básica até a implementação de soluções avançadas para redes de grande porte. Com a Made4it, você pode ter certeza de que seu sistema está sendo monitorado 24 horas por dia, 7 dias por semana, garantindo a segurança e o bom desempenho da sua rede. Além disso, temos uma equipe de suporte altamente qualificada que está sempre pronta para ajudar em caso de problemas ou dúvidas. Com a Made4it, você pode ter a tranquilidade de saber que está em boas mãos. Não perca mais tempo e conheça nossos serviços de monitoramento de rede. Entre em contato conosco hoje mesmo e saiba como podemos ajudar a sua empresa a alcançar um desempenho ainda melhor!

Túnel GRE + IPSec entre Cisco IOS e Huawei NE40

Neste post iremos discutir um cenário muito comum (e pouco documentado), que é utilizar um túnel GRE protegido com IPSec entre um roteador Cisco IOS ASR1002 e um Roteador Huawei NE40. A topologia deste exemplo é descrita abaixo. Ela foi mantida simples para que possamos discutir os detalhes do GRE+IPSEC, sem entrar nos demais pontos da rede. Nela temos o roteador Cisco com endereço IP público 198.51.100.2 e o roteador Huawei NE40 com o IP público 203.0.113.66. Ambos estão conectados à Internet, e com conectividade entre si. Precisamos estabelecer um túnel GRE entre os roteadores e protegê-lo através do IPSec no modo tunnel. O endereçamento do túnel é 172.31.31.0/30. Informações importantes sobre licença/módulos Veja com o fabricante dos seus equipamentos se não é necessário algum tipo de placa de serviços, ou licença. No caso dos equipamentos deste laboratório, o roteador NE40-M2K não precisou de módulo físico adicional, apenas a licença de IPSec. No roteador Cisco também não foi necessário licença, pois o IOS dele já estava no ADVIPSERVICES-K9 (que contém toda a base para o Ipsec). *informação útil*: se quiser rodar IKEv1, no roteador Huawei você precisa de um módulo de software para IKEv1 (que você consegue com o fornecedor Huawei). Configurações do Cisco IOS XE Vamos lá então configurar o roteador Cisco para estabelecer a VPN. Não vou entrar em detalhes das interfaces físicas, somente da VPN. No final do artigo tem um bloco com a conf pertinente delas. Configurações de fase 1, de acordo com a tabela acima: Tudo o que estiver acima é relativo à Fase 1. Então quando estiver diagnosticando problemas, e ele for desta fase, já sabe onde mudar 🙂. Agora, configurando a fase 2: Simples demais no Cisco! Vamos agora combinar as duas fases em um profile: Criando o túnel GRE e adicionando a proteção IPSec: Configurações do Huawei Vamos lá então configurar o roteador Huawei para estabelecer a VPN. Assim como do Cisco, não vou entrar em detalhes das interfaces físicas, somente da VPN. No final do artigo tem um bloco com a conf pertinente delas. A configuração no roteador Huawei é um pouco mais complexa, pois ele cria um túnel para o protocolo GRE, e um túnel para o IPSec. Além disso, queremos usar o mesmo IP para ambos os túneis, sendo necessária uma VRF. 😮 Criando o service instance para uso da VPN (aplicavel somente no NE40): Subindo a nova VRF (vpn-instance): Criando as duas interfaces Loopback com o mesmo IP (magias da VRF). A looback com o túnel IPSec ficará na tabela de roteamento pública, enquanto que a com o túnel GRE ficará na tabela VPNA. Agora sim chegamos ao IPSec.  A ACL de tráfego interessante define o tráfego que será protegido pelo IPSec. No caso então, teremos o tráfego GRE entre os IPs do site A e site B. Perceba que só faço a comunicação em um sentido – o sentido do roteador protegendo o tráfego dele).  A ACL acima pode ser lida assim: “Proteja os dados do protocolo GRE, vindo da VRF vpna entre a origem 203.0.113.66 e o destino 198.51.100.2” Partimos agora para criar a fase 1 (lembra que no Cisco já até começa com ela, muito mais simples). No meio dela tem algumas configurações de binding de VPN-Instance, por conta da VRF criada. Tudo o que estiver acima é relativo à Fase 1. Então quando estiver diagnosticando problemas, e ele for desta fase, já sabe onde mudar 🙂. Seguimos para a fase 2: Vamos agora combinar as duas fases em um profile: Criando os túneis GRE e IPSEC. Vamos lá para não confundir: Tunnel 900 – é um túnel GRE, operando por dentro da vpna. Tunnel 10 – é um túnel IPSec, operando na tabela global A ideia na Huawei é de que exista um túnel IPSec rodando por fora, e um segundo túnel GRE por dentro, um encapsulado no outro. Mas o engraçado é que o túnel GRE roda fora da VRF, e o ipsec dentro. Baguncinha, né? Então o tunnel900 que é o GRE (e que recebe os IPs do /30) usa um destino que vai por dentro da VPNA. E dentro da VPNA o destino é alcançado pelo túnel IPSec. Também observe que a policy de IPsec foi associada ao tunnel 10, utilizando o profile que foi criado. Por fim, e não menos importante, uma rota que tem uma certa complexidade em si mesma: dentro da instancia VPNA, eu digo que para chegar ao peer remoto, eu utilizo a interface de IPSec recém-criada, com o next-hop o próprio peer. E assim configuramos o roteador Huawei. Vamos ver se subiu agora. Validação do funcionamento No processo de validação do túnel, devemos sempre lembrar que cada fase e etapa depende do estabelecimento completo da outra, logo, não adianta querer ter conectividade se a fase 1 ainda não estabeleceu a comunicação. Em ambos os roteadores, vamos validar em sequência: Vamos lá para os testes. Checagem Cisco Validando a conectividade via ICMP ping Checando se o IKEv2 estabeleceu na Fase 1: Quando não aparecer nada na saída, ou ele não estiver em ready, quer dizer que alguns dos parâmetros da Fase 1 não casaram. Confira em ambos os lados se eles estão de acordo. Continuamos a validação na Fase 2: Na saída acima, vemos que os roteadores trocaram o contrato de “tráfego interessante”. Cada lado se comprometeu a proteger um sentido da comunicação GRE. Em sequência ainda na Fase 2, existem alguns contadores muito importantes que se referem a pacotes enviados/recebidos/encapsulados/encryptados/verificados. Ele fica na saída do comando “show crypto ipsec sa”.  Vamos ver eles. Quando estes contadores não estão incrementando, ou ainda incrementando falhas, é porque alguma configuração da Fase 2 não está casando.   Um bom exemplo seria somente o contador de encaps/encrypt ser incrementado, e enquanto o decaps/decrypt ficando zerado. Isto vai ser um problema da ACL de tráfego interessante que está divergindo em ambos os lados. Ou bloqueio da comunicação na rede de transporte ou ainda outros fatores que não vamos tratar aqui. Se

Lançamento Made4Flow v2

É com muito orgulho que anunciamos o lançamento da versão 2 do Made4Flow e Anti-DDoS. Trazendo diversas melhorias, essa versão traz novas funcionalidades e otimizações. Com um visual bem mais atrativo e opção de customização interativa das Dashboards, o Made4Flow v2 se destaca com sua interface muito mais polida e refinada, e também muito mais rápida e dinâmica comparado ao seu antecessor.

O que é TR-069 e como ele pode ajudar os provedores

TR-069 é um protocolo de gestão de dispositivos de rede. Ele permite que provedores de serviços de internet gerenciem e configurem dispositivos de rede, como roteadores e modems, remotamente.

Com TR-069, os provedores podem automatizar tarefas de configuração, monitoramento e manutenção dos dispositivos de rede, o que ajuda a garantir que os serviços de internet funcionem de maneira consistente e eficiente. Além disso, TR-069 também permite aos provedores coletar dados de desempenho dos dispositivos, o que os ajuda a identificar e resolver problemas de maneira rápida e eficiente.

Em resumo, TR-069 é uma ferramenta valiosa para provedores de serviços de internet, pois permite automatizar e gerenciar dispositivos de rede de forma remota, coletar dados de desempenho para identificar e resolver problemas rapidamente, automatizar atualizações de software e firmware e oferecer soluções de gerenciamento de rede para seus clientes, o que pode ajudar a reduzir custos, aumentar a eficiência operacional e aumentar a satisfação e a fidelidade dos clientes.

Made4Graph – Versão 2.2.7 (06/09/2022)

CDN Netflix, como requisitar?

Agora que você já sabe da importância e benefícios de um cache CDN local (caso ainda não saiba, confira: “O que é, pra que e porquê cache CDN?”Vamos apresentar do que precisamos e como adquirimos o cache CDN NETFLIX, também conhecido como OCA (Open Connect Appliance): Banda mínima! Visto que a Netflix vai precisar investir num hardware caro para você, precisa ser lucrativo a ela também! Hoje no Brasil é necessário que tenham pelo menos 5GB/s de tráfego com a Netflix. Fonte: https://openconnect.netflix.com/deploymentguide.pdf “Recebo diversos outros conteúdos juntos pelo trânsito, como posso ter certeza de quanto tráfego possuo com a Netflix?” Para podermos identificar com exatidão quanto de tráfego temos com a Netflix, precisamos de uma ferramenta que permita a análise minuciosa de origem e destino dos pacotes trafegando por ali. Para isso recomendamos o Made4Flow! Que nos permite visualizar o tráfego dos principais conteúdos. Também há diversos outros meios que possibilitam a visualização de ONDE aprendemos o tráfego: Um campo com mais detalhes sobre o consumo Netflix especificamente: Visualizamos o tráfego originado por servidores Cache CDN (OCA) ou pelo trânsito com a Netflix Quanto o tráfego Netflix representa do total da nossa rede. Por onde recebemos o tráfego com a Netflix e até mesmo se é usado por nós ou algum cliente ASN O Made4flow possui muitas outras aplicações pra dar a melhor visibilidade do seu tráfego. “ACHO que já possuo ou estou próximo do tráfego necessário com a Netflix, quando vão vir aqui em casa oferecer o serviço?” Infelizmente não vão, você que precisa ir atrás deles! E precisa ter certeza de que atende aos requisitos antes de solicitar, senão podem te colocar em espera por alguns meses até a próxima solicitação. Entre em contato com eles por meio do Appliance Request, através do link: https://openconnect.netflix.com/pt_br/deployment-guide/appliance-request/ Preencha o formulário atenção redobrada nos campos das imagens abaixo: Após isso, em alguns dias a Netflix dará sua resposta e mais detalhes sobre a entrega do Hardware, que costuma ser: Servidor de 1u (menor modelo) ou 2u (modelo maior) Com 2 ou 4 portas de 10GB/s(Ópticas) Você pode ver a descrição completa do hardware no link: https://openconnect.netflix.com/pt_br/appliances/ Após fazer o pedido lembre-se de cumprir os requisitos de banda, interconexão, energia e espaço no rack, que podem ser validados no link https://openconnect.zendesk.com/hc/en-us/articles/360034538352 Nos próximos posts teremos mais detalhes sobre como realizar as solicitações de demais caches CDNs e muito mais! Também nos acompanhe nas redes sociais para saber mais sobre a Made4it e o Made4Flow. Em caso de dúvidas sobre a requisição ou sobre o software made4flow entre em contato com nosso time.

Como solicitar o CDN da Microsoft? (MCC)

Olá pessoal, como estão? Nessa postagem vamos explicar um pouco sobre como solicitar o CDN da Microsoft mais conhecido como MCC (Microsoft Connected Caching). Requisitos/ Informações: Banda mínima: 2 Gbps (Seletiva) / 5 Gbps downloads por dispositivos com Win10. (Restritivo) Email: ispnode@microsoft.com Informações: https://peering.azurewebsites.net/Peering/Caching PeeringDB: http://as8075.peeringdb.com/ Vamos para um Overview sobre o MCC O Microsoft Connected Cache (MCC) é uma solução de armazenamento em cache somente de software que oferece conteúdo dentro de redes ISP. O MCC pode ser implementado em quantos servidores bare-metal ou VMs se for necessário e é gerenciado a partir de um portal na nuvem. Os serviços de nuvem da Microsoft lidam com o roteamento de dispositivos de consumidor para o servidor de cache para downloads de conteúdo. O Microsoft Connected Cache é uma solução híbrida (mistura de recursos locais e na nuvem) composta por uma máquina Linux compatível com Docker implementada em seu servidor e um portal de gerenciamento de nuvem. Microsoft escolheu o Azure IoT Edge por ser uma plataforma segura, e mesmo que seu cenário não esteja relacionado à IoT, o Azure IoT Edge nos trará a segurança de infraestrutura de implantação e gerenciamento. Para mais informações sobre o Azure IOT https://docs.microsoft.com/en-us/azure/iot-edge/about-iot-edge O Azure IoT Edge consiste em três componentes que a infraestrutura do Microsoft Connected Cache utilizará: 1. Uma interface baseada em nuvem que permite instalação remota segura, monitoramento e gerenciamento de nós do Microsoft Connected Cache. 2. Um tempo de execução que gerencia com segurança os módulos implantados em cada dispositivo. 3. Módulos/contêineres que executam a funcionalidade Microsoft Connected Cache em seu dispositivo. O que é o MCC? O servidor de caching da Microsoft usa os serviços de IOT Edge da Azure para entregar conteúdo a clientes ISP finais. Ele funciona como um servidor cache dentro da rede do ISP, servindo aos IPs especificados nos anúncios da sessão BGP entre o Servidor e o Roteador. O que vem no conteúdo? A princípio o que viria do CDN deles como atualizações do Windows, Office, jogos do XBOX e arquivos dos sites da Microsoft. Atualmente como é uma implantação nova, nem tudo da Microsoft está disponível através do MCC. Ele é igual o GGC da Google ou OCA da Netflix? Sim, se parece muito, mas a grande diferença dele é que a Microsoft não envia um hardware específico para sua rede, você deve fornecer o hardware, instalar o sistema operacional e fazer a instalação de todos os pacotes necessários para o MCC rodar. Os requisitos são: Devem ser usadas interfaces de rede de pelo menos 10Gbits para entrega do Conteúdo através do Servidor. A Microsoft recomenda fortemente que sejam discos SSD instalados no Servidor. Como funciona o MCC? Segundo o documento da Microsoft, que descreve ele, funciona da seguinte forma: 1. O Portal de Gerenciamento do Azure usado para criar e gerenciar nós de Cache Conectado da Microsoft. 2. O cache do Microsoft Connected Cache implementado e provisionado no servidor. 3. O Portal de Gerenciamento do Azure usado para configurar o Microsoft Delivery Optimization Services para rotear tráfego para o servidor do Microsoft Connected Cache fornecendo duas informações: A – O endereço IPv4 público do servidor que hospeda o Microsoft Connected Cache. b. Os blocos CIDR que representam o espaço de endereço IP do cliente, que deve ser roteado para o node do Microsoft Connected Cache. 4. Os dispositivos de usuário final da Microsoft se conectam periodicamente aos Serviços de Otimização de Entrega da Microsoft, e os serviços correspondem ao endereço IP do cliente com o endereço IP do node de Cache Conectado da Microsoft correspondente. 5. Os dispositivos de usuário final da Microsoft fazem as solicitações de intervalo de conteúdo do node do Microsoft Connected Cache. 6. O node de Cache Conectado da Microsoft extrai o conteúdo da CDN, propaga seu cache local armazenado no disco e entrega o conteúdo ao cliente. 7. As solicitações subsequentes de dispositivos de usuário final para conteúdo agora virão do cache. 8. Se o node  do Microsoft Connected Cache não estiver disponível, o cliente extrairá o conteúdo da CDN para garantir um serviço ininterrupto para seus assinantes. Qual o processo para solicitar um MCC Solicitar acesso ao programa, preenchendo o formulário descrito na página Link: https://peering.azurewebsites.net/peering/Caching Abaixo está o resumo das etapas necessárias para implantar o Cache Conectado da Microsoft em seu servidor. 1. Forneça à Microsoft a assinatura do Azure que você usará para o Microsoft Connected Cache 2. Crie o recurso de cache conectado da Microsoft no Azure 3. Crie um node de Cache Conectado da Microsoft a. Informações de aprovação do espaço IP 4. Edite as informações do node de cache 5. Configure um servidor com Ubuntu 20.04 ou uma VM Ubuntu em execução no Windows Server 2019 6. Instale o Microsoft Connected Cache em um servidor ou VM 7. Verifique o funcionamento adequado do Microsoft Connected Cache Server 8. Visualize o Relatório de Resumo do Cache Conectado da Microsoft 9. Problemas comuns. Para qualquer dúvida sobre estas instruções, entre em contato com: msconnectedcache@microsoft.com O portal de gerenciamento do Microsoft Connected Cache Azure é usado para criar e gerenciar nós do Microsoft Connected Cache. Uma ID de Assinatura do Azure é usada para conceder acesso à visualização e para criar o recurso de Cache Conectado da Microsoft nos nodes do Azure e Cache. A instalação: A instalação está muito bem descrita no manual, mas resumidamente: Instalar o servidor ubuntu Criar e registrar uma conta no azure (e também uma subscription) Criar um host no portal da azure, informando os dados do servidor (IP, nome, redes, etc) Baixar o instalador do portal Executar os comandos de instalacao que o portal vai oferecer Ir respondendo as perguntas/logins/acessos durante a instalacao Reportar ao time do MCC Ubuntu 20 com 32G de RAM, 24 vCPUs, 3 discos (Um sistema de 500G e 2 discos de 2T para dados) Exemplo de email recebido com a aprovação do MCC Este email foi recebido pela equipe ao ser aprovado o MCC. Nele constam as instruções para dar seguimento a

Como automatizar processo de provisionamento de clientes!

O provisionamento de clientes é uma tarefa diária de um provedor de internet, tanto na instalação de novos clientes, quanto em manutenções. Neste processo, além do provedor precisar sempre disponibilizar um técnico que faça além da instalação física, a configuração lógica de inserir a VLAN, usuário e senha PPPoE do cliente em sua CPE, temos alguns problemas conhecidos, como: – Demanda de tempo para configuração manual – Abertura para falhas humanas: – Erro de credenciais PPPoE – Erro de Vlan – Erros de usuário e senha – Não cumprir o padrão determinado pelo provedor de configuração – Perda de configurações em resets de CPEs pelos clientes.  Diria que esse é o rei dos tickets do suporte de um provedor, onde muitas vezes o cliente em busca de resolver algum problema qualquer em sua casa, reseta o equipamento e não consegue configurar novamente. Neste caso, se o suporte via telefone não for capaz de auxiliar o cliente na configuração, o provedor irá precisar disponibilizar um técnico presencial para o serviço. E se você já leu até aqui, pode estar se perguntando se realmente é possível resolver este problema de forma automática. E a resposta é sim! E inclusive temos uma gama de cenários e possibilidades que nos permitem além de automatizar o processo de provisionamento, torná-lo auto-reconfigurável, para o famoso caso dos resets. Então sem mais delongas, vamos colocar em jogo alguns cenários e suas possíveis implementações: – Cenário exemplo de implementação: OLT’s e ONT’s do mesmo vendor. ONTs são modo router Autenticação PPPoE Nos casos de equipamentos da rede de acesso que são da mesma fabricante, temos a vantagem deles “falarem a mesma língua”, e isso nos ajuda pois na grande maioria das vezes, conseguimos obter a vantagem de conseguir automatizar a entrega e a permanência das configurações nos equipamentos. Basicamente na OLT, configuramos os parâmetros que serão enviados por OMCI, contendo informações como usuário e senha PPPOE, ativação da WAN, ativação do NAT. Vamos a um exemplo prático de configurações para realizar esse processo: As configurações que serão descritas neste exemplo se aplicam a: – OLT’s Huawei das séries MA56xx e MA58xx. – ONT’s Huawei modo Router. OBS: Note que alguns comandos estão dentro de [chaves] indicando o nome de cada parâmetro, e deve ser alterado para ficar de acordo com o cenário de aplicação. Criação de DBA Profile, line e service profile será normal, de acordo com cada cenário. Recomendamos um profile para cada VLAN, sendo que também recomendamos uma VLAN por PON na OLT. Liberando configuração em modo OMCI: Para ser possível a entrega das configurações para a ONU, precisamos liberar o método de configuração OMCI. Para ativação do NAT na WAN: Para podermos subir a ONT com o NAT ativo, criamos um WAN profile. Adicionando a ONT com user e senha PPPoE: O segredo da implementação está nesta parte, e o comando ont ipconfig será o responsável por entregar o PPPoE para a CPE. interface gpon [FRAME]/[SLOT]ont add  [PON] [ONT-ID] sn-auth [SERIAL-NUMBER] omci ont-lineprofile-id [ID] ont-srvprofile-id [ID] desc [DESCRICAO]ont ipconfig [PON] [ONT-ID] pppoe vlan [VLAN] priority 5 user-account username [USER-PPPOE] password [SENHA-PPPOE] Criando WAN: Entrega da Vlan nas portas LAN: Para que dispositivos ethernet que estejam a frente da CPE entendam a Vlan que estamos entregando nas portas, assumimos o modo de vlan nativa: Ativando portas em modo route: Definimos o modo route para as portas para que elas fiquem ativadas para roteamento IP e entrega de DHCP em dispositivos que se conectarem atrás dela. OBS: tanto na entrega da Vlan quanto na ativação do modo route, temos exemplo feito para ONT’s com 4 portas, mas existem casos que isso muda de acordo com a quantidade de portas disponíveis na ONT. Seguindo os passos acima no provisionamento da sua ONT modo route, ela já deverá funcionar. – Como automatizar isso com meu sistema ERP ?  O processo acima pode ser realizado manualmente, mas para que se torne mais efetivo, podemos utilizar de scripts de provisionamento do sistema ERP para realizar o processo de provisionamento. Abaixo temos um modelo de script que pode ser utilizado, note que cada variável é separada com #, e isso deve ser verificado com cada sistema, para que eles passem a variável ou ajudem no desenvolvimento do script. interface gpon #subrack#/#slot# ont add #pon# sn-auth #onu_mac# omci ont-lineprofile-id #vlan# ont-srvprofile-id #vlan# desc #nome# ont ipconfig #pon# #onu_numero# pppoe vlan #vlan# priority 5 user-account username #user# password #senha# ont internet-config #pon# #onu_numero# ip-index 0 ont wan-config #pon# #onu_numero# ip-index 0 profile-id [ID-PROFILE-WAN] ont port native-vlan #pon# #onu_numero# eth 1 vlan #vlan# priority ont port route #pon# #onu_numero# eth 1 enable ont port native-vlan #pon# #onu_numero# eth 2 vlan #vlan# priority ont port route #pon# #onu_numero# eth 2 enable ont port native-vlan #pon# #onu_numero# eth 3 vlan #vlan# priority ont port route #pon# #onu_numero# eth 3 enable – Extras: Existem também outras coisas que podemos entregar assim como as credenciais PPPoE, como dados de SIP, ou ativação automática do TR-069. E falando em TR-069, esse modo de configuração trabalha muito bem com ele, já que garante a comunicação IP, e o TR-069 por sua vez garante o management completo da CPE, como wi-fi, senhas, dados de sinal, etc.  Quer saber mais sobre o TR-069 ? Leia nosso artigo FAQ:  Isso serve para outros vendors de OLT’s? O processo descrito acima foi testado e homologado na OLT Huawei, alguns outros vendors possuem suporte a esse tipo de configuração porém para cada um, o modo de configuração é diferente. Isso serve para todos os vendors de ONT’s? Não, o processo acima é homologado apenas em cenários de Huawei com Huawei. Esse artigo foi escrito pelo consultor da Made4it Rafael Henrique. Caso tenha alguma dúvida em relação ao artigo ou como realizar essa configuração em sua rede, fale com nosso time

Nova versão Made4Flow

Mais uma versão do software made4flow, tivemos algumas alterações nessa atualização, estamos  sempre trazendo as novidades de acordo com as principais necessidades dos nossos clientes. Vamos conferir a atualização desta versão?  Versão 1.3.4 (26/07/2022) Adicionado Adicionada nova tela para visualizar os ataques amortecidos pelo Anti-DDoS Foi adicionada esta nova tela que mostra os ataques registrados, mas que não viraram anomalias, assim como mostra o número de ataques por período, detalhes de tráfego e por fim os pacotes capturados no determinado ataque. Adicionado logs de ações no Anti-DDoS Um cliente havia reportado que a rota expirou sozinha e não foi possível verificar o que realmente aconteceu visto que não tínhamos logs do sistema. Com a adição de logs é possível ter uma ideia das ações realizadas no sistema para verificar se foi algum bug ou ação de alguém. Ajustado Corrigido problema de perda dos dados brutos dos roteadores Ajustado a ordenação de dados nos dados brutos Ajustado o filtro nos dados brutos para a opção outros Corrigido a responsividade dos botões de ação no Anti-DDoS Corrigido a agregação de dados para gráficos gerados com períodos maior que 2 meses Corrigida expiração indevida de rota BGP caso haja uma outra com o mesmo target ativo no momento no Anti-DDoS Ajustado as permissões de visualização do usuário read-only no Anti-DDoS Corrigido a exclusão de peers BGP no Anti-DDoS Corrigido a perda de rotas BGP no reinício do Anti-DDoS Ajustado o limite de prefixos por threshold no Anti-DDoS Corrigido gráfico de top ASNs de destino do AS Globo Essas foram as atualizações da última sprint, você pode conferir todas as versões e atualizações anteriores na Wiki da Made4it. Para falar com nosso time comercial entre em contato 43 9 8485-4013 ou contato@made4it.com.br