Author: Diego Dias

O que é um Web Application Firewall (WAF) e sua importância na segurança de aplicações web

Diego DiasLeave a comment

Na era digital de hoje, garantir a segurança de aplicações web e APIs tornou-se fundamental para proteger informações confidenciais contra uma infinidade de ameaças cibernéticas. Um firewall de aplicação web (WAF) serve como um mecanismo de defesa crítico, filtrando e monitorando o tráfego HTTP para proteger serviços online contra os ataques maliciosos, como injeção de SQL, cross-site scripting (XSS) e transferência não autorizada de dados.

Dada a importância crescente da segurança de aplicações web destacada por inúmeras violações relatadas em investigações da indústria, a adoção de WAFs torna-se importante não apenas para proteger aplicações web, mas também para cumprir padrões regulatórios e proteger dados confidenciais.

Um firewall de aplicativo da web bem implementado pode proteger os aplicativos contra bots maliciosos e outras ameaças externas, ao mesmo tempo que garante a conformidade com padrões como PCI DSS. Além disso, os WAFs modernos, são projetados para atender às necessidades específicas de aplicações web, fornecendo medidas de segurança personalizadas e incorporando avanços em aprendizado de máquina para adaptação dinâmica a ameaças.

O que é um Web Application Firewall (WAF)?

Um Web Application Firewall (WAF) é uma ferramenta de segurança especializada projetada para proteger aplicações web ao monitorar e filtrar o tráfego HTTP/HTTPS entre a internet e o aplicativo web.

Funcionamento do WAF

  1. Monitoramento e Filtragem: O WAF inspeciona o conteúdo que passa entre a internet e o aplicativo web, aplicando um conjunto de regras—chamadas políticas—para bloquear tráfego malicioso.
  2. Proteção contra Ameaças Específicas: Protege contra ameaças conhecidas e emergentes, incluindo bots maliciosos, ataques de negação de serviço (DoS), e outras vulnerabilidades listadas pelo OWASP.
  3. Configuração de Políticas: As políticas do WAF podem ser rapidamente ajustadas para responder a ameaças emergentes, proporcionando uma defesa adaptativa contra uma variedade de vetores de ataque

Importância do WAF na Proteção de Aplicações

O Web Application Firewall complementa os firewalls tradicionais (como também NGFW) que não são suficientes para entender o tráfego web detalhadamente, ajuda a cumprir regulamentações de segurança e fornece logs detalhados para análise de tráfego, auditoria, identifica e controla o tráfego de bots, diferenciando entre bots benéficos e maliciosos, através de técnicas como análise de comportamento, CAPTCHA e desafios de JavaScript.

O WAF, portanto, é uma peça crítica na proteção de aplicações web e APIs, essencial para manter a integridade e a segurança dos dados enquanto enfrenta um cenário de ameaças em constante evolução.

Como o WAF Protege sua Aplicação Web

Filtragem de Tráfego

O Web Application Firewall (WAF) atua como um escudo protetor entre a aplicação web e a Internet, filtrando o tráfego HTTP/HTTPS para identificar e bloquear conteúdo malicioso antes que ele possa alcançar o aplicativo. Esta filtragem é essencial para proteger contra ataques comuns, como injeção de SQL e cross-site scripting (XSS). O WAF utiliza políticas de segurança que podem ser ajustadas rapidamente para responder a novas ameaças, garantindo uma proteção eficaz contra uma ampla gama de vetores de ataque.

Monitoramento e Bloqueio de Ataques

O monitoramento contínuo das solicitações e respostas HTTP permite ao WAF identificar padrões suspeitos e bloquear ataques direcionados, como tentativas de exploração de vulnerabilidades conhecidas e desconhecidas. Além disso, o WAF é capaz de detectar e impedir atividades de botnets e outras fontes de tráfego malicioso, utilizando métodos avançados como CAPTCHA e algoritmos de interação humana para diferenciar entre usuários legítimos e mal-intencionados.

Configuração de Políticas de Segurança

As políticas de segurança do WAF são configuráveis e permitem uma resposta personalizada às ameaças detectadas. Isso inclui a capacidade de permitir, bloquear ou registrar solicitações com base em critérios específicos, como endereços IP, cabeçalhos HTTP e strings de URI. Essas políticas são fundamentais para garantir que apenas o tráfego legítimo tenha acesso ao aplicativo, enquanto o tráfego malicioso é bloqueado. A flexibilidade e a adaptabilidade das políticas do WAF são cruciais para manter a segurança das aplicações web em um ambiente de ameaças em constante evolução.

Tipos de WAF

WAFs de Rede

Os WAFs de rede são soluções baseadas em hardware, implementadas fisicamente, on-premise, o que elimina latência e aumenta a eficiência do sistema. Eles são ideais para grandes organizações devido à capacidade de replicar regras e configurações em várias instâncias, proporcionando proteção em nível de rede. No entanto, esses WAFs exigem um investimento inicial significativo e custos contínuos de manutenção, além de dependerem de uma infraestrutura física robusta e equipe de TI especializada.

WAFs de Host

Os WAFs de host são integrados diretamente ao software da aplicação e oferecem um alto nível de personalização. Essa opção é mais econômica e permite uma visão detalhada do tráfego e comportamento da aplicação, sendo uma escolha popular entre as empresas que buscam uma primeira camada de proteção. Contudo, consomem muitos recursos do servidor, o que pode impactar o desempenho da aplicação.

