UDP contents

Zeek
1

I'm having a slight problem getting the contents of Kerberos UDP packets. This is my first attempt at Bro so hopefully my error is something simple.

Bro version 1.1d

When a client requests an initial kerberos ticket it sends a request to the server (AS_REQ) and the server reply is usually either the ticket or an error. I want to watch the initial AS_REQ, but all I'm seeing is the response from the server.

In this case, /tmp/trace2.out is a tcpdump of a couple kerberos requests from the client's perspective and the AS_REQ's are there when looking at the dump via ethereal.

/usr/local/bro/bin/bro -r /tmp/trace2.out hostname.bro

====== policy/bro.init =============
...
const udp_content_deliver_all_orig = T &redef;
const udp_content_deliver_all_resp = T &redef;
...
====== site/hostname.bro ========
@prefixes = local
@load site
@load conn.bro # not really needed

global dop = open_log_file("dop") &redef;

event udp_contents(u: connection, is_orig: bool, contents: string){
   local id = u$id;

        print dop, fmt("KDC %s %s",id$orig_p,id$resp_p);
        print dop, fmt("contents %s",contents);
}

2

Hi Mike,

it doesn't look like you're doing anything wrong. However, I've just
tried dumping some UDP contents with Bro 1.2.1 and it works fine, so we
need to figure out why it's not working for you.

I have this traffic:

22:26:10.089582 IP 1.2.3.211.53 > 200.33.146.222.32789: 3628*- 1/4/4 PTR [...]. (245)
22:26:10.089582 IP 1.2.3.211.32789 > 200.33.146.222.53: 18275 A? [...]. (44)
22:26:10.229573 IP 1.2.3.211.53 > 200.33.146.222.32789: 18275*- 1/3/3 A [...] (187)
22:30:39.981424 IP 1.2.3.211.32789 > 200.33.146.222.53: 36142 PTR? [...]. (44)
22:30:40.141413 IP 1.2.3.211.53 > 200.33.146.222.32789: 36142* 1/2/2 PTR [...]. (16
22:30:40.151412 IP 1.2.3.211.32789 > 200.33.146.222.53: 20837 A? [...]. (52)
22:30:40.311401 IP 1.2.3.211.53 > 200.33.146.222.32789: 20837 NXDomain* 0/1/0 (120)

and this policy, in which I don't print out the contents, but have added
output of the is_orig flag that shows the directionality of the packet:

3

I've upgraded to Bro 1.2.1 and here are four packets that correspond to a DNS request and the kerberos request:

18:15:49.693120 IP 141.142.222.33.32909 > 141.142.2.2.domain: 24696+ SRV? _kerberos-master._tcp.NCSA.EDU. (48)
18:15:49.693493 IP 141.142.2.2.domain > 141.142.222.33.32909: 24696 NXDomain* 0/1/0 (105)
18:15:49.693545 IP 141.142.222.33.32909 > 141.142.3.16.kerberos: v5
18:15:49.694244 IP 141.142.3.16.kerberos > 141.142.222.33.32909:

And my bro output:

32909/udp 53/udp F
32909/udp 88/udp F

In this case, 141.142.222.33 is the local client where bro is running. Interestingly enough, I did a tcpdump from two other clients. One in the same building gave similar results, one in the building with the kerberos server gave me the results we should expect:

36209/udp 53/udp T
36209/udp 53/udp F
36209/udp 88/udp T
36209/udp 88/udp F

Now might be a good time to mention that I also see these messages locally, but I had always assumed they were unrelated and due to other local traffic:

1170117967.140200 weird: bad_UDP_checksum
1170117967.140751 weird: bad_UDP_checksum
1170117967.141191 weird: bad_UDP_checksum
1170117967.142015 weird: bad_TCP_checksum
1170117967.142807 weird: bad_TCP_checksum

So.. my current theory is there's something screwy with our local network and I intend to find out what's causing it. I'll let you know when I do. This UDP traffic 'works' so I think Bro should be detecting it regardless of whether some networking equipment might be mangling the packets a bit.

-Mike

Christian Kreibich wrote:

4

1170117967.140200 weird: bad_UDP_checksum
1170117967.140751 weird: bad_UDP_checksum
1170117967.141191 weird: bad_UDP_checksum
1170117967.142015 weird: bad_TCP_checksum
1170117967.142807 weird: bad_TCP_checksum

So.. my current theory is there's something screwy with our local
network and I intend to find out what's causing it.

It's very likely the problem is that for outbound packets, your local
packet capture occurs at a point in the kernel prior to when the checksums
are computed (this can especially be the case if your system has a form
of TCP offboard acceleration).

This UDP traffic 'works' so I think Bro should be detecting
it regardless of whether some networking equipment might be mangling the
packets a bit.

You can test this by running Bro with -C to tell it to ignore checksum errors.

    Vern

5

You can start Bro with -C to ignore broken checksums.

Robin

6

That makes everything work as expected. Thanks!

-Mike