Lying about DNS yields interesting bro entries

Curious. I'll show the data first:

2016-02-01T08:48:12-0700 x.x.x.x 420 65.113.230.90 53 udp dns - - - SHR T F0 d 0 0 1 73 (empty)
2016-02-01T08:48:12-0700 x.x.x.x 420 65.113.230.90 53 udp 21365 - - - - - 2SERVFAIL F F F F 0 - - T
2016-02-01T08:48:12-0700 x.x.x.x 420 65.113.230.90 53 dns_unmatched_reply - F bro

Packet capture listening to udp port 420 (no other match for 65.113.230.90):
2016-02-01 08:48:12.311086633 65.113.230.90 -> x.x.x.x DNS 89 Standard query response 0x5375 Server failure A otqxwnenalwb.www.1818my[.]com < [] added by me

Syslog:
Feb 1 08:48:12 kernel: [157335.232732] IN=ppp0 OUT= MAC= SRC=65.113.230.90 DST=x.x.x.x LEN=73 TOS=0x00 PREC=0x00 TTL=249 ID=23786 PROTO=UDP SPT=53 DPT=420 LEN=53

I guess my question is, is this desired behavior? I see the dns_unmatched_reply, but it seems the first two entries never happened...so should they be there? Thanks...more of a curious question more than anything else.

James

Which two entries are you referring to? This looks correct to me. It looks like you saw a stray DNS response message, but there was no query.

  .Seth

Hi Seth,

Pretty sure this is me missing something first off. But to be honest all the entries:

2016-02-01T08:48:12-0700 x.x.x.x 420 65.113.230.90 53 udp dns - - - SHR T F0 d 0 0 1 73 (empty)
2016-02-01T08:48:12-0700 x.x.x.x 420 65.113.230.90 53 udp 21365 - - - - - 2SERVFAIL F F F F 0 - - T
2016-02-01T08:48:12-0700 x.x.x.x 420 65.113.230.90 53 dns_unmatched_reply - F bro

The above says to me "x.x.x.x sent data to 65.113.230.90 on port 53, and got a servfail response, and this was actually an unmatched dns response". But in reality, this is what happened:

2016-02-01T08:48:12-0700 65.113.230.90 53 x.x.x.x 420 dns_unmatched_reply - F bro

65.113.230.90 was the id.orig_h, not x.x.x.x, but as I read the first three they state that x.x.x.x was the id.orig_h. But in fact per this drop:

Feb 1 08:48:12 kernel: [157335.232732] IN=ppp0 OUT= MAC= SRC=65.113.230.90 DST=x.x.x.x LEN=73 TOS=0x00 PREC=0x00 TTL=249 ID=23786 PROTO=UDP SPT=53 DPT=420 LEN=53

x.x.x.x did not send any traffic to 65.113.230.90, even though conn, dns, and weird. As I look at it though, I think it's me needing to get over reading left to right with Bro :slight_smile: Thanks Seth...hope that makes sense.

James

It sounds like the oddness is around the orig_h and resp_h of unmatched replies.
Which system originated a connection of an unmatched DNS reply? That begs the question: was the reply unsolicited or did Bro miss the request?

-AK

Hi Anthony,

I should first preface the whole reason I started down this path was because I find that a fair amount of firewall hits I see are on port 420, so I started packet capturing for udp port 420, and that’s when I started to notice this. So here’s what Bro showed for the IP of 65.113.230.90:

2016-02-01T08:48:12-0700 x.x.x.x 420 65.113.230.90 53 udp dns - - - SHR T F0 d 0 0 1 73 (empty)
2016-02-01T08:48:12-0700 x.x.x.x 420 65.113.230.90 53 udp 21365 - - - - - 2SERVFAIL F F F F 0 - - T
2016-02-01T08:48:12-0700 x.x.x.x 420 65.113.230.90 53 dns_unmatched_reply - F bro

The packet capture showed this:
2016-02-01 08:48:12.311086633 65.113.230.90 → x.x.x.x DNS 89 Standard query response 0x5375 Server failure A otqxwnenalwb.www.1818my[.]com < [] added by me

And syslog shows the dropped packet:
Feb 1 08:48:12 kernel: [157335.232732] IN=ppp0 OUT= MAC= SRC=65.113.230.90 DST=x.x.x.x LEN=73 TOS=0x00 PREC=0x00 TTL=249 ID=23786 PROTO=UDP SPT=53 DPT=420 LEN=53