WAFs na Nuvem

Os WAFs baseados em cloud são fornecidos como um serviço, com o tráfego sendo roteado através de um provedor de serviços de segurança na nuvem. Essa modalidade oferece uma implementação rápida e custos iniciais reduzidos, já que geralmente são contratados por meio de subscrição. Além disso, os WAFs na nuvem são constantemente atualizados para proteger contra as ameaças mais recentes sem custos adicionais, e não exigem hardware adicional. Contudo, a dependência do provedor de serviços pode ser um desafio, pois problemas no provedor podem afetar a disponibilidade e o desempenho do site.

Desafios na Administração de um WAF

Gestão de Falsos Positivos

A administração de um Web Application Firewall (WAF) envolve desafios significativos, especialmente na gestão de falsos positivos. O WAF pode erroneamente identificar tráfego legítimo como malicioso, resultando em bloqueios desnecessários que podem afetar a experiência do usuário e a funcionalidade do site. Ajustar as regras para minimizar esses incidentes requer uma análise cuidadosa e contínua do tráfego web, o que pode ser um processo complexo e que demanda tempo.

Manutenção e Atualização

Manter um WAF eficaz exige atualizações regulares das regras de segurança para enfrentar novas ameaças e vulnerabilidades emergentes. Este processo não só é essencial para a segurança das aplicações web, mas também exige uma equipe qualificada e recursos suficientes para implementar as mudanças de forma eficiente. A falta de manutenção adequada pode deixar o sistema vulnerável a ataques, comprometendo a segurança dos dados.

Configuração e Customização

Configurar um WAF adequadamente é crucial para sua eficácia. Uma configuração inadequada pode não apenas falhar em proteger contra ataques, mas também pode bloquear usuários legítimos, afetando negativamente a operação do aplicativo web. Personalizar as políticas de segurança para se adaptarem às necessidades específicas de cada aplicação é uma tarefa complexa que exige um entendimento profundo do comportamento do aplicativo e dos possíveis riscos.

Melhores Práticas na Implementação de um WAF

Determinação dos Requisitos de Segurança

A implementação eficaz de um Web Application Firewall (WAF) começa com a determinação precisa dos requisitos de segurança específicos da sua aplicação. É essencial entender a tolerância ao risco da organização e configurar as políticas de WAF de acordo. Por exemplo, uma grande operação de comércio eletrônico pode optar por uma tolerância mais alta ao risco para evitar bloquear tráfego legítimo, enquanto uma instituição financeira pode preferir uma tolerância baixa para maximizar a segurança ].

Escolha Entre Soluções no Local e Baseadas na Nuvem

A escolha entre soluções de WAF no local ou baseadas na nuvem deve ser guiada pelas necessidades específicas de infraestrutura e operacionais da sua organização. WAFs on-premise oferecem controle total e desempenho potencialmente superior, ideal para organizações com requisitos rigorosos de segurança de dados. Por outro lado, WAFs baseados na nuvem proporcionam flexibilidade, menor custo inicial e atualizações automáticas, sendo uma escolha eficiente para organizações que valorizam a facilidade de implementação e custos reduzidos.

Monitoramento e Análise Contínua

Manter um monitoramento constante é crucial para a eficácia de um WAF. Isso inclui ajustar e aprimorar as regras de segurança conforme novas ameaças surgem. A integração do WAF com outras soluções de segurança, como sistemas de detecção e prevenção de intrusões, pode oferecer uma proteção mais abrangente. Além disso, é vital garantir que a equipe de segurança esteja bem treinada e ciente das funcionalidades e relatórios do WAF. Utilizar tecnologias de aprendizado de máquina para a adaptação automática das proteções às mudanças nas aplicações e ameaças emergentes pode reduzir significativamente o atrito operacional e a sobrecarga administrativa.

Conclusão

Ao longo deste artigo, exploramos a função essencial dos Web Application Firewalls (WAFs) no fornecimento de segurança robusta para aplicações Web e APIs. As discussões destacaram como os WAFs atuam como um escudo protetor, filtrando e monitorando o tráfego HTTP para evitar uma variedade de ameaças cibernéticas, incluindo injeção de SQL, scripts entre sites e transferências de dados não autorizadas. Esta medida de segurança abrangente não visa apenas a defesa contra ataques, mas também a garantia do cumprimento das normas regulamentares e a proteção de informações sensíveis, reafirmando a necessidade de incorporar os WAFs na estratégia de segurança digital das organizações.

A integração e a administração adequada de um WAF significam uma postura proativa contra o cenário em constante evolução das ameaças cibernéticas que visam aplicações web e APIs. Ao implementar um WAF, as organizações podem melhorar a sua postura de segurança, cumprir os requisitos de conformidade e, em última análise, proteger os seus ativos digitais contra ataques sofisticados. Além disso, à medida que olhamos para o futuro, a importância dos WAFs só deverá aumentar com o crescimento contínuo de aplicações web e dispositivos IoT, a necessidade de investigação contínua, avanço e adoção destas soluções críticas de segurança para salvaguardar a integridade e disponibilidade de serviços online.

Referencias

