Mudanças entre as edições de "UTRS Registro e Configuracao"

De Wiki BPF
Ir para navegação Ir para pesquisar
(Texto inicial do artigo)
 
(Ajuste de configuração no exemplo Huawei)
 
(20 revisões intermediárias pelo mesmo usuário não estão sendo mostradas)
Linha 1: Linha 1:
−
=== Introdução ===
+
== Introdução ==
−
O U.T.R.S (Unwanted Traffic Removal Service) é um serviço colaborativo provido de forma gratuita pelo Team Cumry e que tem como objetivo auxiliar na mitigação de grandes ataques DDoS através do uso do protocolo BGP por parte dos participantes. Uma vez estabelecida a sessão BGP entre o participante e o UTRS o participante é capaz de realizar anúncios de partes dos prefixos de seu ASN para que esses anúncios sejam encaminhados à todos os outros participantes (ISPs, Empresas de Hospedagem de Conteúdos, etc) e esses deixem de enviar tráfego para o(s) IP(s) anunciados. Desta forma caso algum cliente de banda larga ou servidor hospedados em qualquer das organizações participantes que possa estar sendo fonte de ataques contra o ASN vítima deixará de enviar esse tráfego que será bloqueado na origem não chegando à vítima. Em outras palavras funciona como um blackhole distribuído onde diversos backbones recebem os anúncios e instalam essas rotas evitando assim que qualquer tráfego originado ali não alcance o destino do ataque.
+
[[Arquivo:Logo-UTRS.png|borda|direita|semmoldura|256x256px]]
 +
