Author: Diego Dias

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

The Art of Network Hunter (pt.2) – The Snitch PCAP!

Diego DiasLeave a comment

por DanielOI*

Na primeira parte do post, conseguimos realizar a identificarão do ataque, conforme a conclusão do post a máquina 172.30.200.50 está infectada com um malware que responsável pela realização de requisições externas para o domínio www.gtishare.com [223.25.233.248].

Uma vez que identificamos o “paciente 0”, precisaremos entender tudo o que aconteceu pós infecção para tentarmos traçar uma timeline de eventos. O Primeiro passo é realizar uma rápida analise do report gerado no Hybrid Analysis [ https://goo.gl/62xumA ].

Aparentemente, o arquivo é apenas um PDF, como pode ser visto, ele foi aberto normalmente na máquina sandbox.

Porém ao analisarmos os processos, podemos verificar que o arquivo PDF aberto, realiza uma chamada para mais 2 executáveis, o “a.exe “, que por sua vez chama e o trojan.exe [nome um tanto quando sugestivo], que por fim realiza uma call para o netsh.exe.

Aparentemente o trojan.exe realiza uma chamada para o netsh com a intenção de colocar seu executável na whitelist do firewall da máquina da vítima.

Após isso é possível verificar que a máquina realiza diversas requisições para o domínio do atacante, isso pode significar algumas coisas como: acesso remoto diretamente a máquina da vítima, execuções de comandos remoto na máquina alto e etc.

Agora que sabemos basicamente as ações que o malware realiza na máquina da vítima utilizaremos comando tcpdump no arquivo PCAP para procurar de inconsistências nas requisições, como execução de comandos remotos, menções a arquivos estranhos, pacotes com dados encodados, movimentações laterais entre outras coisas.

Conforme imagem abaixo, podemos verificar algumas anomalias durante a troca de pacotes como a trocas de requisições encodadas em base64 ocorrendo da rede local para a internet .

Se efetuarmos uma tratativa básica de uma amostra para uma análise para decodar o encode, é possível ver claramente que o atacante está executando comandos remotamente na máquina da vítima.

Agora que sabemos como o atacante estava encodando suas ações na rede através da amostra retirada, basta parsear e tratar o arquivo pcap para descobrir todos os atos que o atacante realizou no computador da vítima.

Após a tratativa do PCAP, foi constatado que o arquivo com os ações realizadas pelo atacante contém mais de 1900 linhas entre execuções e retorno de comandos.

Vamos analisar o que o atacante fez de interessante na máquina da 
vítima

1 – Enumeração de usuário

2 – Enumeração dos administradores locais e do domínio

3 – Enumeração dos diretórios de rede

4 – Execução do binário x64.exe

5 – Copia de 2 arquivos o “ninikatz.ps1” e o “dllhost.exe”

A. ninikatz.ps1 -> Analisando o arquivo, foi possível validar que tratava-se do mimikatz

B. dllhost.exe -> Analisando o arquivo, foi possível validar que tratava-se do putty

O atacante usou o arquivo dll.exe para realizar a criação de um túnel entre a máquina da vítima e servidor do atacante, assim possibilitando um acesso remoto a máquina

6. Acesso do servidor DC1

7. Acesso do FileSever

8. Utilização de uma aplicação hotfix.dat (como pode ser visto, na segunda linha, trata-se de um rar) para comprimir os arquivos. Repare que ele salvou os arquivos como “logo.png”

→ Evidência que o logo.png e o logo2.png são arquivos compactados .rar .

9. Realização do mesmo procedimento em outro diretório, criando o logo2.png

10. Copia de um arquivo email.aspx (webshell) para o servidor ISS

11. Copia dos arquivos rar [logo.png e logo2.png] para o servidor ISS exfiltrando-os posteriormente

12. Remoção dos rastros

13 – Arquivos vazados (Exemplo)

Conclusão.

Após realizamos uma análise completa do arquivo PCAP, nós formos capazes de realizar a recriação dos detalhes do ataque sofrido pela corporação, como:

→ Identificar a origem do ataque;
→ Identificar qual foi o host infectado pelo ataque;
→ Identificar como o host foi infectado;
→ Identificar o arquivo malicioso utilizado para a realização do ataque;
→ Realizar a extração e análise do malware utilizado no ataque;
→ Constatar que o atacante realmente realizou um acesso não autorizado a rede interna da corporação;
→ Constatar como o atacante realizou o acesso não autorizado;
→ Verificar quais foram as ações tomadas pelo atacante durante o acesso não autorizado ao host infectado, como:
⇒ Enumeração de usuários;
⇒ Dump de credenciais de ao menos um usuário;
⇒ Acesso não autorizado servidores de arquivos;
⇒ exfiltração de dados;
→ Constatar as máquinas internas que o atacante realizou acesso durante o ataque;
→ Constatar que o atacante realizou a criação de WebShell em um servidor
→ Constatar que o servidor quem que o WebShell foi instalado, foi utilizado para realizar a extração dos dados.

Como todas essas informações do expostas é possível verificar o quão é importante para as corporações sempre realizar a análise e manutenção dos logs de rede, bem como sempre contar com profissionais preparados e capacitados para realização desses tipos de serviço.

IKE Fase 1: Resumo

Diego DiasLeave a comment

Quando você está tentando fazer a uma conexão segura entre 2 hosts através da Internet, um caminho seguro deverá ser estabelecido, como por exemplo, por uma conexão VPN IPSec. Além dos mecanismos de autenticação e validação da informação a VPN IPSec necessita de um mecanismo eficiente de gestão de chaves.

O processo de gestão de chaves diz respeito à criação, eliminação e alteração das chaves. A implementação de uma solução VPN IPSec  utliza-se de um processo de criptografia que envolve uma periódica troca de chaves, embora o IPSec não integre um mecanismo de gestão de chaves, o IETF definiu como norma de gestão o protocolo híbrido ISAKMP/Oakley também denominado IKE, Internet Key Exchange para autenticar os dispositivos e  gerar as chaves criptografadas. O protocolo IKE utiliza o termo security association (SA), que é um acordo entre os equipamentos pares para troca de tráfego IPSec utilizando os requerimentos necessários para estabelecer as proteções aplicadas em uma conexão.

No estabelecimento de uma comunicação segura, passa-se pelas seguintes fases IKE:

Fase 1: Ocorre num meio inseguro. Tem o objetivo de estabelecer um canal seguro que irá proteger as trocas da Fase 2. É executada uma vez para várias fases 2;
Fase 2: Ocorre no canal seguro criado na fase 1. As suas negociações têm o objetivo de estabelecer as associações de segurança que irão proteger a comunicação.

Após estas duas fases, encontra-se estabelecido um canal seguro através do qual ocorre comunicação segura. Nesse post abordaremos apenas a Fase 1.

IKE Fase 1

A principal finalidade dessa primeira troca é permitir que os equipamentos finais consigam definir os parâmetros SA para estabelecer um canal seguro para futuramente estabelecer uma conexão IPSec. Tal canal é chamado IKE SA. Esse canal tem a função de criar criptografia e autenticação bidirecional para as outras trocas IKE e passagem de pacotes IPSec.

O IKE SA pode ser realizado de duas formas:

  • Modo Principal (Main Mode): negocia a criação da conexão através da troca de três pares de mensagem.
    • A primeira troca de mensagens é relativa as formas de criptografia, autenticação (escolha dos algoritmos) e criação de chaves assimétricas.
    • A segunda troca de mensagens utiliza o algoritmo Diffie-Hellman para trocas das chaves criadas, da assinatura digital ou da chave pública, de acordo com os parâmetros definidos.
    • O terceiro par de mensagens verifica a identidade do outro lado. O valor de identidade é o endereço IP do par IPSec na forma criptografada. A principal  função do main mode é combinar IKE SA (security association)  entre os pares para fornecer uma conexão protegidas para posteriores trocas ISAKMP entre os peers IKE. O IKE SA especifica valores para a troca IKE: o método de autenticação usado, a criptografia, os algoritmos de hash, o grupo Diffie-Hellman (DH) utilizado, a vida útil do IKE SA em segundos ou quilobytes, e os valores de chaves secretas compartilhadas para os algoritmos de criptografia. O IKE SA em cada par é bi-direcional.
  • Modo Agressivo(Agressive Mode): é uma alternativa mais rápida ao modo principal, já que negocia a criação IKE SA através de três mensagens, ao invés de três pares de mensagens. A primeira mensagem de um dos extremos manda os parâmetros de segurança, juntamente com sua porção da chave criada por Diffie-Hellman e sua identidade. O outro extremo envia sua parte da chave, parâmetros de segurança e sua autenticação (geralmente por assinatura digital). Na última mensagem o primeiro extremo envia sua autenticação ao outro. Com essas três mensagens a conexão IKE SA está criada. Se ganha em velocidade, mas perde-se em segurança, por exemplo, as chaves podem ser interceptadas e forjadas.

No cenário abaixo, utilizando o Cisco IOS como exemplo, com o estabelecimento de uma conexão segura entre roteadores de uma empresa para uma VPN IPsec, em vez de negociarmos cada protocolo para criptografia, autenticação, etc , individualmente; podemos agrupar os protocolos em conjunto de politicas IKE (IKE policy).

O comando crypto isakmp policy define o IKE Fase 1, com os parâmetros utilizados durante a negociação. A sintaxe do comando crypto isakmp policy “priority” define a prioridade da policy. Caso os valores de criptografia, hash, DH e lifetime não sejam configurados, serão escolhidos os valores default (des, sha, rsa-sig, 1 e 86400 respectivamente).

Para configurar a pre-shared key (PSK) utilize a sintaxe:

 crypto isakmp key “tipo de cifragem da senha na configuração”  senha hostname/ address endereço.

Nos próximos posts daremos continuidade no script para a Fase 2 e modos IPSec.

Referência

http://www.gta.ufrj.br/grad/08_1/vpn/ipsecelementos.html#_Toc200023677

http://civil.fe.up.pt/acruz/Mi99/asr/IPSec.htm

Implementing Cisco IOS Network Security , Cisco press – Catherine Paquet
Network Security Technologies and Solutions, Cisco press – Yusuf Bhaiji

The Art of Network Hunter (pt.1) – PCAPs don’t lie!

Diego DiasLeave a comment

por DanielOI*

Na época que eu era Consultor de Segurança, fiz um curso ministrado por uma galera muito legal da RSA sobre uma solução interessante, o RSA NetWitness.

O NetWitness é uma ferramenta é muito poderosa e capaz de armazenar e fazer analises avançadas de tráfego de rede, mostrando de maneira “visível” as comunicações que estão acontecendo na rede corporativa, através de parsers criados em LUA script.

Essencialmente o NetWitness possui 2 módulos principais, NetWitness for Packets [ https://goo.gl/a1xk4H ] e NetWitness for Logs [ https://goo.gl/icv6Df ], o curso que fiz com meu amigo Xopis [ recomendo -> https://goo.gl/GtP3WC ] foi quase que inteiramente sobre o NetWitness for Logs, porém logo percebi que a parte divertida e que eu realmente iria me interessar do NetWitness, era o NetWitness “for Packets“, devido a sua maleabilidade no tratamento de pacotes de rede.

Durante esse curso eu escutei um termo muito legal, que fazia parte do meu cotidiano diário mas eu nem fazia ideia: “Network Hunter”

– Mas agora, o que é um Network Hunter?

O “Network Hunter” vai ser basicamente o profissional responsável por realizar a análise dos tráfegos de redes, sempre a procura de comportamentos anômalos, vazamentos de informações sensíveis a corporação, timeline, ataques de rede, resposta a incidente e etc.

Geralmente o NetHunter vai ter uma ênfase na identificarão e investigação de comportamentos maliciosos na rede com o intuito de prevenir ataques a corporação.

Alguns colaboradores da Symantec fizeram alguns artigos bem legais sobre algumas ameaças e como elas funcionam. Não vou me estender muito sobre, pois os artigos são públicos, eles foram divido em três partes :

• Parte 1 – Viruses and worms [ https://goo.gl/XpmZWa ]
• Parte 2 – Trojans and- other threats [ https://goo.gl/G5fEcW ]
• Parte 3 – Various types network attacks [ https://goo.gl/y951x4 ]

Eu realizei algumas pesquisas sobre do tema em questão, porém não encontrei muita coisa “prática” sobre o tema. Por isso, resolvi criar um post com o intuito de passar um pouco da ideia de como pode funcionar uma identificação de um ataque através da aplicação de técnicas de forense em rede/análise de pcap , mostrando que essas técnicas podem ser perfeitamente usadas para operações continuas, análise de ameaças e resposta a incidente e PRINCIPALMENTE JOGOS DE CTF.

Para esse post eu irei analisar um pcap que ganhei do pessoal da RSA durante o curso que fiz.

A Forbes fez um post sobre os 5 principais tipos de ataques que as empresas costumam sofrer [ https://goo.gl/5AiNfk ] e segundo eles, os ataques mais comuns realizados nas empresas são através de Malware/Ransomware. Partindo desse pressuposto, podemos dar início a nossa análise.

O primeiro passo da análise é identificar as principais extensões de arquivos maliciosos usados por atacantes. Nos links abaixo é possível verificar as extensões utilizadas em ataques em redes que utilizam plataforma Windows:

• File types and extensions that are common threat vectors in email attachments [ https://goo.gl/rCXrwS ]
• File Extensions That Are Potentially Dangerous on Windows [ https://goo.gl/psCX59 ]

Utilizando os link informados, você poderá gerar um arquivo de texto com algumas extensões maliciosas para facilitar os seus filtros durante sua análise.

Extensões de arquivos

Para agilizar todo o processo, iremos realizar as buscas somente com as principais extensões utilizadas pelos atacantes como .exe, .msi, .bat e .ps1. Antes de começar a realizar a forense no arquivo, você precisa verificar o tipo de arquivo que você irá analisar, conforme abaixo.

Detalhes do artefato

Para realizar essas verificações, você precisará utilizar o comando file, ele é o responsável por determinar o tipo de arquivo que você vai analisar. Conforme o retorno do comando, é possível validar que a forense irá ser realizada em um arquivo de dump de rede com o tamanho de 6.9GB.

Para realizar analise de arquivos com extensão .pcap, você pode usar ferramentas como:

• RSA NetWitness [ Pago ]
• tcpdump
• Wireshark
• Windump
• tshark
• Network Miner
• Fiddler
• Capsa
• nfcapd; nfpcapd; nfdump

No post, iremos utilizar somente o tcpdump e o Wireshark visto que eles são opensource. O primeiro comando que nós iremos utilizar será o tcpdump.

Filtrando filetype

O comando utilizado vai realizar uma busca com alguns filtros [ .exe | .msi | .bat | .ps1 ] no arquivo .pcap e redirecionar a saída para um arquivo de texto.

Após o termino do comando, você deverá realizar uma analise a procura de coisas anômalas no arquivo de texto como a imagem abaixo. Analisando a saída do arquivo, somente um arquivo incoerente foi encontrado, o “resume.pdf.exe”

Arquivo suspeito

Voltando para o arquivo PCAP, é possível verificar que o host 172.30.200.50 realizou um HTTP/GET para o IP 223.25.233.248 baixando o arquivo “resume.pdf.exe”. Renomear arquivos com outras extensões com o intuito de enganar as vítimas é uma pratica é muito comum entre os atacantes, logo tornando o arquivo “resume.pdf.exe” uma ameaça em potencial.

Filtrando arquivo suspeito

O próximo passo é realizar a extração do arquivo “resume.pdf.exe” do pcap. Para facilitar e agilizar o trabalho, você pode utilizar o tcpdump para isolar os pacotes oriundos dos hosts 172.30.200.50 e 223.25.233.248.

Isolando a origem do arquivo

Para isolar os hosts, você só precisa utilizar a opção “host” para filtrar o IP algo e o “-w” para gerar outro arquivo .pcap. Com os arquivos exponencialmente menores, fica mais fácil trata-los utilizando o wireshark. O Wireshark foi utilizado para realizar a extração do arquivo “resume.pdf.exe” e validarmos se o mesmo é malicioso ou somente um falso positivo.

Para realizar a extração, você deve ir em “File > Export Objects”.

Extraindo o arquivo suspeito

Uma vez que o arquivo foi extraído, você poderá realizar o procedimento anterior com o comando “file” para verificar o tipo de arquivo.

Detalhes do arquivo

Como pode ser visto, o “resume.pdf.exe” é um executável de 32bits para plataforma Windows e não um pdf. Você pode realizar um scan online para validar se o executável é ou um malware, no caso o site utilizado foi o https://www.virustotal.com e no https://www.hybrid-analysis.com

• Vírus Total -> https://goo.gl/hxwEN5

• Hybrid Analysis -> https://goo.gl/62xumAH

• Hybrid Analysis -> https://goo.gl/62xumAH

Como é possível verificar, o arquivo resume.pdf.exe foi identificado como um arquivo malicioso em ambos os sites.

Conclusão.

Até o momento é possível concluir que máquina 172.30.200.50 está possivelmente infectada com um malware que conforme análise do Hybrid Analysis, realiza requisições externas para o domínio www.gtishare.com [223.25.233.248].

Na segunda parte deste post, vamos realizar uma análise detalhada sobre quais ações o atacante fez após a vítima fazer o download do malware.