https://avinetworks.com/what-is-a-web-application-firewall/
https://www.cloudflare.com/learning/ddos/glossary/web-application-firewall-waf/
https://www.f5.com/glossary/web-application-firewall-waf
https://www.paloaltonetworks.com/cyberpedia/what-is-a-web-application-firewall
https://ultahost.com/blog/web-application-firewalls/
https://www.youtube.com/watch?v=l5Zv1wbFF78
https://fj.com.br/web-application-firewall-o-que-e-o-waf-e-como-ele-protege-aplicacoes/
https://blog.bughunt.com.br/o-que-e-waf


Os desafios de segurança do desenvolvimento de aplicativos modernos

Diego DiasLeave a comment

Na era digital, a agilidade e a rápida colocação de aplicativos no mercado são cruciais para o sucesso. Por isso, muitas empresas adotam métodos de desenvolvimento Agile e culturas DevOps, possibilitando múltiplas releases de código por dia.

No entanto, essa busca por velocidade pode comprometer a segurança. Desenvolvedores de aplicativos frequentemente dependem de componentes como containers, microsserviços e frameworks, muitos dos quais são softwares de código aberto (FOSS – Free Open-source software). Apesar de o FOSS ser uma grande fonte de inovação, ele também expande a superfície de ataque para agentes mal-intencionados.

APIs são outro componente crítico de aplicações modernas, permitindo a integração entre diferentes softwares. No entanto, APIs também são suscetíveis a explorações e abusos. Ao contrário de páginas web, APIs não são projetadas para interação direta do usuário, o que pode deixá-las fora do radar de equipes de segurança, tornando-as especialmente vulneráveis a ataques.

Componentes e APIs de código aberto, embora facilitem a vida dos desenvolvedores, introduzem novos riscos de segurança. Controles tradicionais, como desenvolvimento orientado a testes, nem sempre são eficazes com esses componentes. Por isso, o gerenciamento e a segurança da API precisam ser integrados ao pipeline de desenvolvimento.

Infelizmente, velocidade e segurança muitas vezes entram em conflito. A pressão para implementar novos códigos rapidamente pode levar ao uso inseguro de componentes FOSS e APIs. Pipelines de CI/CD que automatizam o desenvolvimento e a implantação geralmente carecem de testes de segurança adequados, gerando atrito entre desenvolvedores e equipes de segurança, pois os primeiros podem ver os testes como um obstáculo à agilidade.

Além disso, métodos de teste tradicionais, como testes unitários e de regressão, concentram-se na funcionalidade e não na segurança. Isso pode deixar os aplicativos vulneráveis a novas ou reintroduzidas vulnerabilidades.

A proliferação de endpoints digitais em arquiteturas modernas complica ainda mais o cenário de segurança. À medida que os aplicativos tradicionais evoluem para sistemas baseados em API, o número de possíveis superfícies de ataque aumenta. Equipes de segurança podem não estar cientes de todas as APIs em seu ecossistema, dificultando sua proteção adequada.

Para enfrentar esses desafios, as empresas precisam implementar medidas robustas de segurança de API. Isso inclui:

  • Descoberta dinâmica de API: Identificação automática de APIs em seu ambiente.
  • Proteções automatizadas usando aprendizado de máquina: Mitigação de ameaças em tempo real.
  • Colaboração estreita entre desenvolvedores e equipes de segurança: Integração da segurança no processo de desenvolvimento.

Ao priorizar a segurança da API, as empresas podem se proteger do crescente número de incidentes e violações de segurança.

Lembre-se:

  • A segurança da API é essencial para proteger seus dados e aplicativos.
  • Implemente medidas robustas de segurança de API para mitigar riscos.
  • Colabore entre desenvolvedores e equipes de segurança para integrar a segurança no processo de desenvolvimento.
  • Priorize a segurança da API para se proteger contra incidentes e violações.

Com as ferramentas e estratégias certas, você pode garantir que seus aplicativos modernos sejam seguros e confiáveis.

Para mais informações, consulte os seguintes recursos:

BGP – Mandatory Well-Known (Path Attributes)

Diego DiasLeave a comment

O Protocolo BGP utiliza diversos parâmetros para escolha de melhor rota quando há diversos caminhos para o mesmo destino, esses parâmetros são chamados de Path Atributes.

Cada atualização do BGP consiste em uma ou mais sub-redes (prefixos) vinculadas aos seus atributos.

Os Path Atributes são classificados em Well-Known ( bem conhecido ) ou Optional (opcional). Alguns desses atributos são obrigatórios e outros opcionais com validade local na tabela de roteamento, local no AS, etc.

Os atributos Well-Known são classificados em Mandatory(obrigatório ) e Discretionary ( arbitrário).

No tópico de hoje citaremos os atributos Mandatory, Well-Known (bem conhecidos e obrigatórios).

Mandatory Well-Known

São 3 os atributos Mandatory Well-Known – Origin, AS-Path e Next-hop:

Origin: Relaciona a maneira que a rota foi aprendida pelo BGP. Se a rota foi declarada com o comando network ou via agregação de rotas ela será exibida com a letra “i”, para as rotas aprendidas via redistribuição é utilizado o caracter “?”. Há ainda a possibilidade da rota ser aprendida via o protocolo EGP,”e” mas atualmente o mesmo está em desuso.

AS-Path: Quando um prefixo é injetado no BGP e compartilhado entre os AS, inicialmente o AS-Path é atribuído como vazio, cada vez que a rota atravessa um AS(Sistema Autônomo) é adicionado pelos roteadores de Borda o numero do AS que ele pertence. É possível rastrear a sequencia de Sistemas Autônomos utilizando o atributo AS-Path.

