Conn log shows massive file transfer inbetween normal browsing

Zeek
1

I'm having some anomalies in my conn.log.

Scenario:

Internal host on my network (10.10.10.10) is browsing autotrader (20.20.20.20)

Inbetween normal bro logs for the related traffic, I have things like this showing up:

// conn.log
1524177777.577777 Ccq8hi7x7jIegYyKE7 10.10.10.10 63971 20.20.20.20 443 tcp - 0.015780 1284714853 0 S0 T F 0 Sa 1 48 1 44 (empty)

As I'm reading this, it shows my internal host sent ~1.2gigs of data in .015 seconds to this external host.

S0 for the conn_state "Connection attempt seen, no reply."

So bro thinks my host tried to send 1.2 gigs off-site but failed? (there are many more similar log entries for the same host)

Any ideas what can cause this?

Thanks,
Eric

2

that's probably a websocket connection or something that is idle for long periods of time. Since it's idle for so long bro is assuming the connection ended and is then getting confused when they start talking again. You can fix it by redeffing this value to be higher:

## If a TCP connection is inactive, time it out after this interval. If 0 secs,
## then don't time it out.

3

Justin,

Thanks for the response.

You can figure out how high it needs to be based on how frequently you are seeing that connection logged.

Here are some more of the logs (chopped down for readability). You can see there are multiple "large transfers" in a small time window, less than 5 minutes. Does this mean setting the window higher isn't going to make a difference since I'm already seeing connections more frequently than 5 minutes?

4:38:33.098 PM - 10.10.10.10 63962 20.20.20.20 443 tcp - 0.015809 73288814 0 S0
4:38:31.815 PM - 10.10.10.10 63951 20.20.20.20 443 tcp - 0.015764 1834934747 0 S0
4:38:31.565 PM - 10.10.10.10 63949 20.20.20.20 443 tcp - 0.015718 616216164 0 S0
4:38:28.952 PM - 10.10.10.10 64031 20.20.20.20 443 tcp - 3.014994 1213244309 0 S0
4:38:28.701 PM - 10.10.10.10 64028 20.20.20.20 443 tcp - 3.023816 1777413339 0 S0
4:38:28.329 PM - 10.10.10.10 64024 20.20.20.20 443 TCP_ack_underflow_or_misorder - F worker-2
4:38:28.313 PM - 10.10.10.10 64024 20.20.20.20 443 tcp - 3.017128 0 0 S0
4:38:28.272 PM - 10.10.10.10 64022 20.20.20.20 443 TCP_ack_underflow_or_misorder - F worker-2
4:38:28.257 PM - 10.10.10.10 64022 20.20.20.20 443 tcp - 3.010362 0 0 S0

I included the tcp_ack_underflow_or_misorder from weird log too in case that sheds any light.

-Eric

4

Justin,

Thanks for the response.

You can figure out how high it needs to be based on how frequently you are seeing that connection logged.

Here are some more of the logs (chopped down for readability). You can see there are multiple "large transfers" in a small time window, less than 5 minutes. Does this mean setting the window higher isn't going to make a difference since I'm already seeing connections more frequently than 5 minutes?

4:38:33.098 PM - 10.10.10.10 63962 20.20.20.20 443 tcp - 0.015809 73288814 0 S0
4:38:31.815 PM - 10.10.10.10 63951 20.20.20.20 443 tcp - 0.015764 1834934747 0 S0
4:38:31.565 PM - 10.10.10.10 63949 20.20.20.20 443 tcp - 0.015718 616216164 0 S0
4:38:28.952 PM - 10.10.10.10 64031 20.20.20.20 443 tcp - 3.014994 1213244309 0 S0
4:38:28.701 PM - 10.10.10.10 64028 20.20.20.20 443 tcp - 3.023816 1777413339 0 S0
4:38:28.329 PM - 10.10.10.10 64024 20.20.20.20 443 TCP_ack_underflow_or_misorder - F worker-2
4:38:28.313 PM - 10.10.10.10 64024 20.20.20.20 443 tcp - 3.017128 0 0 S0
4:38:28.272 PM - 10.10.10.10 64022 20.20.20.20 443 TCP_ack_underflow_or_misorder - F worker-2
4:38:28.257 PM - 10.10.10.10 64022 20.20.20.20 443 tcp - 3.010362 0 0 S0

hmm, that is showing 7 different tcp source ports, so this wouldn't be the same connection. If you search for 63949 do you find earlier matches?

I included the tcp_ack_underflow_or_misorder from weird log too in case that sheds any light.

-Eric

It's probably realted..

5

Here are the matching source port entries for the last 3 connections.

The other two from ports 64031 and 64028 did not have any others from those ports.

The connection IDs are different throughout, I've included them this time around.

4:38:31.565 PM CmtAeYrQjXqUGW4xi 10.10.10.10 63949 20.20.20.20 443 tcp - 0.015718 616216164 0 S0 T F 0 Sa 1 48 1 44
4:38:22.566 PM CiyCGi1xwft9PDrqG9 10.10.10.10 63949 20.20.20.20 443 tcp - 3.013144 616216164 0 S0 T F 0 Sa 2 104 2 88
4:38:31.815 PM Cv2Tqo4ErGAdpsnth2 10.10.10.10 63951 20.20.20.20 443 tcp - 0.015764 1834934747 0 S0 T F 0 Sa 1 48 1 44
4:38:22.817 PM CYpYXo175dS7gtQ1p1 10.10.10.10 63951 20.20.20.20 443 tcp - 3.011727 1834934747 0 S0 T F 0 Sa 2 104 2 88
4:38:33.098 PM C3g5Yo4goIOLJEzvSh 10.10.10.10 63962 20.20.20.20 443 tcp - 0.015809 73288814 0 S0 T F 0 Sa 1 48 1 44
4:38:24.099 PM Cv9aWbc0kwMKi7BC2 10.10.10.10 63962 20.20.20.20 443 tcp - 3.007776 73288814 0 S0 T F 0 Sa 2 104 2 88

Is there any significance to the orig_bytes and S0 conn state?

I'm considering filtering these log entires but not sure if I would end up filtering any 'real' traffic in the process.

Eric

6

Now that I look closer at this i think my original comment was wrong, if these were long connections that bro was getting confused about, the history field would be Da (data + ack), not Sa (syn + ack).

Are other connections logged properly by bro ? Connections with a full history of something like ShAdDafF?

would be interesting to see a pcap of the traffic between those two hosts, then you could see if the system is even getting the full 3 way handshake or not.

7

I sent a few screenshots and the pcap for 63949 out of band. 3 way handshake not present.

For clarity, the bro conn log is coming from a sensor that is being fed a decrypted stream of 443 traffic.

I run snort/sancp full packet capture on the same box (same stream) and it doesn't have any data for these connections at all.

My other sensor that gets the encrypted traffic does see the connections, which is where I sourced the pcap but as you can see it doesn't show a huge chunk of data like the bro log does.

Are other connections logged properly by bro ? Connections with a full history of something like ShAdDafF?

In general? Yes. I've had bro running at my site for a number of years now.

For these specific connections no. The only conn state I have for 10.10.10.10 to 20.20.20.20 is S0.

-Eric

8

Ah.. that explains it, seems whatever device that is decrypting the ssl traffic is sending garbage to bro.