[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bird-users
Subject:    Re: Implementing RTBH filtering / BGP tagging
From:       Gregg Berkholtz <gregg () tocici ! com>
Date:       2012-03-28 19:04:57
Message-ID: 16779C3B-40BB-41F9-A6F4-11125C27E646 () tocici ! com
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the help and suggestions, we have a working configuration that now imports \
and uniquely tags/announces blackhole specific kernel route entries.

For the archives, here's a basic working "example" config. I opted to get away from \
statically configuring blackhole routes within BIRD itself, as existing tooling \
adds/removes kernel route table entries on the linux-based router, and keeping this \
within kernel routing tables is a simpler approach for us.

If using a Linux 2.6 kernel based router, and when tracking blacklisted IPs via a 2nd \
route table:

To blacklist 192.0.2.44/32, run:
~$ sudo ip route add blackhole 192.0.2.44/32 table 10

Using the below configuration, within 10 seconds BIRD will detect a new addition to \
kernel routing table 10, and:  1) Auto-add a corresponding blackhole entry to your \
kernel's master routing table...truly blacklisting the IP on your router.

 2) Announce 192.0.2.44/32 with a BGP tag of 64665:666 to your upstream provider, \
enabling you to leverage a customer blackhole community config (e.g. RTBH portion of \
RFC3882).

Relevant portions of bird.conf:
"...
# Scans and learns of blackhole routes from table 10, every 10 seconds
table blackholes;
protocol kernel blackhole {
  table blackholes;
  kernel table 10;
  scan time 10;
  learn;
  import all;
  export all;
}

# Merges kernel route table 10 into the kernel's active/master routing table
protocol pipe {
  table master;
  peer table blackholes;
  mode transparent;
  import filter {
    print "Importing blackhole list.";
    accept;
  };
}

filter bgp_out_upstream {
  # Limit to blackholed routes
  if (proto = "blackhole" ) then
  {
    # Limit to /32 netmask
    if net.len = 32 then {
      bgp_community.add((64665,666)); # Replace 64665 with your upstream's ASN
      printn "Nulling ";
      print net;
      accept;
    }
  }
  if net ~ [192.0.2.0/24] then accept; # Replace 192.0.2.0/24 with your local \
netblock(s)  reject;
}

protocol bgp upstream {
...
  export filter bgp_out_upstream;
...
}
..."

Hope this helps others,
Gregg Berkholtz
Datacenter consulting, hosting & support since 1995
  www.tocici.com  |  503-488-5461 x17  |  AS14613

On Mar 20, 2012, at 3:25 PM, Ondrej Zajicek wrote:

> On Tue, Mar 20, 2012 at 11:42:05AM -0700, Kelly Cochran wrote:
> > > Or much simpler solution - remove secondary tables, add blackhole routes
> > > to bird config as static routes (in static protocol) and have everything
> > > in the master table.
> > 
> 
> > Which is exactly what I wound up doing when testing this sort of thing
> > internally.  Soft config reloads won't bounce the session when you
> > change items in the static protocol.  Good use for an include, generate
> 
> BTW, even 'hard' reconfiguration will not restart the session if there is
> no change in the BGP session protocol (and its filters). The difference
> between soft/hard reconfiguration in BIRD is just whether filter changes
> are considered.
> 
> > > BTW, in the filter bgp_out_he(), i guess you want accept all routes with
> > > proto = "blackhole", otherwise only your routes would be exported (and i
> > > suppose blackholed IPs are foreign).
> > 
> 
> > Blackholed IPs would actually have to be local.  This mechanism is
> > common for dropping a DDoS at your upstream's borders, and not just your
> > own border, as it's presumably not something you can effectively
> > mitigate internally.  Remote IPs would be S/RTBH, and that's not usually
> > seen in transit networks due to the nature of what that would require to
> > affect only the requestor of the blackhole, and not the network as a
> > whole.  (VRFs for everyone!  Wait... that requires how much RAM? 
> > Nevermind...)
> 
> Yes, i thought more about S/RTBH. 
> 
> BTW, to implement other side of RTBH we would probably need to support
> explicit change of received BGP route destination to
> unreachable/blackhole/prohibit type. This currently could by done by
> some tricks, so explicit filter operator for that would be useful, i
> suppose.
> 
> -- 
> Elen sila lumenn' omentielvo
> 
> Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAk9zYNkACgkQw+5R43T/iWXgUgCfcH5j2/vF2i40C4RHf5o5gKIV
5C0AoJlSRUJmzzVlAyitQTSWR8NrYmaj
=bn0k
-----END PGP SIGNATURE-----


[prev in list] [next in list] [prev in thread] [next in thread]