Next-hop: Indica o endereço do próximo salto do Roteador que recebeu o prefixo. Geralmente o roteador que anuncia determinado prefixo repassa com o next-hop o seu próprio IP, exceto em sessões iBGP.

SHOW

O comando show ip bgp exibirá a saída da tabela BGP do Roteador com Cisco IOS:

Router>show ip bgp
BGP table version is 2709, local router ID is 172.16.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight Path
   Network          Next Hop        Metric LocPrf Weight Path
* i1172.31.1.0/29   0.0.0.0              0    100  32768 i
* i1172.16.10.0/24  0.0.0.0              0    100  32768 ?
* i1172.16.11.0/24  192.168.85.22        0    100      0 65510 65544 65516 65541 ?
*>                  192.168.85.23        0             0 65510 65544 65516 65541 ?
* i1172.16.12.0/22  192.168.85.22        0    100      0 65510 65544 65516 65541 ?
*>                  192.168.85.23        0             0 65510 65544 65516 65541 ?

[saída omitida]

! A rede 172.31.1.0/29 está diretamente conectada no Roteador e inserida processo via comando Network ! Já a rede 172.16.10.0/24 foi inserida na tabela BGP via processo de redistribuição

Peering BGP

O comando show ip bgp summary exibe os “peerings” BGP:

Router>show ip bgp summary
BGP router identifier 172.16.1.1, local AS number 65500
BGP table version is 2709, main routing table version 2709
258 network entries using 29154 bytes of memory
510 path entries using 24480 bytes of memory
6725/10 BGP path/bestpath attribute entries using 672500 bytes of memory
2 BGP rrinfo entries using 48 bytes of memory
856 BGP AS-PATH entries using 32108 bytes of memory
270 BGP community entries using 7536 bytes of memory
12 BGP extended community entries using 304 bytes of memory
197 BGP route-map cache entries using 6304 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 772434 total bytes of memory
BGP activity 449536/418807 prefixes, 1538082/1477309 paths, scan interval 60 secs

Neighbor      V    AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down  State/PfxRcd
192.168.85.22 4 65510  962698  517851  2701   0    0 1w2d         24
192.168.85.23 4 65510  517865  517853  2701   0    0 1w2d         25
Router>

Até logo!

Fortigate – reset de senha

Diego DiasLeave a comment

Para acessar um Fortigate em cenários que não se possui a senha de um usuário administrador, siga os seguintes passos:

  1. Acesse o equipamento via console
  2. Reinicie o equipamento
  3. Após o equipamento reiniciar e solicitar o usuário senha, você terá 30 segundos para digitar:

User: maintainer
Password: bcpb<serial-number>

Obs: Todas as letras do Serial Number devem ser maiúsculas (upper case)

Uma vez com acesso ao equipamento, você poderá editar a senha, como faremos com o usuário diego:

Fortigate # config system admin
Fortigate (admin) # show
config system admin
    edit "admin"
        set accprofile "super_admin"
        set vdom "root"
        set password ENC SH2rStUY1qj1l9OtWSt59p1VaWzLF3O7hHZLWKsnM7XKrOYAQWss12=
    next
    edit "diego"
        set accprofile "super_admin"
        set vdom "root"
        set password ENC SH2A7/GUDCIEUYkxbSXYJ522aNGyQPRTR/odp8FHprInkO2abnksdar=
    next 

Fortigate #
Fortigate # config system admin
Fortigate (admin) # edit diego
Fortigate (dinatech) # set password senha123456
Fortigate (dinatech) # end
Fortigate #

Caso seja necessário desabilitar o processo com o usuário maintainer por questões de risco e/ou compliance, configure os comandos abaixo via CLI:

 config sys global
 set admin-maintainer disabled
end

Se precisar resetar toda configuração, entre no equipamento com um usuário administrador e digite:

Fortigate # execute factoryreset
This operation will reset the system to factory default!
Do you want to continue? (y/n)y

Até logo!

Flexible Netflow

Diego DiasLeave a comment

O Netflow é uma tecnologia disponível no Cisco IOS que fornece estatísticas dos pacotes que atravessam um roteador ou Switch. O Netflow coleta e exporta os dados para fins de monitoração, segurança da rede, análise de trafego, análise de capacidade, IP accounting e etc.

Ao invés de apenas contar os pacotes, o NetFlow considera esses pacotes como parte de um fluxo, monitorando o início, meio e fim. Podemos definir um fluxo como uma sequência unidirecional de pacotes que possuem características comuns entre a origem e o destino.

Flexible Netflow (FNF)

O Flexible Netflow (FNF) aprimora o NetFlow com a possibilidade de personalização dos parâmetros para análise do tráfego e facilita a criação de configurações com uma granularidade bem bacana. O FNF é dividido em três funções: a seleção de dados que queremos analisar (flow record), a coleta de dados (flow monitor) e a exportação dos dados para um coletor (flow export).

Para concluir a configuração, um monitor de fluxo pode ser aplicado a uma ou várias interfaces.

Segue abaixo o script bem intuitivo e o resultado da coleta.

Configuração

flow exporter EXPORTER
 description Netflow Collector
 destination 10.10.10.10
 source Loopback0
 transport udp 9996
 template data timeout 60