I believe all these replies are unsolicited…here’s more info from the pcap:

1 2016-02-01 07:27:04.816315071 162.227.35.49 → x.x.x.x DNS 80 Standard query response 0x5375 Server failure A xec.www.1818my.com
2 2016-02-01 07:29:06.691950594 69.165.170.13 → x.x.x.x DNS 86 Standard query response 0x5375 Server failure A hdjxvefrc.www.1818my.com
3 2016-02-01 07:43:15.851708630 77.245.146.9 → x.x.x.x DNS 78 Standard query response 0x5375 Server failure A x.www.1818my.com
4 2016-02-01 07:58:16.362832986 185.37.170.75 → x.x.x.x DNS 84 Standard query response 0x5375 Server failure A mvaakbx.www.1818my.com
5 2016-02-01 08:21:34.161432864 200.66.71.204 → x.x.x.x DNS 91 Standard query response 0x5375 Server failure A qpohqpuhyhydkx.www.1818my.com
6 2016-02-01 08:34:15.116312435 177.38.182.14 → x.x.x.x DNS 80 Standard query response 0x5375 Server failure A xba.www.1818my.com
7 2016-02-01 08:46:06.804898711 180.166.211.154 → x.x.x.x DNS 89 Standard query response 0x5375 Server failure A cnmxiditebuh.www.1818my.com
8 2016-02-01 08:48:12.311086633 65.113.230.90 → x.x.x.x DNS 89 Standard query response 0x5375 Server failure A otqxwnenalwb.www.1818my.com
9 2016-02-01 09:50:28.034713107 86.53.30.145 → x.x.x.x DNS 80 Standard query response 0x5375 Server failure A xbd.www.1818my.com
10 2016-02-01 10:45:33.406354013 189.36.206.166 → x.x.x.x DNS 82 Standard query response 0x5375 Server failure A zavyx.www.1818my.com
11 2016-02-01 10:51:52.599903143 188.64.112.107 → x.x.x.x DNS 78 Standard query response 0x5375 Server failure A x.www.1818my.com
12 2016-02-01 10:55:32.267107992 66.79.47.97 → x.x.x.x DNS 90 Standard query response 0x5375 Server failure A nocdefghvwxym.www.1818my.com
13 2016-02-01 11:30:22.634179669 41.223.176.254 → x.x.x.x DNS 88 Standard query response 0x5375 Server failure A yzxeuexhebp.www.1818my.com
14 2016-02-01 11:37:14.661145722 209.200.125.113 → x.x.x.x DNS 91 Standard query response 0x5375 Server failure A edgjgdehunglcx.www.1818my.com
15 2016-02-01 12:27:23.082648045 110.45.190.78 → x.x.x.x DNS 93 Standard query response 0x5375 Server failure A epgxahchmlejcbgn.www.1818my.com
16 2016-02-01 12:48:26.354106148 195.208.51.100 → x.x.x.x DNS 90 Standard query response 0x5375 Server failure A nbcdefguvwxlz.www.1818my.com
17 2016-02-01 13:21:15.031248372 38.100.165.4 → x.x.x.x DNS 90 Standard query response 0x5375 Server failure A nbcqesguijxlm.www.1818my.com
18 2016-02-01 13:24:04.308343363 117.204.35.201 → x.x.x.x DNS 78 Standard query response 0x5375 Server failure A x.www.1818my.com
19 2016-02-01 13:47:54.805174964 216.227.105.205 → x.x.x.x DNS 158 Standard query response 0x5375 No such name A gaxavkciclt.www.1818my.com SOA rad0.elltel.net
20 2016-02-01 13:55:47.810864539 208.106.155.144 → x.x.x.x DNS 82 Standard query response 0x5375 Server failure A craxx.www.1818my.com
21 2016-02-01 14:03:28.220225897 120.151.219.248 → x.x.x.x DNS 89 Standard query response 0x5375 Server failure A uzuxwlodybgn.www.1818my.com
22 2016-02-01 14:30:31.689614428 40.134.192.119 → x.x.x.x DNS 108 Standard query response 0x5375 A mamzjnvojxeopzr.www.1818my.com A 127.123.45.67
23 2016-02-01 15:04:36.756997582 219.163.72.226 → x.x.x.x DNS 80 Standard query response 0x5375 Refused A xoo.www.1818my.com
24 2016-02-01 16:10:37.693277685 198.71.54.86 → x.x.x.x DNS 78 Standard query response 0x5375 Refused A x.www.1818my.com
25 2016-02-01 16:23:06.072114319 95.79.36.228 → x.x.x.x DNS 86 Standard query response 0x5375 Server failure A xqzxqckbl.www.1818my.com
26 2016-02-01 16:44:48.085836197 86.62.78.132 → x.x.x.x DNS 93 Standard query response 0x5375 Server failure A cjmxkxwvixoxmdoj.www.1818my.com
27 2016-02-01 16:45:53.057522907 110.137.88.41 → x.x.x.x DNS 80 Standard query response 0x5375 Server failure A xzi.www.1818my.com
28 2016-02-01 17:49:34.389252897 46.10.71.248 → x.x.x.x DNS 80 Standard query response 0x5375 Server failure A xrz.www.1818my.com
29 2016-02-01 18:13:04.732047378 192.198.208.163 → x.x.x.x DNS 90 Standard query response 0x5375 Server failure A abpdrsguijxlm.www.1818my.com
31 2016-02-01 20:07:53.110496413 60.6.223.26 → x.x.x.x DNS 107 Standard query response 0x5375 A ifoxmncxspsxkx.www.1818my.com A 127.0.0.1
32 2016-02-01 23:41:16.181497169 84.120.111.129 → x.x.x.x DNS 89 Standard query response 0x5375 Server failure A ahcxsfedofit.www.1818my.com
33 2016-02-02 00:04:54.704232888 68.153.208.145 → x.x.x.x DNS 92 Standard query response 0x5375 Server failure A zscwrvdouxlhhkb.www.1818my.com
34 2016-02-02 00:22:04.204288331 188.171.5.71 → x.x.x.x DNS 91 Standard query response 0xc737 Server failure A cxyvqralibkjux.www.1818my.com[Malformed Packet]
35 2016-02-02 00:23:21.751179271 60.2.46.214 → x.x.x.x DNS 94 Standard query response 0x5375 A x.www.1818my.com A 127.0.0.1
36 2016-02-02 00:31:50.457266962 202.4.227.99 → x.x.x.x DNS 82 Standard query response 0x5375 Server failure A goylx.www.1818my.com
37 2016-02-02 01:25:38.118660850 77.85.169.52 → x.x.x.x DNS 91 Standard query response 0x5375 Server failure A czipcjorufyxgx.www.1818my.com
38 2016-02-02 01:28:33.637461325 210.227.116.101 → x.x.x.x DNS 92 Standard query response 0x5375 Server failure A ezcuarfwvxdotau.www.1818my.com
39 2016-02-02 01:55:14.214997203 220.157.103.38 → x.x.x.x DNS 88 Standard query response 0x5375 Server failure A lixgvrowxjb.www.1818my.com
40 2016-02-02 02:02:32.277401732 207.30.133.65 → x.x.x.x DNS 92 Standard query response 0x5375 Server failure A nfwnvkmqpxxjbof.www.1818my.com
41 2016-02-02 02:55:41.387701175 50.240.13.113 → x.x.x.x DNS 80 Standard query response 0x5375 Refused A xji.www.1818my.com
42 2016-02-02 03:04:08.783792035 203.115.19.200 → x.x.x.x DNS 92 Standard query response 0x5375 Server failure A npcmbhqulxaxrzm.www.1818my.com
44 2016-02-02 03:43:48.400021981 94.229.95.156 → x.x.x.x DNS 88 Standard query response 0x5375 Server failure A gdxypnfowcc.www.1818my.com
133 2016-02-02 10:24:15.482620371 101.99.20.163 → x.x.x.x DNS 92 Standard query response 0x5375 Server failure A jqysdilejxcznxr.www.1818my.com
134 2016-02-02 10:38:53.528569603 90.154.197.253 → x.x.x.x DNS 82 Standard query response 0x5375 Server failure A uacvx.www.1818my.com
135 2016-02-02 10:51:19.133470580 86.102.168.66 → x.x.x.x DNS 82 Standard query response 0x5375 Server failure A lxxax.www.1818my.com
136 2016-02-02 10:56:28.214752509 163.23.118.1 → x.x.x.x DNS 86 Standard query response 0x5375 Refused A fmhxnyfya.www.1818my.com
137 2016-02-02 10:56:48.808973842 193.8.47.24 → x.x.x.x DNS 82 Standard query response 0x5375 Server failure A mdhyx.www.1818my.com
138 2016-02-02 11:34:38.020879046 193.106.93.233 → x.x.x.x DNS 78 Standard query response 0x5375 Server failure A x.www.1818my.com

