The MUM consisted of various presentations and demonstrations and one which caught my eye was a presentation from Barry Higgins from Allness, who demonstrated using OSPF to distribute a black list of bad guys which were then null routed, a nice method of distributing 'firewall' rules on a bunch of routers automagically. You can view his presentation on Youtube.
I've recently been playing Vyatta vRouter appliances and wondered if I could apply a similar method of injecting a black list from an IDS (Intrusion Detection System) and having it distributed via BGP.
Disclaimer
I am not a senior network engineer by trade. This is a proof of concept, tested in a virtualised lab. It may blow up or cause undesired issues in a production environment. YMMV, and Merry Christmas!
Caveats
I came across some weird bugs whilst setting this up. When adding and removing 'route-map' filters on the vRouters, they wouldn't take affect, even after reseting BGP or a reboot. The a work around was to make a change to the route I was trying to filter such as adjusting the next hop, commit it, and then revert the change. This seemed to kick it back into life. Weird. I'm really hoping this is because I am using an ancient version of the vRouter to test. I will test on a newer version and update this post when I get chance.
I ended up using a Mikrotik router to inject the routes, as I'm more familiar with them and filtering was working as expected.
Theory
The goal is to be able to inject routes into the routing table that are then black holed locally on each router. As routing is usually only performed on the destination of a packet rather than the source, this will blackhole replies to the attacker but won't block the actual bad traffic.
To work around this, we can enable strict Reverse Path Forwarding specified in RFC3704, that will drop any packet from an IP address that can't be reached via the same interface the packet arrived on. As the attackers IP is black holed, the source address can't be reached via the same interface it arrived on and the packet is dropped.
Each of the vRouters is configured with a static route for 1.1.1.1/32 to a dummy interface, br0. I tried black holing it, however this prevented the recursive black hole routes from coming active. I also tried forcing to the loopback interface, but this caused routing loops.
The rule injector re-writes the inserted rules with a next-hop address of 1.1.1.1 to ensure bad packets are black holed locally. It also forces 'no-export', to ensure black holed routes aren't distributed to external BGP peers.
It's worth noting that on the Mikrotik it's possible to force routes received via BGP into a black hole, without messing around with dummy interfaces and static routes like the vRouters.
Each of the vRouters is configured with a static route for 1.1.1.1/32 to a dummy interface, br0. I tried black holing it, however this prevented the recursive black hole routes from coming active. I also tried forcing to the loopback interface, but this caused routing loops.
The rule injector re-writes the inserted rules with a next-hop address of 1.1.1.1 to ensure bad packets are black holed locally. It also forces 'no-export', to ensure black holed routes aren't distributed to external BGP peers.
It's worth noting that on the Mikrotik it's possible to force routes received via BGP into a black hole, without messing around with dummy interfaces and static routes like the vRouters.
Proposed Topology
The image below shows my proposed topology, with routers in two locations (London and Washington) and the 'Provider Cloud' in the middle. For the PoC the cloud is just a single router, but in reality it will be multiple routers distributing the customer subnets within VRFs.
The IDS Rule Injector is connected to the London router. This would be an IDS such as snort or Suricata, pushing IPs into a script to then be inserted into Quagga or BIRD which will then distribute the black hole routes to the vRouters. For the PoC we'll just use a Mikrotik router and add the black hole routes manually.
Finally the computers represent hosts. The green hosts are trusted, and the red host is a bad guy we want to block.
 |
| Topology. Click to enlarge |
Configuration
The follow configuration assumes you have a basic understanding of entering commands into the routers. It shows only the final configuration, not a step by step guide on how to get there.
IDS Rule Injector (Mikrotik)
The IDS rule injector peers with the London router via BGP. The black holed routes are inserted into the 'drop' routing table and then distributed via BGP.
/interface bridge
add name=lo
/routing bgp instance
set default as=64512 out-filter=bgp-out redistribute-static=yes \
routing-table=drop
/ip address
add address=172.16.0.100 interface=lo network=172.16.0.100
add address=10.0.100.2/30 interface=ether1 network=10.0.100.0
/ip route
add distance=1 gateway=10.0.100.1
/routing bgp peer
add in-filter=bgp-in name=peer1 remote-address=10.0.100.1
/routing filter
add chain=bgp-out set-bgp-communities=no-export
add chain=bgp-out set-out-nexthop=1.1.1.1
London (vRouter)
firewall {
all-ping enable
broadcast-ping disable
ipv6-receive-redirects disable
ipv6-src-route disable
ip-src-route disable
log-martians enable
receive-redirects disable
send-redirects enable
source-validation strict
syn-cookies enable
}
interfaces {
bridge br0 {
aging 300
description blackhole
hello-time 2
max-age 20
priority 0
stp false
}
ethernet eth0 {
address 10.0.101.2/30
duplex auto
hw-id 52:54:00:12:34:55
smp_affinity auto
speed auto
}
ethernet eth1 {
address 192.168.101.1/24
duplex auto
smp_affinity auto
speed auto
}
ethernet eth2 {
address 10.0.100.1/30
duplex auto
smp_affinity auto
speed auto
}
loopback lo {
address 172.16.0.101/32
}
}
protocols {
bgp 64512 {
neighbor 10.0.100.2 {
remote-as 64512
soft-reconfiguration {
inbound
}
update-source 10.0.100.1
}
neighbor 10.0.102.2 {
remote-as 64512
route-reflector-client
soft-reconfiguration {
inbound
}
update-source 10.0.101.2
}
parameters {
default {
}
}
}
static {
interface-route 1.1.1.1/32 {
next-hop-interface br0 {
}
}
route 0.0.0.0/0 {
next-hop 10.0.101.1 {
}
}
}
}
Provider Cloud (vRouter)
The provider cloud router has a simple configuration, as there is no BGP or black holing here.
interfaces {
ethernet eth0 {
address 10.0.101.1/30
duplex auto
hw-id 52:54:00:12:34:56
smp_affinity auto
speed auto
}
ethernet eth1 {
address 10.0.102.1/30
duplex auto
smp_affinity auto
speed auto
}
ethernet eth2 {
address 192.168.0.1/24
duplex auto
smp_affinity auto
speed auto
}
loopback lo {
}
}
protocols {
static {
route 192.168.101.0/24 {
next-hop 10.0.101.2 {
}
}
route 192.168.102.0/24 {
next-hop 10.0.102.2 {
}
}
}
}
Washington (vRouter)
The Washington router is configured very similar to its counterpart in London, minus the peering to the rule injector and the route reflection.
firewall {
all-ping enable
broadcast-ping disable
ipv6-receive-redirects disable
ipv6-src-route disable
ip-src-route disable
log-martians enable
receive-redirects disable
send-redirects enable
source-validation strict
syn-cookies enable
}
interfaces {
bridge br0 {
description blackhole
}
ethernet eth0 {
address 10.0.102.2/30
duplex auto
hw-id 52:54:00:12:34:56
smp_affinity auto
speed auto
}
ethernet eth1 {
address 192.168.102.1/24
duplex auto
smp_affinity auto
speed auto
}
loopback lo {
address 172.16.0.102/32
}
}
protocols {
bgp 64512 {
neighbor 10.0.101.2 {
remote-as 64512
soft-reconfiguration {
inbound
}
update-source 10.0.102.2
}
}
static {
interface-route 1.1.1.1/32 {
next-hop-interface br0 {
}
}
route 0.0.0.0/0 {
next-hop 10.0.102.1 {
}
}
}
}
Hosts
In my lab environment (GNS3) I am using VPCS as the hosts. The only configuration on the hosts is the IP and default gateway shown in the topology diagram above.
Testing it works
Assuming you followed the above, there's currently no black holed routes. The 'attacker' should be able to ping either of our hosts and receive a response-
Lets black hole him by entering the following on the rule injector-
/ip route add distance=1 dst-address=192.168.0.10/32 routing-mark=drop type=blackhole
And then check the route has been distributed by checking out the route table on each router-
 |
| London Router |
 |
| Washington Router |
Lets try pinging from the attacker again-
So we can see that we're no longer getting a reply to pings. But how can we be sure the pings aren't making it to the host? Lets take a packet capture on ETH1 of the London router to be sure-
So, we can see that the pings or replies aren't making it as far as the host, so things are working as expected. Nice!
So we can see that we're no longer getting a reply to pings. But how can we be sure the pings aren't making it to the host? Lets take a packet capture on ETH1 of the London router to be sure-
 |
| Not a peep |
So, we can see that the pings or replies aren't making it as far as the host, so things are working as expected. Nice!
Summary
Setting this up on the Vyatta vRouters was way more painful than it should have been, but once its setup it works well. Given the choice I'd probably go with Mikrotik routers end to end as they seem to handle this type of configuration a lot better.
No comments:
Post a Comment