! Configuração do Flow Exporter
!
flow record QoS
match ipv4 tos
match ipv4 precedence
match ipv4 dscp
match ipv4 protocol
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
collect counter bytes long
collect counter packets long
! Configuração do Flow Record
!
flow monitor MONITOR-QoS
cache timeout inactive 30
record QoS
exporter EXPORTER
exit
! Configuração do Flow Monitor
!
ip cef
!
interface e0/0.45
ip flow monitor MONITOR-QoS input
! Aplicando o Flow Monitor a interface
!

Output

R5#sh flow monitor MONITOR-QoS cache format ta
  Cache type:                               Normal
  Cache size:                                 4096
  Current entries:                               5
  High Watermark:                               12
  Flows added:                                 398
  Flows aged:                                  393
    - Active timeout      (  1800 secs)          2
    - Inactive timeout    (    30 secs)        391
    - Event aged                                 0
    - Watermark aged                             0
    - Emergency aged                             0
IPV4 SRC ADDR    IPV4 DST ADDR    TRNS SRC PORT  TRNS DST PORT  IP TOS  IP DSCP  IP PREC  IP PROT            bytes long             pkts long
===============  ===============  =============  =============  ======  =======  =======  =======  ====================  ====================
155.1.45.4       224.0.0.10                   0              0  0xC0    0x30           6       88                 18000                   300
155.1.146.6      155.1.45.5               16384          52366  0xB8    0x2E           5       17                 60000                  1000
150.1.6.6        150.1.5.5                   80          63906  0x40    0x10           2        6                   385                     5
150.1.6.6        155.1.45.5                1967          54932  0xB8    0x2E           5       17                    52                     1
155.1.146.6      155.1.45.5               16384          54932  0xB8    0x2E           5       17                 13740                   229
R5#

Até logo!

Netflow

Diego DiasLeave a comment

por Woshington Silva

O NetFlow é uma tecnologia desenvolvida pela Cisco e  já vem integrada ao IOS de seus equipamentos permitindo a coleta de informações e estatísticas do tráfego de uma rede.

Ao invés de apenas contar os pacotes, o NetFlow considera esses pacotes como parte de um fluxo, monitorando o  início, meio e fim. Podemos definir um fluxo como uma sequencia unidirecional de pacotes que possuem características comuns entre a origem e o destino.

Para que os pacotes possam fazer parte do mesmo fluxo, as características abaixo devem ser apresentadas:

  • Mesmo Endereço  de Origem;
  • Mesmo Endereço  de destino;
  • Mesma Porta lógica de origem;
  • Mesma Porta lógica de destino;
  • Mesmo Protocolo de camada 3;
  • Mesmo Tipo de serviço (ToS);
  • Mesma interface (independente de ser física ou lógica);

Um fluxo é extinguindo quando:

  • Sua inatividade supera 15 segundos;
  • Sua duração ultrapassa 30 minutos;
  • Uma conexão TCP é encerrada ;
  • A tabela de fluxos está cheia ou usuário redefine configurações de fluxo;

Obs: Quando um pacote é recebido e o mesmo não pertencer a nenhum fluxo existente, ocorrerá a criação de um novo fluxo.

Quando o fluxo é identificado, as informações são  armazenadas na tabela cache NetFlow. Podemos também transferi-las para um coletor que exibira as informações em formas de relatórios e gráficos.  Porém essas informações serão enviadas ao coletor após o término do fluxo.

O NetFlow  é inteiramente  transparente para os outros dispositivos da rede, não exige nenhuma configuração nos elementos que serão monitorados. Sua única exigência é que seja habilitada na interface do equipamento (Roteador).

Abaixo veremos uma configuração básica do Netflow.

Configurando o Netflow no router:
Router(config)# ip flow-export destination a.b.c.d 9997
!Endereço IP do servidor e porta UDP
Router(config)# ip flow-export version 9
Router(config)# ip flow-export source Ethernet 0/1

obs: a versão do netflow e a porta devem ser a mesma do coletor, outro ponto importante é o que o ip cef esteja habiltado.

Configurando as interfaces:
Router(config)# interface Ethernet 0/0
Router(config-if)# ip route-cache flow
Router(config-if)# ip flow ingress

Existem duas formas de verificarmos os dados coletados: a primeira, via CLI e a segunda via o coletor, ressaltando mais uma vez que os dados só serão coletados após o término do fluxo. Caso haja o desejo de analisar o tráfego em tempo real, o ideal é usarmos os comandos via CLI.

Um dos comandos via CLI em que possamos verificar os dados é o:

Router# show ip cache flow

Onde obtemos informações como distribuição do tamanho dos pacotes, número de fluxos ativos, protocolos utilizados, interface de origem e destino, endereço IP de origem e destino, porta de origem e destino e  tamanho dos pacotes.

Particularmente tive um experiência muito satisfatória ao usar o NetFlow, na empresa em que trabalho recebemos a solicitação para a abertura de um chamado, onde o cliente informava que o link de uma determinada localidade estava com alta utilização e gostaria de receber um relatório com a origem  desse tráfego.

Após contato com o cliente, identificamos que o mesmo não possuía um coletor para construção de gráficos e relatórios baseados em Netflow, a única coisa que nos restava era usar os recursos que a CLI podia nos oferecer. Então decidimos configurar o roteador para que exibisse os 10 maiores fluxo por pacote.