Of interest is that every single one of these is source from 53, and destination is 420, which is why they continue to get dropped at my firewall. Very curious. I’m going to switch the capture to full on dns and see what comes up. More to come…thank you.

James

It looks unlikely that Bro missed the request based on the hostname in the query.

That looks like the DNS server is getting attacked with a spoofed DNS query flood, and is sending DNS responses to the spoofed addresses, and one of the spoofed addresses just happened to be one of James’ IPs, so Bro is really seeing a response that it didn’t see a request for, because the request came from some attacker out on the Internet. In other words, it’s backscatter from someone else being attacked.

The hostname in the query looks like it’s has extra randomized text prepended to an actual hostname to avoid caches and to cause as much load on the DNS server as possible.

Yep, I believe that's exactly right. Bro is also (correctly) flipping the connection around which you can see in the conn.log because the originator of the "connection" never sent any packets.

  .Seth

Ok cool…we are all in agreement that this is an unsolicited DNS response. However…wouldn’t this:

2016-02-01T08:48:12-0700 x.x.x.x 420 65.113.230.90 53 udp dns - - - SHR T F0 d 0 0 1 73 (empty)
2016-02-01T08:48:12-0700 x.x.x.x 420 65.113.230.90 53 udp 21365 - - - - - 2SERVFAIL F F F F 0 - - T
2016-02-01T08:48:12-0700 x.x.x.x 420 65.113.230.90 53 dns_unmatched_reply - F bro

