udp_reply event instead of supposed udp_request event

Zeek
1

hi

i have another riddle for you today :wink:
the following policy script shows not the behaviour i suppose:

# test.bro

event udp_request(u: connection) {
    local srcIP = u$id$orig_h;
    local destIP = u$id$resp_h;
    print "udp_request", u$id;
}

event udp_reply(u: connection) {
    local srcIP = u$id$orig_h;
    local destIP = u$id$resp_h;
    print "udp_reply", u$id;
}

i produced traffic from the source host x.x.x.75 to randomly chosen hosts. source port was 53 (dns). the sent packets didn't
contain any dns replies.

[root@det:/usr/local/bro]# ./bin/bro -i eth3 test
listening on eth3
Reading .state/state.bst ...
udp_reply, [orig_h=28.239.208.235, orig_p=51647/udp, resp_h=x.x.x.75, resp_p=53/udp]
udp_reply, [orig_h=128.212.59.231, orig_p=27613/udp, resp_h=x.x.x.75, resp_p=53/udp]
udp_reply, [orig_h=82.146.148.227, orig_p=53106/udp, resp_h=x.x.x.75, resp_p=53/udp]
udp_reply, [orig_h=58.2.1.68, orig_p=61607/udp, resp_h=x.x.x.75, resp_p=53/udp]
udp_reply, [orig_h=83.88.197.211, orig_p=10120/udp, resp_h=x.x.x.75, resp_p=53/udp]
udp_reply, [orig_h=51.85.5.250, orig_p=54565/udp, resp_h=x.x.x.75, resp_p=53/udp]
udp_reply, [orig_h=109.89.191.91, orig_p=25624/udp, resp_h=x.x.x.75, resp_p=53/udp]
udp_reply, [orig_h=17.93.105.34, orig_p=59958/udp, resp_h=x.x.x.75, resp_p=53/udp]
udp_reply, [orig_h=105.107.199.36, orig_p=56071/udp, resp_h=x.x.x.75, resp_p=53/udp]
udp_reply, [orig_h=113.201.33.243, orig_p=6563/udp, resp_h=x.x.x.75, resp_p=53/udp]
udp_reply, [orig_h=32.154.25.148, orig_p=19877/udp, resp_h=x.x.x.75, resp_p=53/udp]
udp_reply, [orig_h=84.150.247.84, orig_p=44926/udp, resp_h=x.x.x.75, resp_p=53/udp]
udp_reply, [orig_h=114.90.239.185, orig_p=6913/udp, resp_h=x.x.x.75, resp_p=53/udp]
udp_reply, [orig_h=43.22.154.204, orig_p=16223/udp, resp_h=x.x.x.75, resp_p=53/udp]
udp_reply, [orig_h=50.56.252.49, orig_p=18381/udp, resp_h=x.x.x.75, resp_p=53/udp]
1108127885.586962 received termination signal
401 packets received on interface eth3, 0 dropped
1108127885.586962 Saving state...

this is the corresponding tcpdump output:

[root@det:~]# tcpdump -i eth3 -n -q host x.x.x.75 and udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth3, link-type EN10MB (Ethernet), capture size 68 bytes
14:18:02.481453 IP x.x.x.75.53 > 28.239.208.235.51647: UDP, length: 33
14:18:02.581319 IP x.x.x.75.53 > 128.212.59.231.27613: UDP, length: 33
14:18:02.681322 IP x.x.x.75.53 > 82.146.148.227.53106: UDP, length: 33
14:18:02.781343 IP x.x.x.75.53 > 58.2.1.68.61607: UDP, length: 33
14:18:02.881326 IP x.x.x.75.53 > 83.88.197.211.10120: UDP, length: 33
14:18:02.981365 IP x.x.x.75.53 > 51.85.5.250.54565: UDP, length: 33
14:18:03.081301 IP x.x.x.75.53 > 109.89.191.91.25624: UDP, length: 33
14:18:03.181319 IP x.x.x.75.53 > 17.93.105.34.59958: UDP, length: 33
14:18:03.281291 IP x.x.x.75.53 > 105.107.199.36.56071: UDP, length: 33
14:18:03.381325 IP x.x.x.75.53 > 113.201.33.243.6563: UDP, length: 33
14:18:03.481325 IP x.x.x.75.53 > 32.154.25.148.19877: UDP, length: 33
14:18:03.581255 IP x.x.x.75.53 > 84.150.247.84.44926: UDP, length: 33
14:18:03.681327 IP x.x.x.75.53 > 114.90.239.185.6913: UDP, length: 33
14:18:03.781367 IP x.x.x.75.53 > 43.22.154.204.16223: UDP, length: 33
14:18:03.881327 IP x.x.x.75.53 > 50.56.252.49.18381: UDP, length: 33

15 packets captured
15 packets received by filter
0 packets dropped by kernel

my question is: why does bro recognizes udp_reply events and not udp_request
events? the packets were only sent from one host to another and there were no packets in the opposite direction.

i know that udp packets from port 53 are often dns replies but an assumption which is made because of the application layer protocol shouldn't have any impact on events on the transport protocol layer...

thanx
christoph

2

the same behavior with sending port 111 and port 123 instead of port 53.

Zitat von Christoph Goeldi <goeldich@ee.ethz.ch>:

3

my question is: why does bro recognizes udp_reply events and not udp_request
events? the packets were only sent from one host to another and there
were no packets in the opposite direction.

It's hardcoded. Sessions.cc, around 1247.

i know that udp packets from port 53 are often dns replies but an
assumption which is made because of the application layer protocol
shouldn't have any impact on events on the transport protocol layer...

Bro assumes that UDP port 53 is DNS anyway, so assuming that traffic
sourced from port 53 is a DNS reply doesn't make much of a difference.

You could make that flip in Sessions.cc policy-controlled if it really
gets in your way ...

Cheers,
Christian.

4

Indeed, as you'll find if you look at the code I pointed out: those are
assumed to be the Portmapper and NTP.

Cheers,
Christian.

5

my question is: why does bro recognizes udp_reply events and not udp_request
events? the packets were only sent from one host to another and there
were no packets in the opposite direction.

It's hardcoded. Sessions.cc, around 1247.

Yes, Bro currently tries to guess which port is the service port, because it may not see the complete connection, for example, it may miss the initial DNS request. What Bro really should do is to look at the packet contents in addition to port numbers in its guessing. We have been puzzled, too, by non-DNS packets with source port 53 (the source port was probably selected to fool firewalls). I don't know if anyone is working on this kind of content-based port selection, but for now, the problem can be circumvented by tweaking NetSessions::IsLikelyServerPort().

Ruoming