Para que isso fosse possível utilizamos os seguintes comandos na CLI:

Router(config)# ip flow-top-talkers
Router(config-flow-top-talkers)# top 10
Router(config-flow-top-talkers)# sort-by packets

Para visualizar os top 10 o comando é show ip flow top-talkers.

Em resumo, com o NetFlow podemos obter benefícios como:

  • Monitoramento da banda ;
  • Análise de tráfego;
  • Análise da rede;
  • Gerência de segurança;
  • Monitoramento de aplicativos;
  • Rastreamento da migração de aplicativos;
  • Validação de QoS;
  • Planejamento de capacidade;
  • Identificação de worms e malwares

Ou seja, podemos considerar o NetFlow como uma importante ferramenta que nos possibilita compreender, melhorar  e identificar possíveis  problemas que estão acorrendo na rede.

Referências

http://labcisco.blogspot.com/2013/08/cisco-netflow-na-classificacao-do.htmlhttps://www.telcomanager.com/pt-br/o-que-e-netflowhttp://www.teleco.com.br/tutoriais/tutorialgmredes2/pagina_3.asp

Distância Administrativa

Diego DiasLeave a comment

por Woshington Silva

Os roteadores utilizam a distância administrativa para escolher o melhor caminho quando aprendem mais de uma rota para o mesmo destino através de protocolos distintos.  A confiabilidade de um protocolo de roteamento é definida através da distância administrativa.

Quanto menor o valor da distância administrativa mais confiável o protocolo. Esses valores variam de 0 à 255, onde 0 é mais confiável e 255 é menos confiável

Exemplo:
Em um roteador temos duas rotas aprendidas por protocolos distintos para uma determinada rede, a primeira rota foi descoberta pelo protocolo de roteamento RIP e  a segunda pelo protocolo de roteamento OSPF. Baseando-se na tabela abaixo, qual caminho o roteador irá escolher?

*Valores padrão de distância administrativa dos protocolos suportados pela Cisco

Ao verificarmos a tabela acima vimos que a rota onde apresenta o protocolo OSPF será escolhida como melhor caminho e assim inserida na tabela de roteamento, já que o valor 110 do protocolo OSPF está mais próximo de 0 do que o valor  120 do protocolo RIP. Portanto o protocolo OSPF é mais confiável do que o protocolo RIP.

Porém se por algum motivo quiséssemos alterar o valor padrão da distancia administrativa, isso é possível através do comando  “distance”, conforme veremos abaixo:

Router(config)#router rip
Router(config-router)# distance 80
Router(config-router)# end

Se aplicarmos essa configuração no exemplo acima o roteador adicionará na tabela de roteamento a rota do protocolo RIP ao invés da rota do protocolo OSPF, já que agora o valor da distância administrativa do RIP passará a ser de 80, portanto menor que 110 da distância administrativa do OSPF.

Obs: Caso haja uma alteração no valor padrão para 255, o roteador não incluirá a rota na tabela de roteamento, ele irá entender que a rota é totalmente não-confiável.

E se a duas rotas fossem descobertas pelo mesmo protocolo de roteamento?
Quando isso acontece, o roteador irá escolher a rota que tiver a melhor métrica e assim inseri-la na tabela de roteamento.

 Uma informação importante é que a distância administrativa tem um significado local, sendo assim, ela não é anunciada nas atualizações de roteamento, se você alterar o valor padrão só o roteador onde ocorreu a mudança sentirá o efeito.

Por fim…
Podemos verificar a distância administrativa com aos seguintes comandos show ip route e show ip protocols, conforme veremos nas imagens abaixo:

Até o próximo artigo!

MPLS (Multi Protocol Label Switching) – parte 2

Diego DiasLeave a comment

Como iniciado no primeiro post, em uma rede com arquitetura MPLS cada roteador da topologia possui uma designação que define a sua posição e atribuição na topologia:

  • CE (Customer Edge Router) – possui a função de prover conectividade para a rede MPLS e é situado na “borda do cliente”. Não encaminha e nem troca labels.
  • PE (Provider Edge Router) – é responsável pela conexão entre uma rede IP (rede do cliente) e a rede MPLS (rede da Operadora/Provider)
  • P (Provider Edge Router) – é responsável pelo encaminhamento de pacotes baseando-se nos labels.

Label Switch Router

Diversas documentações também atribuem um nome mais genérico para roteadores que tratam o recebimento e encaminhamento de pacotes MPLS, chamados de Label Switch Routers(LSR). Na topologia, os LSR podem ser chamados de:

  • Ingress LSRs – responsáveis por receber um pacote não “rotulado” e inserir o Label
  • Egress LSRs – responsáveis por receber um pacote “rotulado” e remover o Label
  • Intermediate LSRs – responsáveis por inserir, encaminhar e trocar Labels.

Os Roteadores LSRs são responsáveis por três operações principais para encaminhamento de pacotes e/ou labels: POP (remover o label), PUSH (inserir o label) ou SWAP (trocar o label).

A seqüência de Roteadores LSRs que são responsáveis pela comutação de um pacote com label em uma rede MPLS, é chamada de LSP (Label Switched Path).

O LSP é definido como o caminho por onde os pacotes irão passar numa rede MPLS. No momento em que um pacote entra numa rede MPLS, este é associado a uma classe de equivalência (FEC) e assim é criado um LSP relacionado a esta FEC.

