Selfhosted: Unexplained Traffic to 3rd Party

[alatark]

When testing in a very controlled environment here (Local windows machine here -> hbbs on Digital Ocean VM -> remote Windows pc here), I can't help notice a moderate but inexplicable amount of traffic from hbbs to a server that appears to be a 3rd party host at Linode. It's roughly 10kbps in and 30kbps out while I have any sessions active, but it doesn't immediately stop when I terminate a session -- it seems to continue for at least several minutes afterwards.

ESTAB 0 0 [::ffff:147.xxx.xxx.xxx]:21118 [::ffff:173.255.212.137]:53726 users:(("hbbs",pid=650,fd=19))

This is coming in on 21118 which I had open as per the instructions, but it's supposedly optional and needed only for web clients. IP 173.255.212.137 seems to be at Linode/Akamai, but I don't know what it could be.

Disabling 21118-19 fixes the problem, and I don't use web clients, so I'll simply leave them closed. But it's worrying from both a security standpoint and also for people who pay for their bandwidth at a cloud provider. 40kbps is 12.6gB/month, which, if one has many sessions, could get expensive.

This shows the network traffic on the server running hbbs, which shouldn't have significant traffic as the sessions are local. Session started at about 18:50. Note traffic continues well after session termination at about 18:55. Note also server restart at 19:32 whereafter port 21118 was closed and the network traffic looks appropriate.

[paspo]

@rustdesk PTAL

[alatark]

Hi - thanks for the quick response.

If, as I suspect, PTAL means please take another look, then I have done so again but still can't discern why hbbs -- the control server intermediating a session between two computers on the local subnet here -- would have this constant traffic to a different server apparently unrelated to us.

Can you point me in the direction to look? Is this related to an unreleased web client feature?

[paspo]

"PTAL" was meant for @rustdesk, not for you, sorry for the incomprehension

[rustdesk]

Comment below two lines will disable websocket totally. Apologize, I do not have enough knowledge to explain your traffic.

rustdesk-server/src/rendezvous_server.rs

Line 284 in 4240c47

self.handle_listener(stream, addr, key, true).await;

rustdesk-server/src/relay_server.rs

Line 347 in 4240c47

handle_connection(stream, addr, &limiter, key, true).await;

[alatark]

Okay, thanks for looking into it. If I have the time later I will fire up tcpdump and see what the packets show. In the meantime, I've simply closed 21118-9 and the issue has gone away.

[paspo]

I just set up a test environment with a debian VM in a subnet, 2 ubuntu VM in another subnet, and tcpdump in the middle.

I used latest docker images: rustdesk/rustdesk-server:latest and I found no "unexpected" connections.
Can you give some extra details on your environment to try to reproduce it?

[alatark]

Okay, so colour me embarrassed.

I got all set up and started a complete professional lab report, with full equipment description, configuration of all relevant software, starting conditions, yada yada yada.

The last thing I did before starting the formal test was to switch the focus to the netdata display (a browser-based monitor displaying the data reported by netdata's hooks in the OS) and bingo, the unexplained traffic started right up. A few experiments show (duh) that the traffic happens only when netdata is in live play mode.

The periods of traffic shown here correlate exactly with the times at which the netdata window was visible and had focus (the indicator automatically switches to "play", whereas it changes to "pause" when focus is elsewhere).

Clearly the traffic is just sampling data from our rustdesk server to the netdata cloud server.

Thanks for the help, and my apologies for the false alarm!
Paul

[paspo]

Thanks for the feedback, and I'm glad to see it's a false positive.

And don't worry, it happens to anybody; what you do after the fact is what makes the difference.