Long time listner, first time caller - is SO VRF aware?

[Steve]

Good morning. I've been trying to find a use case for SO in my
environment, and I may have it. I have a multi-tennant firewall that
is falling over because of a specific traffic type going through it
(attack). At this point, the box is fed by at least one 1GB link, and
all the traffic is VRF encapsulated.

I need something to watch the Internet side, and while the connections
share the same physical link(s), all the logical interfaces are
separated into Virtual Route Forwarders, or VRFs.

Is SO VRF aware?
I already have netflow data leaving this firewall, could I send the
netflow data to an SO appliance to identify bad flows?

I would also like to mitigate the issue, but as I do not have any taps
handy, I'm not sure I can actually DO anything without SO being
inline. That said, getting an alert about a bad flow as sson as it
starts would be 10x better than searching through the netflow logs
manually. Thanks in advance for your time!

Steve

[Liam Randall]

There are a lot of tools in SO, however the sensor is primarily geared towards receiving, analyzing and processing full packet data.  SO would probably work best on the private side of this link.

By VRF do you mean Virtual Routing and Forwarding or VPN Routing and Forwarding (Cisco MPLS)?

If you have a pcap handy, replay some traffic and check sguil, snorby, and bro.

Liam

Steve

--

[S Marouchoc]

Virtual Routing and Forwarding, my bad.

The internal side has many more physical feeds that would have to be watched.  All the internal connections are also in unique VRF's.  I suppose I could try to mirror at least one of the ports to an SO box and see if it can interpret it  - that may have to wait until we mitigate the issue we are having.  Bosses are looking for something to help RIGHT NOW, of course :)

--
 
 

[Liam Randall]

I would try a test mirror first off of the router, however I am a big fan of hard taps.  Check the wiki, there are instructions for replaying and testing traffic w/ tcpreplay.

Liam

--
 
 

[Ian Bowers]

Confusingly, unless I'm mistaken those 2 connotations of VRF are more or less the same thing.  And to add to the quagmire, VPN with respect to MPLS is a very different thing than VPN with respect to IPSec.

-Ian

On Mon, Oct 22, 2012 at 10:18 AM, Liam Randall <liam.r...@gmail.com> wrote:

--
 
 

[Liam Randall]

Ian,

I had to google it: http://en.wikipedia.org/wiki/Virtual_Routing_and_Forwarding

On more complex links (QinQ, 6in4, 4in6, etc) I have seen the various SO have different levels of success.  For example, Bro is magic- it is the honey badger of network tools.  It doesn't seem to care what you throw at it- it just works.

I often find that clients don't know what is on their networks.  I have had people swear to me "we have this, not that.." all the time.  Pcaps don't usually lie.  :)  Steve, I suggest you start there.

Liam

--
 
 

[Steve Marouchoc]

Cool. If Bro will "just work", I'm down with giving it a try. 

We do have a test environment and a capture of the problem traffic already. I could set up the mirror there and replay the traffic. Thanks for the advice!

Stephen Marouchoc

--
 
 

[Liam Randall]

Please reply back to list with what tools did and did not work on the deployment.  SO is really just a bunch of really cool tools all put together and a lot of those project maintainers are on this list.

Liam

--
 
 

[S Marouchoc]

You hit it exactly.  In my case, the traffic arriving at the interface is NOT IPSEC - while ther could certainly be IPSEC VPN's terminating to the external IP's of a particular VRF, that is not where my problem lies.  I have a good old fashioned resource depletion attack going on using traffic in the clear.  I know, because I've got captures that show me the actual packets, and have correlating data from the router showing this is what is depleting the resources. I just need to detect the attack sooner than I have been, and stop it before it becomes service affecting.


I have a meeting with my boss this afternoon, hopefully I can obtain approval for hardware and get SO loaded in my test environment and replay the attack, see what I get.

On Mon, Oct 22, 2012 at 12:22 PM, jswan <sanju...@gmail.com> wrote:

So since my primary hat is network guy, I can clarify the whole VRF thing: a VRF is simply a virtual routing instance inside a router. It's similar to a VLAN, but for layer 3. Interfaces that are in different VRFs have their own routing tables, separate instances of routing protocols, etc. You can have overlapping IP address space in different VRFs. Different VRFs can't talk to teach other except when specifically allowed. It's a great tool when you have networks that share common physical infrastructure but aren't supposed to talk to each other.

There is no necessary connection between MPLS or IPSec and VRFs. You can have VRFs mapped to VLANs and run them with neither MPLS or IPSec, and it works fine (this is usually called "multi-VRF" or in Cisco-land, "VRF-Lite"). MPLS simply offers a convenient way to manage VRFs at large scale; you can have thousands of VRFs at the network edge without the core needing to know anything about them. IPSec just offers an encryption layer. It is not uncommon for people to run IPSec VPNs on top of VRFs, either with or without MPLS. I saw a presentation recently about a network running IPSec-encrypted GRE on top of two layers of MPLS VPNs: the tunnels can get deep!

So depending on the configuration, there could be either no extra encapsulation, or you could have various configurations of 802.1q tags, MPLS tags, or more.

I know that Snort and Bro are smart enough to handle normal 802.1 tags transparently; whether they will handle stacked 802.1q tags or MPLS tags I don't know, but if I have time this week (doubtful), I'll test it. Obviously if the traffic is already IPSec encrypted by the time you see it, you're out of luck.

--

[Liam Randall]

for testing you can replay it on a vm.  It runs fine in both virtualbox and vmware.

:)

Liam

--
 
 

[seth...@gmail.com]

(For context, I'm one of the lead Bro developers)

On Oct 22, 2012, at 12:22 PM, jswan <sanju...@gmail.com> wrote:

> So depending on the configuration, there could be either no extra encapsulation, or you could have various configurations of 802.1q tags, MPLS tags, or more.

If you have traffic containing stacked MPLS and 802.1q tags in the same packet, I'd appreciate if you could send it to me. The weirder the combination of headers, the better (but i'm not looking for artificially created traffic).

> I know that Snort and Bro are smart enough to handle normal 802.1 tags transparently; whether they will handle stacked 802.1q tags or MPLS tags I don't know, but if I have time this week (doubtful), I'll test it. Obviously if the traffic is already IPSec encrypted by the time you see it, you're out of luck.

In Bro we handle stacked MPLS tags transparently. I had to look up if the 802.1q standard even supports stacking and it turns out that it doesn't, it's supported in the 802.1ad standard. We don't currently support 802.1ad which supports double tagging though (two stacked vlan tags). If anyone ever encounters an 802.1ad tagged trace file, I'd love to get ahold of it to support it though since I'm lazy and don't feel like going out and finding one.

.Seth

[Liam Randall]

Seth and lazy are not two words I would ever expect to see next to each other.

Liam

  .Seth

--