Como a criação de uma LSP só ocorre na entrada de uma rede MPLS, os LSR ( Label Switch Router) da nuvem só terão o trabalho de fazer as trocas dos rótulos (swap), encaminhando assim o pacote de acordo com o LSP determinado anteriormente, não havendo mais a necessidade de fazer o roteamento dos pacotes (somente a comutação via Label).

Protocolos de distribuição de Labels

Atualmente são utilizados 2 principais protocolos para distribuição de Rótulos em uma rede MPLS, (daremos um foco especial no LDP):

  • Label Distribution Protocol (LDP)
  • Resource Reservation Protocol – Traffic Engineering (RSVP-TE)

O vinculo de Rótulos é a associação de um label a um prefixo (rota). O LDP trabalha em conjunto com um IGP (OSPF, IS-IS, etc) para anunciar os vínculos de labels (binding) para as rotas, como por exemplo, em um backbone. Conforme desenho abaixo:

Resumidamente, é atribuído um valor de label para cada prefixo. No exemplo abaixo segue o exemplo da configuração do LDP em um Roteador P com o processo OSPF em um roteador com IOS Cisco.

Exemplo de Configuração do Roteador P

ip cef
mpls ip
mpls ldp router-id loopback 0
!
int loo 0 
ip add 10.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.1.1.5 255.255.255.252
 mpls label protocol ldp
 mpls ip
!
interface FastEthernet0/1
 ip address 10.1.1.1 255.255.255.252
 mpls label protocol ldp
 mpls ip
!
!
router ospf 1
 log-adjacency-changes
 network 10.1.1.0 0.0.0.3 area 0
 network 10.1.1.4 0.0.0.3 area 0
 network 10.2.2.2 0.0.0.0 area 0
!
----------------------------------------------

R2#show mpls forwarding-table 
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
23     Pop tag     10.1.1.0/30       636      Fa0/0      point2point
24     Pop tag     10.1.1.4/30       641          Fa0/1      point2point
25     26          192.168.1.0/24    234          Fa0/0      point2point
26     30         192.168.1.0/24     143          Fa0/1      point2point
27     28         192.168.2.0/30     143          Fa0/1      point2point
-
R2#show mpls ldp neighbor
    Peer LDP Ident: 10.1.1.2:0; Local LDP Ident 10.1.1.5:0
        TCP connection: 10.1.1.2.646 - 10.1.1.1.11012
        State: Oper; Msgs sent/rcvd: 21/21; Downstream
        Up time: 00:10:29
        LDP discovery sources:
          FastEthernet0/0, Src IP addr: 10.1.1.2
        Addresses bound to peer LDP Ident:
          10.1.1.2        
    Peer LDP Ident: 10.1.1.6:0; Local LDP Ident 10.1.1.5:0
        TCP connection: 10.1.1.6.11000 - 10.1.1.5.646
        State: Oper; Msgs sent/rcvd: 28/31; Downstream
        Up time: 00:16:00
        LDP discovery sources:
          FastEthernet0/1, Src IP addr: 10.1.1.6
        Addresses bound to peer LDP Ident:
          10.1.1.6        192.168.1.0      192.168.2.0

Referências

http://www.gta.ufrj.br/grad/04_2/MPLS/conceitos.htm
http://blog.ccna.com.br/2008/09/12/multi-protocol-label-switching-mpls-parte-3/

BGP Communities

Diego DiasLeave a comment

O protocolo BGP possui a versatilidade de agregar redes e atributos; anunciando e modificando cada prefixo de maneira individual. Um desses atributos, o Community permite “taguear”  o anuncio de cada rede individualmente de acordo com o negócio, políticas de roteamento ou para fins de troubleshooting.

De forma básica o uso de community (ou “comunidade BGP” em português) pode ser usado como uma flag para marcar um determinado grupo de rotas.

Provedores de Serviço utilizam essas marcações para aplicar políticas de roteamento específicas em suas redes, por exemplo alterando o Local Preference, MED ou Weight.

O atributo community é opcional e transitivo (optional transitive)  e de tamanho variável, isto é, implementações BGP não necessitam reconhecer o atributo e fica ao critério do administrador de rede alterar ou reencaminhar para outros pares . O atributo consiste em um número de 32 bits que específica uma community. Sendo que sua representação é feita AA:NN onde o AA é o Autonomous System (AS) e o NN é o número da community.

Um prefixo pode participar de mais de uma community e  os roteadores BGP podem tomar uma ação em relação à um prefixo baseado em uma, algumas ou todas as communities associadas ao prefixo.

O comando utilizado para configurar uma community em um Roteador Cisco (baseado no IOS) é via set community dentro de um route-map:

R1(config-route-map)#set community ?
  <1-4294967295>  community number
  aa:nn           community number in aa:nn format
  additive        Add to the existing community
  internet        Internet (well-known community)
  local-AS        Do not send outside local AS (well-known community)
  no-advertise    Do not advertise to any peer (well-known community)
  no-export       Do not export to next AS (well-known community)
  none            No community attribute

O comando “set community” apaga a comunidade existente vinculada a um prefixo substituindo-o pela nova community, a menos que seja especificado o comando additive após o valor da community.

 R1(config-route-map)#set community 65535:1 additive

