Protosig question, round 2

Zeek
1

So not wanting to highjack a thread, here we have the pcap for GRE traffic:

https://www.cloudshark.org/captures/000721f1edfb

So per packet #1, src is 10.0.0.1, dst is 10.0.0.2. Packet #10 in the IP header is x2f or 47. I was hoping one of these would match, but they don't:

signature protosig_gre {
    header ip[10] == 47
    event "match"
}

signature protosig_gre {
    header ip[10:1] == 47
    event "match"
}

I tested this, and oddly this didn't match either:

signature protosig_gre {
   header ip[16:4] == 10.0.0.1
   event "match"
}

But THIS did:

signature protosig_gre {
   header ip[16:4] == 1.1.1.1
   event "match"
}

So that tells me that bro is reading the GRE encapsulated IP header, which is neat. Now...how do I tell bro to NOT read the GRE encapsulated IP header and read the original IP header? I also tried matching on GRE header proper as a payload of /\x00\x00\x08\x00/:

signature protosig_gre_payload {
   ip-proto == ip
   payload /\x00\x00\x08\x00/
   #payload-size == 4
}

But this didn't match either. Thank you.

James

2

I have the same interests but for vxlan encapsulated traffic. Last I heard, no luck doing this with bro. Have to decap upstream.

3

I don't recall anyone ever asking about vxlan before. I think it's a pretty trivial protocol to decode - look for udp 4789, skip 8 bytes, see if you have what looks like an ethernet frame.

The main issue with that and things like fabric path is the encapsulation into a limited number of outer l3 headers can cause flow hashing to be useless making it hard to load balance the traffic.

4

Right, I spoke to arista directly about that too. On the bro side I asked via my broala support contract.

Jon

5

Yea this works:

signature protosig_vxlan {
   ip-proto == udp
   dst-port == 4789
   payload /\x08\x00/
   eval ProtoSig::match
}

Adjust the payload "\x08" for vlanid. From https://surf.cloudshark.org/captures/b6495a4ea5d5.

James

6

But that just matches on it, which I think was the original tickets intent but I missed that. I’m interested in processing the inner packet/frame - I thought your initial comments were just your first step towards decap. I’m looking to decap and process the inner frame. Regardless, sorry, don’t mean to hijack.

Jon

7

Ohhhh...gotcha. We have the reverse problem...it appears that GRE is decapsulated, and vxlan isn't :slight_smile:

James

8

From https://www.bro.org/sphinx/frameworks/signatures.html:
Note that the IP-in-IP forms of tunneling are automatically decapsulated by default and signatures apply to only the inner-most packet [...]

From time to time people want to attach analyzers at layer 2, which

isn't possible at the moment. Maybe once this part of Bro sees an
update, signatures and custom decapsulation analyzers can be integrated.
But that's a question for the devs.

Jan

9

Thanks Jan…I’ve been looking so long at that page I completely missed that. :frowning:

James