O [https://team-cymru.com/community-services/utrs/ U.T.R.S] (Unwanted Traffic Removal Service) é um serviço colaborativo provido de forma gratuita pelo [https://team-cymru.com/ Team Cymru] e que tem como objetivo auxiliar na mitigação de grandes ataques DDoS através do uso do protocolo BGP pelos participantes.
  
−
Isso permite à vítimas de ataque conseguirem reduzir de maneira significativa o tamanho do ataque através da colaboração de centenas de outros backbones que deixarão de enviar tráfego para o(s) IP(s) reportados para o serviço.
+
Uma vez estabelecida a sessão BGP com o UTRS, o participante se torna capaz de anunciar parte dos prefixos do seu AS para o URTS, que encaminhará os anúncios recebidos à todos os outros participantes (ISPs, Empresas de Hospedagem de Conteúdos, etc), que por sua vez, deixarão de enviar tráfego para o(s) IP(s) anunciados. Assim, caso algum cliente dos participantes (assinante de banda larga ou servidor de hospedagem, por exemplo) esteja gerando ataques contra o ASN vítima, este deixará de enviar esse tráfego aos IPs das vítimas, pois o tráfego será bloqueado na origem.  
  
−
Com o aumento dos casos de ataques DDoS devido à diferentes motivos é importante que os Sistemas Autônomos possam contar com todas as ferramentas possíveis que possam auxiliar durante a mitigação ou redução do tamanho desses ataques.O que torna o uso do UTRS ainda mais interessante
+
Em outras palavras funciona como um '''blackhole distribuído''', onde diversos backbones recebem os anúncios e instalam essas rotas descartando assim que qualquer tráfego originado ali para que não alcance o destino do ataque. Para mais informações consulte IETF [[rfc:3882/|RFC 3882]] Configuring BGP to Block Denial-of-Service Attacks.
  
−
É importante mencionar que o uso do UTRS sozinho não visa ser uma ferramenta definitiva na resolução de todos os tipos de ataques DDoS, mas um complemento poderoso na redução dos tráfego direcionado principalmente os IPs não utilizados de um Sistema Autônomo sob ataque. É importante ter também outras ferramentas de mitigação para tratar diferentes tipos de ataques sejam internamente dentro do backbone ou em nuvem. A combinação do uso dessas ferramentas é a maneira mais efetiva de lidar com os problemas gerados por esses ataques.
+
Isso permite às organizações vítimas de ataque conseguirem reduzir de maneira significativa o tamanho do ataque através da colaboração de centenas de outros backbones que deixarão de enviar tráfego para o(s) IP(s) reportados para o serviço.
  
−
Cada novo Sistema Autônomo que se torna um usuário do UTRS além possuir uma opção à mais de proteção à si mesmo, colabora com os demais e principalmente evita que tráfego de ataques destinados à outras redes e originados no seu backbone sejam encaminhados através de algum dos seus upstreams causando assim aumento de custos com a maior utilização de circuitos de transporte e trânsito e da capacidade de processamento e encaminhamento de equipamentos.
+
Com o aumento dos casos de ataques DDoS devido à diferentes motivos é importante que os Sistemas Autônomos possam contar com todas as ferramentas possíveis que possam auxiliar durante a mitigação ou redução do tamanho desses ataques. O que torna o uso do UTRS ainda mais interessante
  
−
=== Registro no UTRS ===
+
É importante mencionar que o uso do UTRS sozinho não visa ser uma ferramenta definitiva na resolução de todos os tipos de ataques DDoS, mas um complemento poderoso na redução dos tráfego direcionado principalmente à IPs não utilizados de um Sistema Autônomo sob ataque. É importante ter também outras ferramentas de mitigação para tratar diferentes tipos de ataques sejam internamente dentro do backbone ou em nuvem. A combinação do uso dessas ferramentas é a maneira mais efetiva de lidar com os problemas gerados por esses ataques.
 +
 
 +
Cada novo Sistema Autônomo que se torna um usuário do UTRS além possuir uma opção à mais de proteção à si mesmo, colabora com todos os demais e principalmente evita que tráfego de ataques destinados à outras redes e originados no seu backbone sejam encaminhados através de algum dos upstreams causando assim uma possível redução de custos com a menor utilização de circuitos de transporte e trânsito e da capacidade de processamento e encaminhamento de equipamentos.
 +
 
 +
O Team Cymru aplica filtros na sessão BGP para garantir que '''apenas os prefixos do próprio Sistema Autônomo''' possam ser anunciados. Está no roadmap do UTRS permitir também o anúncio de prefixos de Downstreams possibilitando assim que Upstreams de Trânsito possam anunciar também prefixos de seus clientes para auxiliá-los durante episódios de ataques.
 +
 
 +
== UTRS no Brasil ==
 +
O UTRS já é utilizado por centenas de redes Brasileiras o que ajuda a reduzir o tráfego de ataques originados no Brasil.
 +
 
 +
Isso é especialmente importante visando reduzir o tráfego de entrada provenientes de ataques que chegam através da conexão do Sistema Autônomo com o IX.br já que no momento os Route Servers não permitem anúncios de blackhole. Isso é válido não apenas para o IX-SP mas para qualquer outro IX do projeto IX.br. Essa possibilidade aliada ao uso de communities de blackhole disponibilizadas por empresas de Trânsito IP se somam no sentido da redução do tráfego que chega ao ISP durante o ataque.
 +
 
 +
Se o Sistema Autônomo o qual você é responsável já é participante do UTRS encaminhe este artigo para seus colegas que são responsáveis por outras redes Brasileiras ou Upstreams convidando-os a se tornarem participantes também. Quanto maior o número de redes, mais efetivo é o efeito na redução do tráfego de ataque originado em cada uma dessas redes.
 +
 
 +
== Registro no UTRS ==
 +
[[Arquivo:Formulario-registro-UTRS.png|miniaturadaimagem]]
 
Para se tornar um usuário do UTRS os participantes necessitarão fornecer as seguintes informações:
 
Para se tornar um usuário do UTRS os participantes necessitarão fornecer as seguintes informações:
 
* Nome e Sobrenome do responsável
 
* Nome e Sobrenome do responsável
−
* Endereço de Email que será inscrito na Lista de Discussão do UTRS
+
* Endereço de Email que será inscrito na Lista de Email do UTRS
 
* Nome da Empresa/Organização
 
* Nome da Empresa/Organização
 
* Número de Sistema Autônomo (ASN)
 
* Número de Sistema Autônomo (ASN)
 
* Endereço IP de Peering (normalmente IP de Loopback ou de Interface)
 
* Endereço IP de Peering (normalmente IP de Loopback ou de Interface)
−
Nota 1: O IP de Peering deve ser um IP anunciado para Internet ou ao menos para o ASN do Team Cumry.
+
Nota 1: O IP a ser utilizado na sessão de Peering deve aparecer como um IP único anunciado pelo seu ASN. Verifique no whois.cymru.com se o IP aparece como anunciado para seu ASN. Também é possível verificar em https://asn.cymru.com/
  
−
Nota 2: Todas as requisições serão verificadas com o administrador dos Sistema Autônomos solicitantes, portante certifique-se que o endereço cadastrado no Whois do seu ASN seja acessível.
+
Nota 2: Todas as requisições serão verificadas com o administrador do Sistema Autônomo solicitante, portanto certifique-se que o endereço de email cadastrado no Whois do seu ASN seja acessível.
  
−
==== Preenchimento do Formulário de Cadastro ====
+
=== Preenchimento do Formulário de Cadastro ===
 
# Acesse a URL - https://team-cymru.com/community-services/utrs/
 
# Acesse a URL - https://team-cymru.com/community-services/utrs/
 
# Clique em "Register for UTRS"
 
# Clique em "Register for UTRS"
Linha 27: Linha 42:
 
# Selecione "I am interested in both peering/receiving and populating the feed"
 
# Selecione "I am interested in both peering/receiving and populating the feed"
 
# Clique em Submit.
 
# Clique em Submit.
−
-= EM CONSTRUÇÃO =-
+
A solicitação será enviada para a equipe do Team Cymru que responderá posteriormente com uma confirmação e os detalhes para estabelecimento da sessão BGP. Para garantir que os emails referentes à esta tratativa sejam recebidos adicione o endereço '''utrsrequest@cymru.com''' à sua whitelist de email.
 +
 
 +
== Configuração dos Equipamentos ==
 +
As informações abaixo são padrão para todas as sessões e anúncios de rotas. Caso exista necessidade de customizar esses valores para adequar as suas necessidade contate a equipe do UTRS.
 +
* ASN to UTRS: 64496
 +
* Endereço IP para estabelecimento da sessão BGP com o UTRS: [disponibilizado durante o provisionamento]
 +
* TCP MD5 password: [disponibilizado durante o provisionamento]
 +
* Next-hop: 192.0.2.1
 +
* Community: NO_EXPORT
 +
* Community: 64496:0
 +
* Multihop
 +
* Passive
 +
É esperado que os participantes do UTRS realizem o descarte de qualquer tráfego direcionado à cada um dos prefixos recebidos na sessao BGP configurando o endereço de next-hop para apontar pra blackhole (e.g: interface null0).
 +
 
 +
A configurações abaixo são exemplos genéricos para diferentes equipamentos e plataformas e devem ser ajustadas em cada caso com detalhes e particularidades de cada participante com o uso de atributos únicos para cada sessão. É possível também aplicar políticas de import e export especificas à cada Sistema Autônomo.
 +
 
 +
=== Configuração Mikrotik ===
 +
<pre>
 +
# BGP instance setup
 +
  /routing bgp instance set default as=<YOUR_ASN> router-id=<WAN_IP_ADDRESS>
 +
 
 +
  # route filters - install these routes as black hole routes
 +
  # do NOT receive or announce anything else by default
 +
  /routing filter add action=accept bgp-communities=64496:0 chain=utrs-in prefix-length=0-32 comment="" disabled=no invert-match=no set-type=blackhole
 +
  /routing filter add action=discard chain=utrs-in comment="" disabled=no invert-match=no
 +
  /routing filter add action=discard chain=utrs-out comment="" disabled=no invert-match=no
 +
 
 +
  # UTRS peering session
 +
  /routing bgp peer add address-families=ip disabled=no in-filter=utrs-in instance=default multihop=yes name=UTRS out-filter=utrs-out passive=yes remote-address=<UTRS_IP_ADDRESS> remote-as=64496 tcp-md5-key=<UTRS_MD5_PASSWORD>
 +
 +
</pre>
 +
=== Configuração Cisco IOS ===
 +
<pre>
 +
! Do not generate ICMP unreachables or you may run out of CPU
 +
  ip interface Null0
 +
  no ip unreachables
 +
  !
 +
  router bgp 64496
 +
  neighbor W.X.Y.Z remote-as 64496
 +
  neighbor W.X.Y.Z ebgp-multihop 255
 +
  !
 +
  ! TCP MD5 passphrase provided at provisioning
 +
  neighbor W.X.Y.Z password ##SECRET-DATA
 +
  !
 +
  ! UTRS will initiate the active open
 +
  neighbor W.X.Y.Z transport connection-mode passive
 +
  !
 +
  ! by default only send RTBH tagged IPv4 /32 routes
 +
  neighbor W.X.Y.Z route-map utrs-out out
 +
  !
 +
  ! ensure /32-only prefixes, maybe reject "golden" prefixes
 +
  neighbor W.X.Y.Z route-map utrs-in
 +
  !
 +
  ! default UTRS next-hop, if you change it, make sure it forwards to null
 +
  ip route 192.0.2.1 255.255.255.255 null0
 +
  !
 +
  ! Beware of overwriting an existing ACL, or use an existing deny all
 +
  access-list 1 remark utility ACL to deny everything
 +
  access-list 1 deny any
 +
  !
 +
  ! match exactly IPv4 prefixes
 +
  ip prefix-list 32-only permit 0.0.0.0/0 ge 32
 +
  !
 +
  ! define RTBH community to tag your UTRS announcements, optional
 +
  ip community-list standard RTBH permit <your-as>:0
 +
  !
 +
  ! permit only IPv4 /32 prefixes from UTRS (see prefix-list above)
 +
  ! NOTE: you may wish to whitelist "golden" prefixes
 +
  ! NOTE: consider adding your own community when propagating internally
 +
  route-map utrs-in permit 10
 +
  match ip address prefix-list 32-only
 +
  !
 +
  ! default deny on UTRS updates in case UTRS leaks
 +
  route-map utrs-in deny 100
 +
  match ip address 1
 +
  !
 +
  ! only send UTRS IPv4 /32's with your RTBH community tag
 +
  route-map utrs-out permit 10
 +
  match ip address prefix-list 32-only
 +
  match community RTBH
 +
  !
 +
  ! do not send UTRS any routes by default
 +
  route-map utrs-out deny 100
 +
  match ip address 1
 +
</pre>
 +
=== Configuração Cisco IOS-XR ===
 +
<pre>
 +
! Do not generate ICMP unreachables or you may run out of CPU
 +
interface Null0
 +
  ipv4 icmp unreachables disable
 +
!
 +
router bgp <your-as>
 +
  neighbor W.X.Y.Z
 +
  remote-as 64496
 +
  ebgp-multihop 255
 +
  ! TCP MD5 passphrase provided at provisioning
 +
  password encrypted ##SECRET-DATA
 +
  ! UTRS will initiate the active open
 +
  session-open-mode passive-only
 +
  address-family ipv4 unicast
 +
    ! ensure /32-only prefixes, maybe reject "golden" prefixes
 +
    route-policy UTRS-in in
 +
    ! by default only send RTBH tagged IPv4 /32 routes
 +
    route-policy UTRS-out out
 +
!
 +
! default UTRS next-hop, if you change it, make sure it forwards to null
 +
router static
 +
  address-family ipv4 unicast
 +
  192.0.2.1/32  Null0
 +
!
 +
! define RTBH community to tag your UTRS announcements, optional
 +
community-set RTBH
 +
  <your-as>:0
 +
end-set
 +
!
 +
! permit only IPv4 /32 prefixes from UTRS (see prefix-list above)
 +
! NOTE: you may wish to whitelist "golden" prefixes
 +
! NOTE: consider adding your own community when propagating internally
 +
route-policy UTRS-in
 +
  if destination in (0.0.0.0/0 eq 32) then
 +
    ! possible direct drop here, no need for static route to Null0
 +
    ! set next-hop discard
 +
    done
 +
  endif
 +
  drop
 +
end-policy
 +
!
 +
! only send UTRS IPv4 /32's with your RTBH community tag
 +
route-policy UTRS-out
 +
  if destination in (0.0.0.0/0 eq 32) and community matches-any RTBH then
 +
    done
 +
  endif
 +
  drop
 +
end-policy
 +
</pre>
 +
=== Configuração IOS XE ===
 +
<pre>
 +
router bgp
 +
neighbor W.X.Y.Z remote-as 64496
 +
neighbor W.X.Y.Z description *** AS64496-V4-TEAMCYMRU-UTRS01 ***
 +
neighbor W.X.Y.Z ebgp-multihop 255
 +
neighbor W.X.Y.Z transport connection-mode passive
 +
neighbor W.X.Y.Z password 0
 +
neighbor W.X.Y.Z update-source Loopback0
 +
!
 +
address-family ipv4
 +
  neighbor W.X.Y.Z activate
 +
  neighbor W.X.Y.Z remove-private-as all
 +
  neighbor W.X.Y.Z soft-reconfiguration inbound
 +
  neighbor W.X.Y.Z route-map BGP-AS64496-V4-IN-CYMRUUTRS in
 +
  neighbor W.X.Y.Z route-map BGP-AS64496-V4-OUT-CYMRUUTRS out
 +
exit-address-family
 +
!
 +
ip community-list standard UTRS permit 64496:0
 +
ip community-list standard UTRS- permit :0
 +
!
 +
ip prefix-list 32-only permit 0.0.0.0/0 ge 32
 +
!
 +
ip route 192.0.2.1 255.255.255.255 null0
 +
!
 +
route-map BGP-AS64496-V4-OUT-CYMRUUTRS permit 10
 +
description IPv4 Filter UTRS learned from cymru.com route-servers
 +
match ip address prefix-list 32-only
 +
match community UTRS-
 +
set ip next-hop 192.0.2.1
 +
!
 +
route-map BGP-AS64496-V4-IN-CYMRUUTRS permit 10
 +
description IPv4 Filter UTRS learned from cymru.com route-servers
 +
match ip address prefix-list 32-only
 +
match community UTRS
 +
set ip next-hop 192.0.2.1
 +
!
 +
</pre>
 +
=== Configuração Juniper JUNOS ===
 +
<pre>
 +
routing-options {
 +
      static {
 +
          # UTRS default next-hop null route
 +
          route 192.0.2.1/32 {
 +
              discard;
 +
              retain;
 +
          }
 +
      }
 +
  }
 +
  protocols {
 +
      bgp {
 +
          group UTRS {
 +
              #
 +
              # enable multihop for remote UTRS peering
 +
              multihop;
 +
              #
 +
              local-as <your-asn>;
 +
              #
 +
              # UTRS peering address provided at provisioning
 +
              neighbor W.X.Y.Z {
 +
                  description "Team Cymru UTRS";
 +
                  #
 +
                  # allow UTRS to initiate the active open
 +
                  passive;
 +
                  #
 +
                  # import policy, see below
 +
                  import [ UTRS_in DENY_ALL ];
 +
                  #
 +
                  # MD5 passphrase provided at provisioning
 +
                  authentication-key <md5_password>;
 +
                  #
 +
                  # export policy, see below
 +
                  export [ UTRS_out DENY_ALL ];
 +
                  #
 +
                  # do not announce private ASNs
 +
                  remove-private;
 +
                  #
 +
                  # UTRS ASN
 +
                  peer-as 64496;
 +
              }
 +
          }
 +
      }
 +
  }
 +
  policy-options {
 +
      policy-statement UTRS_out {
 +
          term BLACKHOLE {
 +
              from {
 +
                  #
 +
                  # export self-tagged /32 routes only
 +
                  community <your-ibg-blackhole-community>;
 +
                  route-filter 0.0.0.0/0 prefix-length-range /32-/32;
 +
              }
 +
              then {
 +
                  #
 +
                  # remove local organization communities before announcing
 +
                  community delete <all-your-ibgp-communties>;
 +
                  #
 +
                  # add UTRS community to trigger blackholing
 +
                  community add UTRS_tag_out;
 +
                  #
 +
                  # add no-export community
 +
                  community add no-export;
 +
                  #
 +
                  # rewrite next-hop
 +
                  next-hop 192.0.2.1;
 +
                  #
 +
                  accept;
 +
              }
 +
          }
 +
      }
 +
      policy-statement UTRS_in {
 +
          term BLACKHOLE {
 +
              from {
 +
                  #
 +
                  # accept tagged /32 routes only
 +
                  community UTRS_tag_in;
 +
                  route-filter 0.0.0.0/0 prefix-length-range /32-/32;
 +
              }
 +
              then {
 +
                  # if required, depends on your configuration
 +
                  local-preference 200;
 +
                  #
 +
                  # remove company communities set by 3rd party
 +
                  community delete <all-your-ibgp-communites>;
 +
                  #
 +
                  # add your company community for blackholing within your iBGP
 +
                  community add <your-ibgp-blackhole-community>;
 +
                  #
 +
                  # rewrite next-hop
 +
                  next-hop discard;
 +
                  #
 +
                  accept;
 +
              }
 +
          }
 +
      }
 +
      policy-statement DENY_ALL {
 +
          then reject;
 +
      }
 +
      community UTRS_tag_in members 64496:0;
 +
      community UTRS_tag_out members <your-asn>:0;
 +
      community no-export members no-export;
 +
  }
 +
</pre>
 +
=== Configuração Huawei ===
 +
<pre>
 +
ip ip-prefix BGPv4-UTRS index 10 permit 0.0.0.0 0 greater-equal 32 less-equal 32
 +
 
 +
ip community-filter 5 index 10 permit 64496:0
 +
ip community-filter 5 index 20 permit no-export
 +
ip community-filter 6 index 10 permit <YOUR_ASN>:0
 +
 
 +
route-policy BGPv4-Import-UTRS permit node 5
 +
if-match ip-prefix BGPv4-UTRS
 +
if-match community-filter 5
 +
apply ip-address next-hop 192.0.2.1
 +
 
 +
ip route-static 192.0.2.1 255.255.255.255 NULL0
 +
 
 +
route-policy BGPv4-Export-UTRS permit node 5
 +
if-match ip-prefix BGPv4-UTRS
 +
if-match community-filter 6
 +
apply ip-address next-hop 192.0.2.1
 +
 
 +
#BGP Session configuration
 +
peer W.X.Y.Z as-number 64496
 +
peer W.X.Y.Z description CYMRU-UTRS
 +
peer W.X.Y.Z ebgp-max-hop 255
 +
peer W.X.Y.Z connect-interface Loopback0
 +
peer W.X.Y.Z password simple <UTRS_MD5_PASSWORD>
 +
peer W.X.Y.Z enable
 +
peer W.X.Y.Z route-policy BGPv4-Import-UTRS import
 +
peer W.X.Y.Z route-policy BGPv4-Export-UTRS export
 +
peer W.X.Y.Z advertise-community
 +
peer W.X.Y.Z advertise-ext-community
 +
</pre>
 +
 
 +
=== Configuração FRR ===
 +
<pre>
 +
ip route 192.0.2.1/32 Null0
 +
 
 +
router bgp <your-asn>
 +
neighbor IP remote-as 64496
 +
neighbor IP description "UTRS TEAM CYMRU"
 +
neighbor IP password <md5-password>
 +
neighbor IP passive
 +
neighbor IP ebgp-multihop 255
 +
neighbor IP update-source <your-ip-address>
 +
 
 +
address-family ipv4 unicast
 +
  neighbor IP remove-private-AS all
 +
  neighbor IP soft-reconfiguration inbound
 +
  neighbor IP route-map UTRS-IN in
 +
  neighbor IP route-map UTRS-OUT out
 +
 
 +
ip prefix-list 32-only seq 5 permit 0.0.0.0/0 ge 32
 +
bgp community-list standard UTRS permit 64496:0
 +
 
 +
route-map UTRS-IN permit 10
 +
match community UTRS
 +
match ip address prefix-list 32-only
 +
set ip next-hop 192.0.2.1
 +
 
 +
route-map UTRS-OUT permit 10
 +
match community YOUR-BLACKHOLE-COMMUNITY
 +
match ip address prefix-list 32-only
 +
set ip next-hop 192.0.2.1
 +
</pre>
 +
 
 +
=== Configuração BIRD ===
 +
<pre>
 +
filter bgp_in_utrs {
 +
    if (64496,0) ~ bgp_community && net.len = 32 then {
 +
        dest = RTD_BLACKHOLE;
 +
        accept;
 +
    }
 +
    else reject;
 +
}
 +
 
 +
filter bgp_out_utrs {
 +
    if  (xxxxx,666) ~ bgp_community && net.len = 32 && net_local() then {
 +
        bgp_community = -empty-;
 +
        bgp_community.add((xxxxx,0));
 +
        accept;
 +
    }
 +
    else reject;
 +
}
 +
 
 +
protocol bgp UTRS_BL {
 +
    description "UTRS Blackhole Service";
 +
    ipv4 {
 +
    import filter bgp_in_utrs;
 +
      export filter bgp_out_utrs;
 +
    };
 +
    multihop;
 +
    local <your-ip> as <your-asn>;
 +
    neighbor <utrs-ip> as 64496;
 +
    graceful restart;
 +
    password "<md5-password>";
 +
    passive;
 +
}
 +
</pre>
 +
== Perguntas Frequentes (FAQ) ==
 +
'''Qual é o custo do serviço ?'''
 +
 
 +
Nada. É um serviço gratuito. O Team Cymru aceita compartilhamento de dados ou doações que ajudem a manter este e outros serviços gratuitos.
 +
 
 +
'''Quais prefixos o UTRS anuncia atualmente ?'''
 +
 
 +
Geralmente, anúncios de rotas originados pelo UTRS são poucos, em média anunciam uma quantidade reduzida de endereços ou é possível haver momentos que nenhum prefixo será anunciado.
 +
 
 +
'''As rotas RTBH que o UTRS anuncia são públicas ?'''
 +
 
 +
As RTBH que forem aceitas e encaminhadas pelo UTRS são também anunciadas para toda a comunidade participante do UTRS em tempo real através das sessões BGP, porém elas não são disseminadas de maneira pública. Rotas que não passam na verificação podem estar sujeitas à revisão. O UTRS pode considerar publicar um resumo ou dados históricos para benefício público e para a comunidade de pesquisa no futuro.
 +
 
 +
'''Me ajude, estou sob ataque, o UTRS pode bloquear para mim ?'''
 +
 
 +
Se você representa uma organização que é um Sistema Autônomo e é capaz de provar que é autorizado a originar os anúncios dos prefixos em questão o UTRS poderá auxiliar. No entanto se você não possui qualquer tipo de contato prévio com o Team Cymru pode haver alguma demora para que possam ser realizadas todas as verificações necessárias.
 +
 
 +
'''Eu não tenho um ASN ou uso BGP, você pode bloquear algo para mim ?'''
 +
 
 +
Este serviço é disponibilizado apenas para operadores de BGP que possuam um número de Sistema Autônomo público, geralmente através de um Registro Regional da Internet (RIR).
 +
 
 +
'''Como o UTRS faz para verificar as redes conectadas ?'''
 +
 
 +
É possível que o UTRS já possua algum tipo de relacionamento com alguns potenciais participantes ou conhecer pessoal dessas organizações. No casos onde isso não ocorre geralmente os a solicitações de participação são verificadas através dos contatos registrados junto à base de dados Whois onde o ASN é registrado ou no [https://www.peeringdb.com/ Peering DB] (portanto [[PeeringDB - como se cadastrar e atualizar seus dados|mantenha seus dados de contato atualizados]]). Se o UTRs não for capaz de verificar os dados de contato utilizando essas bases de dados mais comuns outros métodos podem ser utilizados como consulta à base de dados públicas com com upstream do solicitante.
 +
 
 +
'''O UTRS recebe anúncios de rotas ou apenas os anuncia ?'''
 +
 
 +
Ambos, porém UTRS normalmente não origina esses anúncios. Os anúncios de rotas são iniciados pela comunidade de participantes através de anúncios BGP para o UTRS que realiza as verificações necessárias e os encaminha através de anúncios BGP para todos os outros participantes.
 +
 
 +
'''Quem decide quais prefixos são anunciados para os participantes do UTRS ?'''
 +
 
 +
Cada participante do UTRS pode anunciar prefixos /32 os quais estejam dentro de alguma das ranges de prefixos pertencentes ao próprio Sistema Autônomo. Nenhum participante do UTRS é capaz de anunciar rotas pertencentes à prefixos de outros participantes.
 +
 
 +
'''Como o UTRS verifica os anúncios ?'''
 +
 
 +
Todos os anúncios devem ser /32, caso contrário será automaticamente rejeitado. Também é utilizada a API do [https://stat.ripe.net/ RIPEstat]para analisar o histórico de rotas, origem e AS-Path. O peer deve ser o único originador ou upstream do prefixo que engloba o anúncio mais especifico.O peer também deve possuir um histórico de ter anunciado o prefixo que engloba aquela rota por pelo menos os últimos 30 dias. Se o anúncio não bater com esses critérios o encaminhamento desse anúncio não será realizado e um alerta interno poderá ser gerado e enviado para revisão interna.
 +
 
 +
'''Quais outras restrições de anúncios existem ?'''
 +
 
 +
A cada participante é permitido até 25 anúncios simultâneos à qualquer momento. Quantidades superiores serão rejeitadas. Um anúncio também expira após ficar ativo por 7 dias e será removido. O participante poderá anunciá-lo novamente caso necessário.
 +
 
 +
'''Posso anunciar rotas de blackhole dos meus clientes para o UTRS ?'''
 +
 
 +
No momento o UTRS apenas verifica os prefixos originados diretamente pelo próprio participante e não seus Downstreams. Esta é uma funcionalidade requisitada frequentemente e está nos planos do UTRS adicioná-la como parte do processo de verificação das rotas anunciadas para ser capaz de receber anúncios de blackhole de Downstreams dos participantes. No entanto um participante pode solicitar que alguma dessas rotas seja anunciada manualmente contatando a equipe do UTRS que fará uma revisão da solicitação.
 +
 
 +
'''O UTRS suporta BGP Flowspec ao invés de blackholes (RTBH) apenas ?'''
 +
 
 +
Atualmente UTRS é um serviço exclusivo para RTBH. Apesar da implementação BGP utilizada pelo UTRS suportar Flowspec o suporte à esta funcionalidade ainda é limitado em muitos casos e portanto esta funcionalidade não foi habilitada. Isso pode mudar caso houver demanda suficiente que justifique. Se isso é algo que interessa ao seu Sistema Autônomo entre em contato diretamente com o UTRS sinalizando neste sentido.
 +
 
 +
'''É possível customizar o ASN, next-hop e community tags ?'''
 +
 
 +
Tecnicamente sim, porém o UTRS considera que poucos casos necessitam esta mudança e prefere não fazer para poder manter a configuração o mais simples possível. É possível para cada participante modificar e alterar o next-hop or community tag em cada politica de import própria.
 +
 
 +
'''É necessário o uso de assinatura TCP MD5 (aka BGP password) ?'''
 +
 
 +
Sim.
 +
 
 +
'''Posso anunciar meus prefixos normalmente anunciados para outros peers e Trânsitos para o UTRS ?'''
 +
 
 +
Não. <u>Por favor não faça isso</u> ! Isso aumenta o trabalho dos sistemas do UTRS e esses anúncios serão ignorados, a mesmo claro que o anúncio seja um /32 o qual será encaminhado para os demais participantes realizarem o bloqueio. Se o UTRS constatar outras rotas que não sejam de blackhole a sessão BGP pode ser desligada.
 +
 
 +
'''Qual software é utilizado pelo UTRS ?'''
 +
 
 +
O UTRS utiliza o [https://github.com/Exa-Networks/exabgp/ ExaBGP], um software que possui uma implementação extensível de BGP e que permite uma nível interessante de customizações como as que o UTRS realiza.
 +
 
 +
'''Quais Sistemas Autônomos participam do UTRS ?'''
 +
 
 +
A lista de participantes do UTRS não é publicada porque nem todas as redes desejam que essa informação seja pública. No entanto os participantes do UTRS são capazes de saber quem são esses outros participantes assim como possuem a capacidade interagir com os demais através da Lista de Emails. Backbones dos mais variados tamanhos e regiões no mundo todo participam do UTRS.
 +
 
 +
'''Sou um participante do UTRS e necessito suporte, quem eu posso contatar ?'''
 +
 
 +
Participantes podem enviar um email para utrsrequest@cymru.com
 +
 
 +
'''Autor''': Fernando Frediani
 +
[[Categoria:Roteamento]]

Edição atual tal como às 15h02min de 4 de junho de 2020

Introdução

Logo-UTRS.png

O U.T.R.S (Unwanted Traffic Removal Service) é um serviço colaborativo provido de forma gratuita pelo Team Cymru e que tem como objetivo auxiliar na mitigação de grandes ataques DDoS através do uso do protocolo BGP pelos participantes.

Uma vez estabelecida a sessão BGP com o UTRS, o participante se torna capaz de anunciar parte dos prefixos do seu AS para o URTS, que encaminhará os anúncios recebidos à todos os outros participantes (ISPs, Empresas de Hospedagem de Conteúdos, etc), que por sua vez, deixarão de enviar tráfego para o(s) IP(s) anunciados. Assim, caso algum cliente dos participantes (assinante de banda larga ou servidor de hospedagem, por exemplo) esteja gerando ataques contra o ASN vítima, este deixará de enviar esse tráfego aos IPs das vítimas, pois o tráfego será bloqueado na origem.

Em outras palavras funciona como um blackhole distribuído, onde diversos backbones recebem os anúncios e instalam essas rotas descartando assim que qualquer tráfego originado ali para que não alcance o destino do ataque. Para mais informações consulte IETF RFC 3882 Configuring BGP to Block Denial-of-Service Attacks.

Isso permite às organizações vítimas de ataque conseguirem reduzir de maneira significativa o tamanho do ataque através da colaboração de centenas de outros backbones que deixarão de enviar tráfego para o(s) IP(s) reportados para o serviço.

Com o aumento dos casos de ataques DDoS devido à diferentes motivos é importante que os Sistemas Autônomos possam contar com todas as ferramentas possíveis que possam auxiliar durante a mitigação ou redução do tamanho desses ataques. O que torna o uso do UTRS ainda mais interessante

É importante mencionar que o uso do UTRS sozinho não visa ser uma ferramenta definitiva na resolução de todos os tipos de ataques DDoS, mas um complemento poderoso na redução dos tráfego direcionado principalmente à IPs não utilizados de um Sistema Autônomo sob ataque. É importante ter também outras ferramentas de mitigação para tratar diferentes tipos de ataques sejam internamente dentro do backbone ou em nuvem. A combinação do uso dessas ferramentas é a maneira mais efetiva de lidar com os problemas gerados por esses ataques.

Cada novo Sistema Autônomo que se torna um usuário do UTRS além possuir uma opção à mais de proteção à si mesmo, colabora com todos os demais e principalmente evita que tráfego de ataques destinados à outras redes e originados no seu backbone sejam encaminhados através de algum dos upstreams causando assim uma possível redução de custos com a menor utilização de circuitos de transporte e trânsito e da capacidade de processamento e encaminhamento de equipamentos.

O Team Cymru aplica filtros na sessão BGP para garantir que apenas os prefixos do próprio Sistema Autônomo possam ser anunciados. Está no roadmap do UTRS permitir também o anúncio de prefixos de Downstreams possibilitando assim que Upstreams de Trânsito possam anunciar também prefixos de seus clientes para auxiliá-los durante episódios de ataques.

UTRS no Brasil

O UTRS já é utilizado por centenas de redes Brasileiras o que ajuda a reduzir o tráfego de ataques originados no Brasil.

Isso é especialmente importante visando reduzir o tráfego de entrada provenientes de ataques que chegam através da conexão do Sistema Autônomo com o IX.br já que no momento os Route Servers não permitem anúncios de blackhole. Isso é válido não apenas para o IX-SP mas para qualquer outro IX do projeto IX.br. Essa possibilidade aliada ao uso de communities de blackhole disponibilizadas por empresas de Trânsito IP se somam no sentido da redução do tráfego que chega ao ISP durante o ataque.

Se o Sistema Autônomo o qual você é responsável já é participante do UTRS encaminhe este artigo para seus colegas que são responsáveis por outras redes Brasileiras ou Upstreams convidando-os a se tornarem participantes também. Quanto maior o número de redes, mais efetivo é o efeito na redução do tráfego de ataque originado em cada uma dessas redes.

Registro no UTRS

Formulario-registro-UTRS.png

Para se tornar um usuário do UTRS os participantes necessitarão fornecer as seguintes informações:

  • Nome e Sobrenome do responsável
  • Endereço de Email que será inscrito na Lista de Email do UTRS
  • Nome da Empresa/Organização
  • Número de Sistema Autônomo (ASN)
  • Endereço IP de Peering (normalmente IP de Loopback ou de Interface)

Nota 1: O IP a ser utilizado na sessão de Peering deve aparecer como um IP único anunciado pelo seu ASN. Verifique no whois.cymru.com se o IP aparece como anunciado para seu ASN. Também é possível verificar em https://asn.cymru.com/

Nota 2: Todas as requisições serão verificadas com o administrador do Sistema Autônomo solicitante, portanto certifique-se que o endereço de email cadastrado no Whois do seu ASN seja acessível.

Preenchimento do Formulário de Cadastro

  1. Acesse a URL - https://team-cymru.com/community-services/utrs/
  2. Clique em "Register for UTRS"
  3. Preencha os dados solicitados no formulário em nome da empresa/organização solicitante. Em "Enter IP address you request we peer with" recomenda-se utilizar o IP de Loopback do roteador).
  4. Selecione "I am interested in both peering/receiving and populating the feed"
  5. Clique em Submit.

A solicitação será enviada para a equipe do Team Cymru que responderá posteriormente com uma confirmação e os detalhes para estabelecimento da sessão BGP. Para garantir que os emails referentes à esta tratativa sejam recebidos adicione o endereço utrsrequest@cymru.com à sua whitelist de email.

Configuração dos Equipamentos

As informações abaixo são padrão para todas as sessões e anúncios de rotas. Caso exista necessidade de customizar esses valores para adequar as suas necessidade contate a equipe do UTRS.

  • ASN to UTRS: 64496
  • Endereço IP para estabelecimento da sessão BGP com o UTRS: [disponibilizado durante o provisionamento]
  • TCP MD5 password: [disponibilizado durante o provisionamento]
  • Next-hop: 192.0.2.1
  • Community: NO_EXPORT
  • Community: 64496:0
  • Multihop
  • Passive

É esperado que os participantes do UTRS realizem o descarte de qualquer tráfego direcionado à cada um dos prefixos recebidos na sessao BGP configurando o endereço de next-hop para apontar pra blackhole (e.g: interface null0).

A configurações abaixo são exemplos genéricos para diferentes equipamentos e plataformas e devem ser ajustadas em cada caso com detalhes e particularidades de cada participante com o uso de atributos únicos para cada sessão. É possível também aplicar políticas de import e export especificas à cada Sistema Autônomo.

Configuração Mikrotik

# BGP instance setup
  /routing bgp instance set default as=<YOUR_ASN> router-id=<WAN_IP_ADDRESS>

  # route filters - install these routes as black hole routes
  # do NOT receive or announce anything else by default
  /routing filter add action=accept bgp-communities=64496:0 chain=utrs-in prefix-length=0-32 comment="" disabled=no invert-match=no set-type=blackhole
  /routing filter add action=discard chain=utrs-in comment="" disabled=no invert-match=no
  /routing filter add action=discard chain=utrs-out comment="" disabled=no invert-match=no

  # UTRS peering session
  /routing bgp peer add address-families=ip disabled=no in-filter=utrs-in instance=default multihop=yes name=UTRS out-filter=utrs-out passive=yes remote-address=<UTRS_IP_ADDRESS> remote-as=64496 tcp-md5-key=<UTRS_MD5_PASSWORD>

Configuração Cisco IOS

! Do not generate ICMP unreachables or you may run out of CPU
  ip interface Null0
   no ip unreachables
  !
  router bgp 64496
   neighbor W.X.Y.Z remote-as 64496
   neighbor W.X.Y.Z ebgp-multihop 255 
   !
   ! TCP MD5 passphrase provided at provisioning
   neighbor W.X.Y.Z password ##SECRET-DATA
   !
   ! UTRS will initiate the active open
   neighbor W.X.Y.Z transport connection-mode passive
   !
   ! by default only send RTBH tagged IPv4 /32 routes
   neighbor W.X.Y.Z route-map utrs-out out
   !
   ! ensure /32-only prefixes, maybe reject "golden" prefixes
   neighbor W.X.Y.Z route-map utrs-in
  !
  ! default UTRS next-hop, if you change it, make sure it forwards to null
  ip route 192.0.2.1 255.255.255.255 null0
  !
  ! Beware of overwriting an existing ACL, or use an existing deny all
  access-list 1 remark utility ACL to deny everything
  access-list 1 deny any
  !
  ! match exactly IPv4 prefixes
  ip prefix-list 32-only permit 0.0.0.0/0 ge 32
  !
  ! define RTBH community to tag your UTRS announcements, optional
  ip community-list standard RTBH permit <your-as>:0
  !
  ! permit only IPv4 /32 prefixes from UTRS (see prefix-list above)
  ! NOTE: you may wish to whitelist "golden" prefixes
  ! NOTE: consider adding your own community when propagating internally
  route-map utrs-in permit 10
   match ip address prefix-list 32-only
  !
  ! default deny on UTRS updates in case UTRS leaks
  route-map utrs-in deny 100
   match ip address 1
  !
  ! only send UTRS IPv4 /32's with your RTBH community tag
  route-map utrs-out permit 10
   match ip address prefix-list 32-only
   match community RTBH
  !
  ! do not send UTRS any routes by default
  route-map utrs-out deny 100
   match ip address 1

Configuração Cisco IOS-XR

! Do not generate ICMP unreachables or you may run out of CPU
 interface Null0
  ipv4 icmp unreachables disable
 !
 router bgp <your-as>
  neighbor W.X.Y.Z
   remote-as 64496
   ebgp-multihop 255
   ! TCP MD5 passphrase provided at provisioning
   password encrypted ##SECRET-DATA
   ! UTRS will initiate the active open
   session-open-mode passive-only
   address-family ipv4 unicast
    ! ensure /32-only prefixes, maybe reject "golden" prefixes
    route-policy UTRS-in in
    ! by default only send RTBH tagged IPv4 /32 routes
    route-policy UTRS-out out
 !
 ! default UTRS next-hop, if you change it, make sure it forwards to null
 router static
  address-family ipv4 unicast
   192.0.2.1/32  Null0
 !
 ! define RTBH community to tag your UTRS announcements, optional
 community-set RTBH
   <your-as>:0
 end-set
 !
 ! permit only IPv4 /32 prefixes from UTRS (see prefix-list above)
 ! NOTE: you may wish to whitelist "golden" prefixes
 ! NOTE: consider adding your own community when propagating internally
 route-policy UTRS-in
   if destination in (0.0.0.0/0 eq 32) then
     ! possible direct drop here, no need for static route to Null0
     ! set next-hop discard
     done
   endif
   drop
 end-policy
 !
 ! only send UTRS IPv4 /32's with your RTBH community tag
 route-policy UTRS-out
   if destination in (0.0.0.0/0 eq 32) and community matches-any RTBH then
     done
   endif
   drop
 end-policy

Configuração IOS XE

router bgp 
 neighbor W.X.Y.Z remote-as 64496
 neighbor W.X.Y.Z description *** AS64496-V4-TEAMCYMRU-UTRS01 ***
 neighbor W.X.Y.Z ebgp-multihop 255
 neighbor W.X.Y.Z transport connection-mode passive
 neighbor W.X.Y.Z password 0 
 neighbor W.X.Y.Z update-source Loopback0
!
 address-family ipv4
  neighbor W.X.Y.Z activate
  neighbor W.X.Y.Z remove-private-as all
  neighbor W.X.Y.Z soft-reconfiguration inbound
  neighbor W.X.Y.Z route-map BGP-AS64496-V4-IN-CYMRUUTRS in
  neighbor W.X.Y.Z route-map BGP-AS64496-V4-OUT-CYMRUUTRS out
 exit-address-family
!
ip community-list standard UTRS permit 64496:0
ip community-list standard UTRS- permit :0
!
ip prefix-list 32-only permit 0.0.0.0/0 ge 32
!
ip route 192.0.2.1 255.255.255.255 null0
!
route-map BGP-AS64496-V4-OUT-CYMRUUTRS permit 10
 description IPv4 Filter UTRS learned from cymru.com route-servers
 match ip address prefix-list 32-only
 match community UTRS-
 set ip next-hop 192.0.2.1
!
route-map BGP-AS64496-V4-IN-CYMRUUTRS permit 10
 description IPv4 Filter UTRS learned from cymru.com route-servers
 match ip address prefix-list 32-only
 match community UTRS
 set ip next-hop 192.0.2.1
!

Configuração Juniper JUNOS

routing-options {
      static {
          # UTRS default next-hop null route
          route 192.0.2.1/32 {
              discard;
              retain;
          }
      }
  }
  protocols {
      bgp {
          group UTRS {
              #
              # enable multihop for remote UTRS peering
              multihop;
              #
              local-as <your-asn>;
              #
              # UTRS peering address provided at provisioning
              neighbor W.X.Y.Z { 
                  description "Team Cymru UTRS";
                  #
                  # allow UTRS to initiate the active open
                  passive;
                  #
                  # import policy, see below
                  import [ UTRS_in DENY_ALL ];
                  #
                  # MD5 passphrase provided at provisioning
                  authentication-key <md5_password>;
                  #
                  # export policy, see below
                  export [ UTRS_out DENY_ALL ];
                  #
                  # do not announce private ASNs
                  remove-private;
                  #
                  # UTRS ASN
                  peer-as 64496;
              }
          }
      }
  }
  policy-options {
      policy-statement UTRS_out {
          term BLACKHOLE {
              from {
                  #
                  # export self-tagged /32 routes only
                  community <your-ibg-blackhole-community>;
                  route-filter 0.0.0.0/0 prefix-length-range /32-/32;
              }
              then {
                  #
                  # remove local organization communities before announcing
                  community delete <all-your-ibgp-communties>;
                  #
                  # add UTRS community to trigger blackholing
                  community add UTRS_tag_out;
                  #
                  # add no-export community
                  community add no-export;
                  #
                  # rewrite next-hop
                  next-hop 192.0.2.1;
                  #
                  accept;
              }
          }
      }
      policy-statement UTRS_in {
          term BLACKHOLE {
              from {
                  #
                  # accept tagged /32 routes only
                  community UTRS_tag_in;
                  route-filter 0.0.0.0/0 prefix-length-range /32-/32;
              }
              then {
                  # if required, depends on your configuration
                  local-preference 200;
                  #
                  # remove company communities set by 3rd party
                  community delete <all-your-ibgp-communites>;
                  #
                  # add your company community for blackholing within your iBGP
                  community add <your-ibgp-blackhole-community>;
                  #
                  # rewrite next-hop
                  next-hop discard;
                  #
                  accept;
              }
          }
      }
      policy-statement DENY_ALL {
          then reject;
      }
      community UTRS_tag_in members 64496:0;
      community UTRS_tag_out members <your-asn>:0;
      community no-export members no-export;
  }

Configuração Huawei

ip ip-prefix BGPv4-UTRS index 10 permit 0.0.0.0 0 greater-equal 32 less-equal 32

ip community-filter 5 index 10 permit 64496:0
ip community-filter 5 index 20 permit no-export
ip community-filter 6 index 10 permit <YOUR_ASN>:0

route-policy BGPv4-Import-UTRS permit node 5
 if-match ip-prefix BGPv4-UTRS
 if-match community-filter 5
 apply ip-address next-hop 192.0.2.1

ip route-static 192.0.2.1 255.255.255.255 NULL0

route-policy BGPv4-Export-UTRS permit node 5
 if-match ip-prefix BGPv4-UTRS
 if-match community-filter 6
 apply ip-address next-hop 192.0.2.1

#BGP Session configuration
peer W.X.Y.Z as-number 64496
peer W.X.Y.Z description CYMRU-UTRS
peer W.X.Y.Z ebgp-max-hop 255
peer W.X.Y.Z connect-interface Loopback0
peer W.X.Y.Z password simple <UTRS_MD5_PASSWORD>
peer W.X.Y.Z enable
peer W.X.Y.Z route-policy BGPv4-Import-UTRS import
peer W.X.Y.Z route-policy BGPv4-Export-UTRS export
peer W.X.Y.Z advertise-community
peer W.X.Y.Z advertise-ext-community

Configuração FRR

ip route 192.0.2.1/32 Null0

router bgp <your-asn>
 neighbor IP remote-as 64496
 neighbor IP description "UTRS TEAM CYMRU"
 neighbor IP password <md5-password>
 neighbor IP passive
 neighbor IP ebgp-multihop 255
 neighbor IP update-source <your-ip-address>

address-family ipv4 unicast
  neighbor IP remove-private-AS all
  neighbor IP soft-reconfiguration inbound
  neighbor IP route-map UTRS-IN in
  neighbor IP route-map UTRS-OUT out

ip prefix-list 32-only seq 5 permit 0.0.0.0/0 ge 32
bgp community-list standard UTRS permit 64496:0

route-map UTRS-IN permit 10
 match community UTRS
 match ip address prefix-list 32-only
 set ip next-hop 192.0.2.1

route-map UTRS-OUT permit 10
 match community YOUR-BLACKHOLE-COMMUNITY
 match ip address prefix-list 32-only
 set ip next-hop 192.0.2.1

Configuração BIRD

filter bgp_in_utrs { 
    if (64496,0) ~ bgp_community && net.len = 32 then { 
        dest = RTD_BLACKHOLE; 
        accept; 
    } 
    else reject; 
} 

filter bgp_out_utrs { 
    if  (xxxxx,666) ~ bgp_community && net.len = 32 && net_local() then { 
        bgp_community = -empty-; 
        bgp_community.add((xxxxx,0)); 
        accept; 
    } 
    else reject; 
} 

protocol bgp UTRS_BL { 
    description "UTRS Blackhole Service"; 
    ipv4 {
     	import filter bgp_in_utrs;
       	export filter bgp_out_utrs;
    };
    multihop; 
    local <your-ip> as <your-asn>; 
    neighbor <utrs-ip> as 64496; 
    graceful restart; 
    password "<md5-password>"; 
    passive; 
}

Perguntas Frequentes (FAQ)

Qual é o custo do serviço ?

Nada. É um serviço gratuito. O Team Cymru aceita compartilhamento de dados ou doações que ajudem a manter este e outros serviços gratuitos.

Quais prefixos o UTRS anuncia atualmente ?

Geralmente, anúncios de rotas originados pelo UTRS são poucos, em média anunciam uma quantidade reduzida de endereços ou é possível haver momentos que nenhum prefixo será anunciado.

As rotas RTBH que o UTRS anuncia são públicas ?

As RTBH que forem aceitas e encaminhadas pelo UTRS são também anunciadas para toda a comunidade participante do UTRS em tempo real através das sessões BGP, porém elas não são disseminadas de maneira pública. Rotas que não passam na verificação podem estar sujeitas à revisão. O UTRS pode considerar publicar um resumo ou dados históricos para benefício público e para a comunidade de pesquisa no futuro.

Me ajude, estou sob ataque, o UTRS pode bloquear para mim ?

Se você representa uma organização que é um Sistema Autônomo e é capaz de provar que é autorizado a originar os anúncios dos prefixos em questão o UTRS poderá auxiliar. No entanto se você não possui qualquer tipo de contato prévio com o Team Cymru pode haver alguma demora para que possam ser realizadas todas as verificações necessárias.

Eu não tenho um ASN ou uso BGP, você pode bloquear algo para mim ?

Este serviço é disponibilizado apenas para operadores de BGP que possuam um número de Sistema Autônomo público, geralmente através de um Registro Regional da Internet (RIR).

Como o UTRS faz para verificar as redes conectadas ?

É possível que o UTRS já possua algum tipo de relacionamento com alguns potenciais participantes ou conhecer pessoal dessas organizações. No casos onde isso não ocorre geralmente os a solicitações de participação são verificadas através dos contatos registrados junto à base de dados Whois onde o ASN é registrado ou no Peering DB (portanto mantenha seus dados de contato atualizados). Se o UTRs não for capaz de verificar os dados de contato utilizando essas bases de dados mais comuns outros métodos podem ser utilizados como consulta à base de dados públicas com com upstream do solicitante.

O UTRS recebe anúncios de rotas ou apenas os anuncia ?

Ambos, porém UTRS normalmente não origina esses anúncios. Os anúncios de rotas são iniciados pela comunidade de participantes através de anúncios BGP para o UTRS que realiza as verificações necessárias e os encaminha através de anúncios BGP para todos os outros participantes.

Quem decide quais prefixos são anunciados para os participantes do UTRS ?

Cada participante do UTRS pode anunciar prefixos /32 os quais estejam dentro de alguma das ranges de prefixos pertencentes ao próprio Sistema Autônomo. Nenhum participante do UTRS é capaz de anunciar rotas pertencentes à prefixos de outros participantes.

Como o UTRS verifica os anúncios ?

Todos os anúncios devem ser /32, caso contrário será automaticamente rejeitado. Também é utilizada a API do RIPEstatpara analisar o histórico de rotas, origem e AS-Path. O peer deve ser o único originador ou upstream do prefixo que engloba o anúncio mais especifico.O peer também deve possuir um histórico de ter anunciado o prefixo que engloba aquela rota por pelo menos os últimos 30 dias. Se o anúncio não bater com esses critérios o encaminhamento desse anúncio não será realizado e um alerta interno poderá ser gerado e enviado para revisão interna.

Quais outras restrições de anúncios existem ?

A cada participante é permitido até 25 anúncios simultâneos à qualquer momento. Quantidades superiores serão rejeitadas. Um anúncio também expira após ficar ativo por 7 dias e será removido. O participante poderá anunciá-lo novamente caso necessário.

Posso anunciar rotas de blackhole dos meus clientes para o UTRS ?

No momento o UTRS apenas verifica os prefixos originados diretamente pelo próprio participante e não seus Downstreams. Esta é uma funcionalidade requisitada frequentemente e está nos planos do UTRS adicioná-la como parte do processo de verificação das rotas anunciadas para ser capaz de receber anúncios de blackhole de Downstreams dos participantes. No entanto um participante pode solicitar que alguma dessas rotas seja anunciada manualmente contatando a equipe do UTRS que fará uma revisão da solicitação.

O UTRS suporta BGP Flowspec ao invés de blackholes (RTBH) apenas ?

Atualmente UTRS é um serviço exclusivo para RTBH. Apesar da implementação BGP utilizada pelo UTRS suportar Flowspec o suporte à esta funcionalidade ainda é limitado em muitos casos e portanto esta funcionalidade não foi habilitada. Isso pode mudar caso houver demanda suficiente que justifique. Se isso é algo que interessa ao seu Sistema Autônomo entre em contato diretamente com o UTRS sinalizando neste sentido.

É possível customizar o ASN, next-hop e community tags ?

Tecnicamente sim, porém o UTRS considera que poucos casos necessitam esta mudança e prefere não fazer para poder manter a configuração o mais simples possível. É possível para cada participante modificar e alterar o next-hop or community tag em cada politica de import própria.

É necessário o uso de assinatura TCP MD5 (aka BGP password) ?

Sim.

Posso anunciar meus prefixos normalmente anunciados para outros peers e Trânsitos para o UTRS ?

Não. Por favor não faça isso ! Isso aumenta o trabalho dos sistemas do UTRS e esses anúncios serão ignorados, a mesmo claro que o anúncio seja um /32 o qual será encaminhado para os demais participantes realizarem o bloqueio. Se o UTRS constatar outras rotas que não sejam de blackhole a sessão BGP pode ser desligada.

Qual software é utilizado pelo UTRS ?

O UTRS utiliza o ExaBGP, um software que possui uma implementação extensível de BGP e que permite uma nível interessante de customizações como as que o UTRS realiza.

Quais Sistemas Autônomos participam do UTRS ?

A lista de participantes do UTRS não é publicada porque nem todas as redes desejam que essa informação seja pública. No entanto os participantes do UTRS são capazes de saber quem são esses outros participantes assim como possuem a capacidade interagir com os demais através da Lista de Emails. Backbones dos mais variados tamanhos e regiões no mundo todo participam do UTRS.

Sou um participante do UTRS e necessito suporte, quem eu posso contatar ?

Participantes podem enviar um email para utrsrequest@cymru.com

Autor: Fernando Frediani

Disponível em “https://wiki.brasilpeeringforum.org/index.php?title=UTRS_Registro_e_Configuracao&oldid=2508”