A community pode ser aplicada em um ou mais prefixos  com a utilização de route-maps nos seguintes itens do processo BGP:

  • No peering BGP de in/out
  • Redistribuição
  • Comando network

Três communities são definidas e reservadas na RFC 1997 para implementações  BGP: NO-EXPORT (0xFFFFFF01 ), NO-ADVERTISE (0xFFFFFF02 ), and NO-ADVERTISE-SUBCONFED (0xFFFFFF03 ). Adicionalmente, NO-PEER (0xFFFFFF04 ) tem sido proposta em um draft para Internet [3].

NO-EXPORT é geralmente utilizado dentro de um AS para instruir os roteadores para não exportar o prefixo para vizinhos eBGP.

NO-ADVERTISE instrui um roteador BGP para não encaminhar o prefixo “tagueado” para qualquer vizinhos, seja iBGP ou eBGP.

NO-ADVERTISE-SUBCONFED é utilizado para prevenir um prefixo de ser anunciado para outros membros dentro da confederação.

NO-PEER é usado em situações onde é necessário o controle de engenharia de tráfego ao longo de um prefixo “mais específico”,  restringindo a sua propagação apenas aos prestadores de trânsito e não seus pares. Ou seja, o prefixo é anunciado de AS para AS, desde que haja uma relação de trânsito / cliente, ao contrário do NO-EXPORT, que restringe a propagação do prefixo somente ao AS adjacente.  Atualmente tal comunidade não é reconhecido pela maioria dos fabricantes e requer uma implementação manual.

Durante processos complexos de redistribuição de IGPs no BGP, o uso de community pode ser usado para detectar o protocolo de origem (por exemplo, uma community para IS-IS outra definida para OSPF, etc).

Community List

A Community-list é como uma ACL, só que para communities. Essas listas são adicionadas com o comando “ip community-list ” onde o valor é representado por “AA:NN” ou por caracteres especiais como, por exemplo, “*” que representa tudo.

Exemplo de configuração

No exemplo abaixo iremos anunciar 3 prefixos do ASN 65524, dois serão marcados com community e um sem  community. No ASN 65525 iremos atribuir um valor de local preference para cada prefixo de acordo com a comunidade atribuída.

Roteador R4
!
ip bgp-community new-format
! Exibe o valor da community de 32 bits dividido em 2 de 16 separados por ":"
!
! Configurando as route-maps para atribuir o valor de community
route-map SET_COMM_B permit 10
 set community 65524:2
!
route-map SET_COMM_A permit 10
 set community 65524:1
!
router bgp 65524
 no synchronization
 bgp log-neighbor-changes
 network 172.16.100.0 mask 255.255.255.0 route-map SET_COMM_A
 network 172.16.101.0 mask 255.255.255.0 route-map SET_COMM_B
 network 172.16.102.0 mask 255.255.255.0
! Anunciando as redes no processo BGP de acordo com as communities atribuídas 
 neighbor 192.168.45.5 remote-as 65525
 neighbor 192.168.45.5 send-community
! Permitindo o envio de community para o peer BGP 
 no auto-summary
!
ip classless
ip route 172.16.100.0 255.255.255.0 Null0
ip route 172.16.101.0 255.255.255.0 Null0
ip route 172.16.102.0 255.255.255.0 Null0
!
end
Roteador R5
!
ip bgp-community new-format
! Exibe o valor da community de 32 bits dividido em 2 de 16 separados por ":"
!
! Community-list para filtro de valores de Communities
ip community-list standard LOCAL_PREF_150 permit 65524:1
ip community-list standard LOCAL_PREF_200 permit 65524:2
!
!
route-map SET_LOCAL_PREF permit 10
 match community LOCAL_PREF_150
 set local-preference 150
! Atribuindo o local preference aos prefixos da community-list
!
route-map SET_LOCAL_PREF permit 20
 match community LOCAL_PREF_200
 set local-preference 200
! Atribuindo o local preference aos prefixos da community-list
!
route-map SET_LOCAL_PREF permit 30
!
router bgp 65525
 neighbor 192.168.45.4 remote-as 65524
 neighbor 192.168.45.4 send-community
 neighbor 192.168.45.4 route-map SET_LOCAL_PREF in
! Atribuíndo os route-maps configurados no peering BGP
 no auto-summary
!
ip classless
!
end
!
! Verificando o valor de Local Preference atribuído a cada prefixo
R5#show ip bgp
BGP table version is 4, local router ID is 192.168.45.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure
Origin codes: i - IGP, e - EGP, ? – incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.100.0/24  192.168.45.4             0    150      0 65524 i
*> 172.16.101.0/24  192.168.45.4             0    200      0 65524 i
*> 172.16.102.0/24  192.168.45.4             0             0 65524 i
!
! Verificando o valor de community atribuído ao prefixo
R5#show ip bgp 172.16.100.0
BGP routing table entry for 172.16.100.0/24, version 2
Paths: (1 available, best #1)
  Not advertised to any peer
  65524
    192.168.45.4 from 192.168.45.4 (192.168.45.4)
      Origin IGP, metric 0, localpref 150, valid, external, best
      Community: 65524:1

Até logo!!!

Referências

http://babarata.blogspot.com.br/2010/05/bgp-atributo-community.html

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_6-2/bgp_communities.html

http://www.rfc-editor.org/rfc/rfc1997.txt