DHCP Option 43 para auto-configuração de ACS
Hoje vamos explorar o famoso DHCP Option 43, usado principalmente na autoconfiguração de dispositivos como Access Points, Switches, Telefones IP, CPEs, dispositivos IoT e outros através do TR-069. Também vamos mostrar um exemplo de configuração utilizando o DHCP Server de um roteador Mikrotik entregando parâmetros via DHCP Option43 e permitindo a autoconfiguração de serviços no processo de atribuir endereço de IP ao dispositivo. Isso nos possibilita, por exemplo, sinalizar um controlador externo ao dispositivo, automaticamente, mesmo que o equipamento tenha passado por um factory-reset. A RFC 2132 “DHCP Options and BOOTP Vendor Extensions” [1] trata de diversos tipos de informações que podem ser enviadas através do protocolo DHCP como por exemplo o DNS, Máscara de sub-rede, endereço do gateway (router), atributos específicos de vendor e muitos outros mais. O Option 43 é definido nesta RFC como “Vendor Specific Information” e é usado para que os clientes e servidores DHCP troquem informações específicas entre si. A RFC não define que valores eu posso enviar, e nem que informações são estas e muito menos o tipo de dados. Ele apenas descreve a estrutura, que deve ser: Code Len Vendor specific information 43 n i1 i2 … Code 1 Len 1 Data 1 Code 2 Len 2 Data 2 Code n Len n Data n T1 n1 d1 T2 n2 T2 … … … Com esta estrutura, cada fabricante ou organização, pode modelar os dados como for mais conveniente para seu uso. Por exemplo, para access-points poderem ser configurados os endereços IP dos controladores Wifi permitindo seu “join” no controlador centralizado, para Telefones IP entregando o IP ou URL do servidor de telefonia e para os roteadores que suportem TR-069 poderem ser configurados com a URL do ACS. E tudo isso automaticamente! O foco deste artigo será mostrar o uso do option 43 junto ao TR-069, enviando a URL do servidor ACS para a CPE através do servidor DHCP. Isso nos permite que o roteador mesmo resetado e sem um “template” de configuração, aprenda via DHCP a URL do servidor ACS junto do usuário e senha, dados necessários para se integrar ao ACS e permitir o TR-069 aplicar configurações na CPE automaticamente. Mas antes de continuar, vou deixar alguns links de outros exemplos de caso de uso do option 43. Configure DHCP OPTION 43 for Lightweight Access Points: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/97066-dhcp-option-43-00.html VLAN ID Discovery over DHCP: https://wiki.unify.com/wiki/VLAN_ID_Discovery_over_DHCP Use DHCP Option 43 for Unifi Accesspoint Provisioning:https://niksec.com/use-dhcp-option-43-for-unifi-accesspoint-provisioning/ Como o DHCP foi parar no TR-069 Se não sabe o que é o ACS, consulte nosso outro artigo . O DHCP foi inserido como uma das formas de onboarding do ACS. O onboarding é o processo em que a CPE/roteador é configurada com um servidor ACS.Existem três formas de se fazer o processo de onboarding das CPEs para um servidor ACS, segundo a especificação TR-069 do Broadband Forum [2]: O objetivo final de qualquer um dos três é um só: ter a URL do servidor ACS configurada na CPE, para que a mesma possa ser gerenciada através do protocolo TR-069. Processo de solicitação do DHCP Option 43 O BroadBand Forum define alguns passos para que a CPE possa conseguir a URL do ACS através do DHCP. A figura abaixo mostra os passos, e já vamos falar de cada um deles. Passo a passo da comunicação: Na especificação do TR-069 também estão definidos outros campos/protocolos que podem ser utilizados para o mesmo fim: DHCPv4 Option 125, DHCPv6 Option 17. Também citam diversas regras de descoberta pós-reset e como lidar com problemas de conectividade com o ACS. Mas estão fora do escopo deste artigo. Exemplo de uma transação DHCP com Option 43 – Capturas de pacotes Exemplo de configuração no Mikrotik Aqui, veremos como configurar um roteador Mikrotik para, via DHCP-Server, entregar parâmetros de autoconfiguração de “clientes” via o Option43. A configuração será baseada na topologia abaixo, semelhante ao utilizado em nossos testes com uma CPE Nokia. Primeiro é necessário ter a configuração do DHCP Server, depois vincular as configurações de DHCP Option43. Utilizamos a rede 192.168.2.0/24 e a Vlan 881, conforme nosso exemplo: Você deve estar se perguntando, de onde aquele valor da opção 43 saiu? Existe sim uma regra para ser criada, e você pode conferir como gerar para seu servidor ACS no seguinte artigo. Conclusão Neste artigo, abordamos como utilizar o atributo “Option43” do DHCP para autoconfiguração de um servidor ACS em CPEs e dispositivos diversos. Abordamos o seu funcionamento e como ele pode ser utilizado para automação de entrega de configurações específicas a dispositivos utilizando um protocolo tão comum como o DHCP. Conhecer as capacidades, atributos e opções que o fabricante e o modelo de equipamento suportam nos ajuda a automatizar diversas configurações, incluindo mas não se restringindo ao gerenciamento de uma CPE, Nokia, via o TR-069. Referências:[1] RFC 2132, DHCP Options and BOOTP Vendor Extensions, https://www.ietf.org/rfc/rfc2132.txt [2] TR-069, CPE WAN Management Protocol, https://www.broadband-forum.org/pdfs/tr-069-1-6-1.pdf
VMware x Proxmox – Qual escolher?
Introdução Quando falamos de servidores hoje em dia, automaticamente já associamos à virtualização. Foi-se o tempo em que usávamos servidores bare-metal para executar apenas uma aplicação. Com a facilidade da virtualização e o melhor aproveitamento dos recursos do servidor, tornou-se quase obrigatório utilizar o seu servidor com algum software de virtualização. Atualmente, dois grandes nomes têm liderado quando o assunto é virtualização: VMware e Proxmox. Ainda mais depois das notícias referentes à venda do VMware para a Broadcom, esse assunto começou a ficar ainda mais em alta. E a dúvida que percorre a maioria das pessoas é: VMware ou Proxmox? Qual virtualizador escolher? Qual é o “melhor”? Ao longo deste post, iremos realizar algumas comparações entre os dois virtualizadores para que você possa decidir qual deles melhor atende à sua necessidade e, claro, também conhecer as principais funcionalidades de cada um! Visão geral dos serviços Proxmox é um virtualizador open-source atualizado e mantido pela Proxmox. Ele é baseado em Debian e utiliza como virtualizador o KVM/QEMU e LXC para containers. Ele se destaca por ser gratuito e ter uma grande variedade de funcionalidades, de forma que o limite do quanto você pode crescer e evoluir está diretamente ligado ao seu conhecimento com a ferramenta. O Proxmox também se destaca muito na questão de compatibilidade com hardwares mais antigos, pois está diretamente ligado ao kernel do Linux que está sendo utilizado. VMware é um virtualizador de código proprietário e é atualizado e mantido recentemente pela Broadcom. Atualmente, deixou de ser gratuito, passando a aderir somente à forma de licenciamento para a utilização dele. Utiliza como virtualizador tecnologias proprietárias para virtualização de servidores, e é inegável a sua alta performance e estabilidade. Ele se destaca por sua interface simples e funcionalidades que agregam muito em cenários grandes. A parte de compatibilidade do VMware depende da versão em que ele está, e quanto mais nova a versão, menos compatibilidade com hardwares considerados antigos. Facilidade de uso Proxmox, em um primeiro momento, pode parecer confuso e difícil, ainda mais porque algumas configurações precisam de integração com o CLI. Porém, depois que você se habitua com a sua interface e as funções que você precisa, tudo fica mais simples. Ele também possui uma ótima documentação que aborda todas as funções disponíveis. Também conta com um suporte pago que fica a escolha do usuário se deseja adquirir ou não, e possui uma boa comunidade ativa. VMware possui uma interface amigável e mais objetiva. Com alguns poucos cliques, você já consegue subir uma VM e deixá-la funcional. Por outro lado, caso queira ter acesso a outras funcionalidades, vai precisar adquirir uma nova licença e/ou configurar algum outro software (ex: VEEAM, vCenter). Possui uma ótima documentação e vários KBs (Base de Conhecimento o/ knowledge base) explicando diversos problemas que podem acontecer. Performance Ambos os serviços têm uma boa performance. O VMware se destaca por executar o seu SO em memória RAM, permitindo assim uma melhor navegação na sua interface. Fora isso, ambos estão bem próximos na questão de performance em cenários mistos, utilizando VMs Linux e Windows e diferentes tipos de storage e armazenamentos. Escalabilidade Ambos os virtualizadores permitem aumentar os recursos (CPU/MEM/DISCO) das suas VMs sem problemas, e se preciso, aumentar até recursos internos como adicionar mais espaço em algum datastore ou disco de suas VMs. Agora, caso você adquira mais um servidor e queira aumentar a sua infraestrutura de servidores, o Proxmox lida melhor com a adição de um novo servidor em seu sistema. Enquanto no VMware esse servidor ficaria isolado e seria preciso configurar um novo serviço (vCenter) para unir os servidores sobre sua gerência, no Proxmox basta criar um Cluster e cadastrar o novo servidor no cluster (literalmente só essas duas configurações). Recursos e funcionalidades Ambos os serviços contam com recursos e funcionalidades parecidas. No caso do VMware, o acesso a elas vai depender da licença que você possui, enquanto no Proxmox vai depender se a versão em que você está possui ou não suporte a ela. Exemplos de algumas funcionalidades que possuem em ambos: Custos Fizemos uma simulação para um servidor com 1 CPU (Socket) e esses foram os custos Para o Proxmox não é necessário licença para uso, somente para Suporte direto do fabricante caso queira. Estudos de caso e exemplos práticos Vamos supor alguns cenários e entender onde que é interessante implementar VMware ou Proxmox. PS: Irei puxar sardinha para cenários On-premises de provedores de internet! Cenário 1: Possuo um servidor usado antes de 2015 e gostaria de adicionar ele em produção para virtualizar 5 VMs não críticas. Cenário VMware: Cenário Proxmox: Ou seja, em ambos os cenários você vai conseguir implementar esse seu cenário. Claro que no caso do VMware, além do preço da licença, você tem que se atentar com o modelo do seu servidor e principalmente do ano dele. Servidores muito antigos não são suportados pelas versões mais recentes do VMware, e você terá que fazer mais investimentos para suportar o cenário de backup caso tenha mais que 10 VMs em seu cenário. Upgrade Cenário 1: Vi que a virtualização funcionou muito bem, e agora quero adicionar mais VMs, porém agora vão ter VMs críticas, e para executar essas VMs fiz um upgrade e adquiri um novo servidor. Cenário VMware: Cenário Proxmox: Conclusão Enfim, vimos que o Proxmox e VMware são bem parecidos e conseguem entregar o mesmo resultado, desde que você atente a alguns requisitos! Sobre qual é melhor, tudo depende do tamanho da sua infraestrutura e criticidade. A primeira coisa que temos que levar em conta é o investimento que irei realizar em licenças. Caso opte por utilizar VMware, veja se esse investimento não poderia ser mais útil em alguma outra área (por exemplo, realizar o upgrade de alguma peça do meu servidor interno). A minha recomendação é a seguinte: se a sua infraestrutura está 100%, com servidores novos e não precisa de upgrade, e você tem a possibilidade de adquirir as licenças, vá de VMware, pois ele vai te entregar o que tem de
Atualizações – Made4Flow, Made4Graph e Made4OLT – Fevereiro 2024
Made4Flow – Versão 2.6.2 Alterações: Correções: Made4Graph – Versão 2.4.3 Adições: Correções: Made4OLT – Versão 1.3.0 [Beta] Adições: 1 – Adicionada possibilidade de reiniciar ONU configurada. 2 – Adicionado quantidade máxima de OLTs por licença. 3 – Adicionada opção de Save manual e Autosave de OLTs. 4 – Adicionada implementação de comandos Telnet 5 – Adicionado terminal via Telnet na OLT Alterações: 1 – Templates podem receber Board, slot e port como parâmetros. 2 – DBA profile selecionável de 1 a 5. 3 – Corrigido bug, Vlans só podem ser criadas dentro do range de 1 a 4094. Correções: 1 – Corrigido bug ao enviar nova licença.2 – Corrigido bug, agora campo de Vlans só aceita number.
Como configurar FlowSpec em Roteadores Juniper
Visão Geral: O BGP FlowSpec (Border Gateway Protocol Flow Specification) é uma extensão do protocolo BGP usado para definir regras de filtragem de tráfego em roteadores ou simplificando podendo gerar regras de firewall nos roteadores a partir de um anúncio BGP. Ao contrário do BGP convencional, que roteia com base em informações de IPv4/IPv6 e prefixo, o BGP FlowSpec permite que os administradores de rede especifiquem critérios mais granulares para o encaminhamento de pacotes, incluindo informações sobre camada 4 (portas TCP/UDP) e até mesmo padrões de pacotes. Para saber mais sobre o BGP Flowspec acesse nosso artigo falando sobre o que é BGP Flowspec através deste link. Funcionamento: O BGP FlowSpec funciona adicionando novos tipos de atributos ao BGP, permitindo aos administradores de rede especificarem regras de filtragem detalhadas. Essas regras podem incluir critérios como: As seguintes ações podem ser tomadas com o BGP FlowSpec: Quando essas regras são propagadas através da rede BGP, os roteadores podem usar essas informações para filtrar ou manipular o tráfego de acordo com as políticas definidas. Funcionamento – Mais Detalhes: No contexto do BGP FlowSpec, as ações são especificadas como parte das regras de filtro. Cada regra de filtro contém três partes principais: As ações no BGP FlowSpec são codificadas usando comunidades BGP. Cada ação é mapeada para uma comunidade BGP específica: Ao criar uma regra BGP FlowSpec, você especifica os campos de correspondência, a ação desejada e, opcionalmente, campos de protocolo. Esta regra é então codificada como uma comunidade BGP e incluída em uma mensagem de atualização BGP que é enviada para os roteadores vizinhos. Os roteadores que recebem essa regra aplicam as ações especificadas aos pacotes que correspondem aos critérios de correspondência. Por favor, note que as comunidades BGP específicas para cada ação podem variar de acordo com a implementação do BGP FlowSpec em seu equipamento de rede. Recomendo consultar a documentação do seu equipamento para obter informações detalhadas sobre as comunidades BGP associadas a cada ação no BGP FlowSpec. Casos de Uso: 1. **Mitigação de Ataques DDoS**: O BGP FlowSpec pode ser utilizado para bloquear ou redirecionar tráfego malicioso durante ataques de negação de serviço distribuídos (DDoS). As regras precisas podem ser aplicadas para filtrar o tráfego indesejado e manter os serviços online. 2. **Políticas de QoS (Qualidade de Serviço)**: Administradores de rede podem utilizar o BGP FlowSpec para garantir a qualidade de serviço, priorizando determinados tipos de tráfego com base em portas ou protocolos específicos. 3. **Implementação de Políticas de Segurança**: O BGP FlowSpec pode ser usado para implementar políticas de segurança granulares, bloqueando tráfego associado a malware ou atividades suspeitas. Exemplos de Configuração: A configuração do BGP FlowSpec pode variar de acordo com o equipamento de rede utilizado. Este exemplo explora como projetar uma solução de mitigação de DDoS em que um provedor de serviços permite que seus clientes anunciem rotas BGP FlowSpec para ele. Também discute algumas das melhores práticas que devem ser consideradas antes de implementar este tipo de solução e, finalmente, alguns dos comandos do Junos disponíveis para o ajudar a verificar se a solução de Flow-spec está funcionando corretamente. Cenário de Topologia para o exemplo: Vamos começar dando uma olhada em como nossa solução será configurada: Conforme podemos ver na topologia acima, existe a BORDA que é um equipamento Juniper que tem a função de Roteador de BGP da rede, o Made4Flow que é o software que irá analisar os fluxos e gerar regras de BGP FlowSpec dinamicamente e anunciar via BGP para o Roteador BGP chamado BORDA. Neste cenário, o ataque exemplo é um ataque de amplificação de DNS. Isto significa que a rede está recebendo um grande volume de pacotes UDP porta 53 de que na realidade não necessitaria para o funcionamento normal do ISP. O ataque enche o circuito entre o ISP e as operadoras e, efetivamente, deixa a rede inoperante. Quando o atacante decide lançar o ataque, o ISP pode utilizar o Made4Flow para gerar uma rota BGP FlowSpec apenas para pacotes UDP porta 53 e anunciá-la para o Roteador de BGP BORDA, que pode transformar essa rota em um filtro de firewall em suas interfaces de comunicação com as Operadoras. E então isso bloqueia os pacotes de amplificação de DNS na borda da rede do ISP e também na operadora (se a operadora suportar sessões FlowSpec), mas permite que o tráfego legítimo continue a chegar. Primeiramente vamos analisar as configurações da sessão BGP FlowSpec no Roteador de BGP BORDA com o Made4Flow, assumindo que o Roteador já está configurado para o encaminhamento unicast BGP normal (Sessão BGP normal para anúncio de Rotas de Blackhole ou Mitigação/Scrubbing Center). Para realizar a configuração de uma sessão BGP FlowSpec em equipamentos Juniper, utilizamos os seguintes comandos: Boas Práticas: Existem melhores práticas para proteger esta solução. Tanto as rotas BGP FlowSpec como os filtros de firewall resultantes que criam são recursos finitos no router. Sendo assim, o Roteador de BGP BORDA pode efetuar a filtragem de rotas de entrada para garantir que não receba rotas demais fora do esperado ou rotas erradas. Prefix Limit: Assim, a primeira coisa a fazer é definir um limite de prefixo para as rotas BGP FlowSpec. Poderia simplesmente definir um único limite de prefixo para as rotas inet unicast e inet flow, no entanto, este exemplo vai definir um limite separado para as rotas inet flow. Para que o Made4Flow apenas possa enviar dez rotas de BGP Flowspec de cada vez, vamos definir o limite de prefixos para 10 (esta configuração deve ser ajustada de acordo com cada cenário): Route Policy : A próxima coisa a fazer é aplicar uma política de rota de entrada. Essa política limitará o roteador a receber prefixos que são do próprio ISP com prefixos /24 até /32, que são os anunciados pelo Made4Flow. Vamos também adicionar uma Community 64496:86 para que possa identificar as rotas como sendo rotas BGP FlowSpec. Para todas as outras rotas, pode simplesmente filtrá-las com base na atribuição de rotas do cliente: 1. Crie a definição da
Como migrar Vmware para Proxmox?
Recentemente, a nova proprietária da VMware fez uma declaração que ecoou em toda a comunidade: não haverá mais licenças gratuitas da VMware, e os custos das licenças novas aumentaram em 40%. Essa mudança drástica nas políticas de licenciamento levou muitos profissionais de TI e empresas a reavaliar suas estratégias de virtualização. Como resultado, soluções alternativas estão emergindo, com destaque para o Proxmox, o virtualizador Open Source mais amplamente utilizado em todo o mundo. O Proxmox oferece uma gama completa de recursos comparáveis aos oferecidos pela VMware, incluindo funcionalidades como cluster, replicação, alta disponibilidade (H.A.) e a garantia de alta disponibilidade, tudo isso sem os altos custos de licenciamento associados à plataforma VMware. Com a capacidade de realizar todas essas operações essenciais de virtualização sem comprometer a qualidade ou a confiabilidade. Se você já utiliza VMware e está considerando migrar para o Proxmox, elaboramos um artigo detalhado que demonstra o processo de migração de VMs diretamente da VMware para o Proxmox. Este guia prático oferece instruções passo a passo para garantir uma transição suave e eficiente, permitindo que você aproveite ao máximo os recursos e benefícios do Proxmox em seu ambiente de virtualização. Processo de migração do ProxMox Export O primeiro passo é realizar a instalação do ovftools através desse link após isso você pode enviar via SCP para o seu servidor ProxMox utilizando o comando: Logo após isso em seu servidor Proxmox, dê a permissão de execução para o arquivo enviado e logo em seguida execute ele: Pronto, o OVFtools já está instalado! Com esse binário iremos avançar duas etapas, o export e a conversão, o OVFTOOLS irá se conectar remotamente ao seu servidor VMware ESXi, e através da linha de comando você irá informar qual a VM que deseja exportar, logo em seguida o ovftools já irá baixar essa VM e logo em seguida converter para o padrão do Proxmox, para realizar essa etapa no servidor onde está instalado o OVFTOOLS execute o comando: Após finalizar o Export, vamos importar essa VM utilizando o comando: E após o IMPORT finalizar a VM já vai estar configurada em seu ProxMox Com alguns poucos comandos já conseguimos migrar a nossa primeira VM do VMware para o Proxmox, basta repetir esse procedimento para as demais VM’s do seu ambiente. Porém, não é só isso. O ProxMox tem várias outras funções interessantes que você pode utilizar já no início da sua implementação, fique ligado nos próximos posts! Você irá aprender a: A migração do VMware para o Proxmox pode ser uma escolha estratégica para otimizar seus recursos e reduzir custos sem comprometer a qualidade. Se você está buscando uma alternativa sólida e econômica para suas necessidades de virtualização, estamos aqui para ajudar. Entre em contato conosco para explorar as possibilidades e iniciar o processo de migração para o Proxmox.
Como configurar FlowSpec em Roteadores Huawei
Visão Geral: O BGP FlowSpec (Border Gateway Protocol Flow Specification) é uma extensão do protocolo BGP usado para definir regras de filtragem de tráfego em roteadores. Ao contrário do BGP convencional, que roteia com base em informações de IPv4/IPv6 e prefixo, o BGP FlowSpec permite que os administradores de rede especifiquem critérios mais granulares para o encaminhamento de pacotes, incluindo informações sobre camada 4 (portas TCP/UDP) e até mesmo padrões de pacotes. O Flowspec simplificando permite aos administradores da rede criar regras de firewall dinamicamente através de anúncios BGP, podendo utilizar critérios de camada 4 como protocolo e portas de aplicação, e aplicar ações que podem ser de descartar o tráfego ou somente aplicar um controle de banda. Se você quiser saber mais sobre o funcionamento do FlowSpec confira esse artigo explicando o que é Flowspec Funcionamento: O BGP FlowSpec funciona adicionando novos tipos de atributos ao BGP, permitindo aos administradores de rede especificar regras de filtragem (ou de firewall dinâmico) detalhadas. Essas regras podem incluir critérios como: As seguintes ações podem ser tomadas com o BGP FlowSpec: Quando essas regras são propagadas através da rede BGP, os roteadores podem usar essas informações para filtrar ou manipular o tráfego de acordo com as políticas definidas. Funcionamento – Mais Detalhes: No contexto do BGP FlowSpec, as ações são especificadas como parte das regras de filtro. Cada regra de filtro contém três partes principais: As ações no BGP FlowSpec são codificadas usando comunidades BGP. Cada ação é mapeada para uma comunidade BGP específica: Ao criar uma regra BGP FlowSpec, você especifica os campos de correspondência, a ação desejada e, opcionalmente, campos de protocolo. Esta regra é então codificada como uma comunidade BGP e incluída em uma mensagem de atualização BGP que é enviada para os roteadores vizinhos. Os roteadores que recebem essa regra aplicam as ações especificadas aos pacotes que correspondem aos critérios de correspondência. Por favor, note que as comunidades BGP específicas para cada ação podem variar de acordo com a implementação do BGP FlowSpec em seu roteador. Recomendo consultar a documentação do seu equipamento para obter informações detalhadas sobre as comunidades BGP associadas a cada ação no BGP FlowSpec. Casos de Uso: O BGP FlowSpec pode ser utilizado para bloquear ou redirecionar tráfego malicioso durante ataques de negação de serviço distribuídos (DDoS). As regras precisas podem ser aplicadas para filtrar o tráfego indesejado e manter os serviços online. Administradores de rede podem utilizar o BGP FlowSpec para garantir a qualidade de serviço, priorizando determinados tipos de tráfego com base em portas ou protocolos específicos. O BGP FlowSpec pode ser usado para implementar políticas de segurança granulares, bloqueando tráfego associado a malware ou atividades suspeitas. Exemplos de Configuração: Agora que você já sabe o que é FlowSpec e o que ele pode fazer, vamos demonstrar como configurar o FlowSpec em Roteadores Huawei, essa configuração vale para os Roteadores Huawei NE20, Huawei NE40, Huawei NE8000-M4, Huawei NE8000-M8, Huawei NE8000-M12, Huawei NE8000-F1A ou qualquer Huawei que utilize o sistema Operacional VRP da Huawei. Exemplo de configuração da especificação de fluxo BGP dinâmico: Se as características do tráfego de ataque DoS ou DDoS forem desconhecidas, um servidor de análise de tráfego, como o Made4Flow com Anti-DDoS, pode ajudar a implementar a especificação de fluxo BGP para garantir a segurança da rede. #Requisitos de rede: Conforme mostrado na Topologia abaixo, o Dispositivo A pertence ao AS 100, enquanto o Dispositivo B, o Dispositivo C e o Servidor pertencem ao AS 200. O Dispositivo B é uma entrada do AS 200. O AS 200 se comunica com o AS 100 através do Dispositivo B. A origem do ataque no AS 100 pode fluir para o AS 200 através do Dispositivo B, representando uma ameaça ao AS 200. Nessa situação, configure a especificação de fluxo BGP dinâmica para garantir a segurança da rede. O processo de operação é o seguinte: Observação: As interfaces 1 a 3 neste exemplo representam GE 1/0/0, GE 2/0/0 e GE 3/0/0, respectivamente. O roteiro de configuração segue o seguinte fluxo: Preparação de dados: Para concluir a configuração, você precisa dos seguintes dados: Procedimento: Vamos demonstrar os comandos utilizados, em nosso laboratório estamos utilizando um simulador como o PNETLAB/EVE-NG. #Configure o dispositivo B: #Verifique o status da conexão de peer da sessão de FlowSpec no dispositivo B, se caso a sessão tenha o status “Established” a sessão está correta e funcional. #Verifique as rotas recebidas via BGP Flowspec pelo dispositivo B: #Verifique a política de tráfego (Regra de firewall dinâmica) em cada rota de BGP Flowspec com base no ReIndex mostrado na saída anterior: Arquivos de configuração completos do cenário: Arquivo de configuração do dispositivo A: Arquivo de configuração do dispositivo B: Abaixo mais um exemplo básico de uma regra BGP FlowSpec para bloquear tráfego de uma determinada porta: Validar rotas BGP Flowspec recebidas: Validar detalhes da rota recebida: Para checar se as rotas BGP Flowspec estão sendo efetivas, você pode usar os comandos abaixo: Validar estatísticas da rota: Mais comandos para validações: Exemplo de rota Flowspec com rate-limit: RFCs: Para informações detalhadas sobre BGP FlowSpec, consulte as seguintes RFCs: Certifique-se de consultar estas RFCs para obter informações detalhadas sobre o BGP FlowSpec e suas extensões. Você sabia que agora o Made4Flow possui BGP Flowspec automatizado em suas configurações e você pode proteger sua rede e seus clientes usando esta tecnologia? Você pode automatizar os anúncios BGP FlowSpec de discard, rate limit e com as regras flexíveis.
Atualizações – Made4Flow, Made4Graph e Made4OLT – Janeiro 2024
Made4Flow – Versão 2.6.1 Adições Alterações Correções Made4Graph – Versão 2.4.2 Adições Correções Made4OLT – Versão 1.2.2 [Beta] Adições Alterações Correções
O que é FlowSpec? Como utilizar FlowSpec para mitigar ataques DDoS?
Basicamente, o Flowspec é uma extensão do protocolo BGP que permite aos roteadores aplicar regras, como ACLs dinâmicas ou regras de firewall dinâmicas em tipos específicos de tráfego. Essas regras podem ser baseadas em uma variedade de critérios, incluindo origem, destino, protocolo, porta e etc.
Atualizações – Made4Flow, Made4Graph e Made4OLT – Janeiro 2024
Made4Flow – Versão 2.6.0 Adições: -Adicionado a opção de anunciar FlowSpec manualmente. -Adicionado ação de envio de anúncio BGP FlowSpec no Anti-DDoS. -Adicionado execução reincidente ou prolongamento do anúncio para ataques com anomalias já existentes. -Adicionado a possibilidade de controlar a unidade de tempo nas ações do Anti-DDoS. -Adicionado a possibilidade de visualizar o flowspec anunciado. -Adicionado select com os IPs das interfaces da VM local. -Adicionado visualização do tráfego em tempo real de IPv6 na dashboard principal. -Adicionado a possibilidade de configurar um tamanho de prefixo para as ações de IPv6.-Adicionado novas validações com dois coletores cadastrados na ferramenta.-Adicionado a escolha da interface local pro bind dos IPs das sessões BGP. Alterações: -Alterado para não permitir a adição de um novo roteador com os mesmos dados de histórico.-Alterado a verificação de coleta Netflow do roteador agora ocorre de dentro do coletor. Correções: -Corrigido a exibição de tráfego em realtime dos roteadores em coletores separados do Made4Flow.-Corrigido o flood de logs nos anúncios BGP em cenários específicos. Made4Graph – Versão 2.4.1 Alterações: -Realizamos melhorias significativas na performance do worker responsável pelas tarefas do TR-069. Agora, em casos de falhas nas tarefas, implementamos um processo otimizado de remoção dessas tarefas da CPE correspondente. Essa otimização visa evitar um aumento substancial no uso do servidor, que anteriormente poderia causar uma lentidão. Correções: -Identificamos e corrigimos um problema que poderia ocasionar um aumento no consumo de recursos do servidor, decorrente das consultas realizadas no TR-069. Essa correção visa otimizar a performance do servidor, garantindo um funcionamento mais estável e eficiente durante as consultas do TR-069. Made4OLT – Versão 1.1.4 [Beta] Adições: 1 – Homologado ZTE-C600 (Firmware 1.2.2) view e provisionamento.2 – Implementado soft delete no ONU TYPE.3 – Implementado comandos SNMP para coletar dados das ONUS.4 – Adicionado filas separadas no bull para capturar diferentes tipos de dados, respeitando o tempo de requisições de cada OLT.5 – Adicionado imagem nas ONUS Alterações: 1 – Alterado tela de detalhes da ONUs 2 – Otimização no banco de dados, criando index para as tabelas.3 – Alterado regra de negócio das ONUS quando não receber sinal da mesma, deixando igual smartOLT4 – Possibilidade de carregar Slots/Pons/Ports individualmente via SNMP Correções: 1 – O foco desta sprint foi corrigir valores e status das ONUs em produção
Como configurar Netflow em Roteadores Nokia
Olá Hoje vamos demonstrar como configurar o seu roteador Nokia SR OS para exportar Netflow (IP Netstream). Aqui temos a topologia da Rede e as informações do Servidor de Netflow Estes são os passos necessários para configuração do Roteador Nokia SR OS para exportar Netflow v9/v10 via IP Netstream 1 – Configurar o Servidor de NTP2 – Configurar os parâmetros do cflowd com o Servidor de Netflow3 – Configurar a interface para habilitar o Netflow Vamos para a configuração passo a passo: 1.Configurar o Servidor de NTP É importante configurar um Servidor de NTP pois os dados Flows usam timestamp de acordo com a hora do Roteador, caso o roteador esteja com uma hora diferente do servidor, os dados não irão estar de acordo com a hora, gerando um desencontro de informações. É importante que seja configurado no mínimo 2 servidores de NTP e também o timezone de seu roteador. 2 – Configurar os parâmetros do cflowd com o Servidor de Netflow 3- Configurar a interface para habilitar o Netflow Por último precisamos ativar nas interfaces que irão exportar o Netflow, para isso em cada interface utilize os comandos: Segue abaixo a configuração completa do Roteador: E em todas as interfaces habilitar: Descrição detalhada Alguns comandos extras para análise do flow:
