Pages

11/12/2017

Vyatta vRouter Appliance: Using BGP to distribute 'firewall' rules

A while ago I attended a Mikrotik User Meeting or MUM for short. For those of you that don't know, Mikrotik are a Latvian company that make networking hardware and an operating system known as RouterOS, that will act as a router and firewall. Their 'USP' is value for money. £22 will get you a home router that will support OSPF, BGP, MPLS et and £2736 will get you a router that will route almost 80Gb/s. Nice.

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.

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)

The London router is configured to peer with both the rule injector and the Washington router via BGP. As the router in Washington is not directly connected to the rule injector, the London Router is configured as a route reflector. The black hole destination 1.1.1.1 is forced to go to a 'dummy' interface, br0.

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-
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