be something instead like this (the below is a made up entry):

2016-02-01T08:48:12-0700 65.113.230.90 420 x.x.x.x 53 dns_unmatched_reply - F bro

Not trying to beat a dead horse here…just trying to understand how Bro is treating a DNS response that it never saw requested. Thanks all.

James

Hah, not a problem. A lot of this stuff has so many edge cases and fairly arbitrary decisions on how to handle various situations deep down in scripts.

I am actually seeing the issue you're getting now. It's like the IP addresses were flipped but the ports weren't. To be completely honest, I don't know what's causing that without seeing the actual traffic. Could you send a packet that causes this behavior?

  .Seth

Hi,

I am actually seeing the issue you're getting now. It's like the IP addresses were flipped but the ports weren't. To be completely honest, I don't know what's causing that without seeing the actual traffic. Could you send a packet that causes this behavior?

I think you are talking past each other. If I am not mistaken, James is
struggling with the originator/responder pattern of Bro. I guess he just
forgot to swap ports in his made up log line.

So the question would be: Why is the source IP logged as the responder's
IP for the unmatched reply?

That would be because source/destination is not equal to
originator/responder. At first Bro assumes the source is the originator.
But then Bro identifies the packet as a DNS response and therefore
determines the source IP as the responder's IP. So orig/resp get flipped
as Seth wrote:

Bro is also (correctly) flipping the connection around which you can see in the conn.log because the originator of the "connection" never sent any packets.

Did I get this right, James, or are you really struggling with flipped
ports?

Jan

Thanks Jan…I think I finally explained it well enough that Seth is able to look at it. At the end of the day the question for me is when an unsolicited dns response comes in from source port 53 to destination port 420, why does bro show my machine as the originator of the traffic. Guess I should have just said that in the first place 8-|

James

Hah, I actually answered your question in the first reply, but then I got confused when I looked at your reply to that email.

Anyway, what Bro is doing is using port 53/udp as a heuristic and it's taking a guess that it may have the originator and responder backwards so it flips them. One thing I've been meaning to add for a long time is an indicator in the conn.log for connections that were flipped. At the very least it would be nice to know if Bro flipped the connection in it's attempt to analyze the traffic correctly.

It does make for some subtlety in analyzing logs if you don't know that Bro is doing that. Especially in cases like this where only a single packet was sent from outside your network. The biggest thing to keep in mind that originator and responder are very different concepts than source and destination. src and dst work perfectly if you're talking about individual packets, but when you're talking about a connection composed of two flows and many packets, originator and responder work much better.

.Seth