Home Assistant uploads data packet to unknown external IP address

Configuration
1

hi everyone,

My network monitoring device picked up an abnormal upload action from my home assistant towards an external IP address in China. I cannot find which feature (either home assistant itself or one of my integrations) would do this, and why. For now, I have blocked data transfers to this IP, and all my integrations and HA features seem to operate as normal.

When I search for more information about the IP or the port, I end up with no results as to what this data transfer is for. I’m looking for help to analyze this behaviour, please advise.

Abnormal upload
Abnormal upload1053×1620 141 KB

2

Maybe its just a check for updates, like if you use tuya.

3

It’s a lot easier if you tell us what integrations you use.

But 1.39 MB is quite a lot for an update request

4

Good start, thanks for your reply.

add-ons:

  • DuckDNS
  • File Editor
  • Samba Share
  • SSH & Web Terminal

Integrations:

  • AVM FRITZ!SmartHome (router)
  • Google Cast
  • HACS
  • Home Assistant Supervisor
  • Siemens Home Connect (dishwasher)
  • Aurum Huisbaasje/Energyflip (utilities monitor)
  • IPP (Internet Printing Protocol for my printer)
  • Meteorologisk institutt (weather monitor)
  • Home Assistant Mobile App
  • Philips Hue (lighting)
  • Raspberry Pi Power Supply Checker (for my Pi)
  • Shopping List
  • Tado (heating)
  • uPnP (networking)

most of these are stock / auto-discovered.

HACS:

  • card-mod (card)
  • Panasonic Comfort Cloud (air conditioning)
  • simple thermostat (card)

Custom in configuration.yaml:

let me know if you require more information, I am still relatively new with HA :slight_smile:

5

I would say there is two options now.
None of them is particularly fun.

Open the integrations page (documentations) and see if it’s cloud or local.
If it’s cloud then disable the integration and see if that stopped the communication.
If not, then do the same with the next integration until you find the guilty integration.

Or…
Open the integrations page (documentations) and see if it’s cloud or local.
If it’s cloud then open the GitHub page and search for the IP in the code.
I assume the IP should be included somewhere in the GitHub code, but it could also be a DNS name so this method may not work at all.

6

Check your router is not exposing the Samba Share via uPnP using the Shields Up test on this site:

https://www.grc.com/x/ne.dll?bh0bkyd2

7

When I look at the details in the warning again it starts to look like a HA installation that is shared on the internet through a portforward on the router.

8

I performed the test, with a positive outcome:

image
image894×156 7.03 KB

9

Which is why I asked them to perform the uPnP test.

10

Well… a negative outcome, which is positive news. :slight_smile:

Good: That’s that attack vector crossed off the list. It has happened in the past.

Bad: still no closer to determining what is being sent.

I don’t suppose your monitoring software logs the actual packets sent?

11

It did/does not, unfortunately

12

That just test the uPnP function and should have no meaning here.

The connection is initiated from the China IP and connection to the 8123 port on the posters HA device.
This means the port have to be open already.

My guess is that its just an automated script that tries to detect known security holes on web servers.

13

I might not fully understand what you mean, but the only port thing I have configured is incoming traffic through my duckdns address directly towards port 8123 is forwarded to my HA frontend, which is password and 2FA protected.
The 1.39MB was sent from my network towards an outside address, for which I can see no apparent reason for it to do so

14

Since I notice you’re using Firewalla, it is easy to block outging traffic from your HA server to that geo location.

15

Wrong.

uPnP has been known to expose ports externally that it should not. Any hacker casting a wide net for exposed ports could have easily spotted an exposed Samba share, connected and downloaded what was exposed. As I said it has happened here before.

16

The message from the monitor is confusing.
It says it uploaded to 36… originated from 36… with source 36…:12306

Are you sure it’s working correctly and it didn’t just detected some kind of attack?

1 Like
17

I have done exactly that, at least until I find where this comes from :slight_smile:

18

Ok, but would a samba share not be served on port 445 then and not on port 8123?

19

Yeah. Point taken.

20

Its just network terms.

The China IP initiated a connection the the posters router, which is why its listed as the source.
The China IP then uploaded some data.
The terms that confuse is downloading and uploading, since these relate to the viewpoint.

In China the data was downloaded, because they moved towards China IP, but from the posters position the data was uploaded, because the data moved away from the posters IP.

The warning state only that data was moved from the posters IP to the China IP.
There is no info of how much data was moved the other way.
It could be just a few kilobytes in typical requests or it could be much more, if the China IP had write permission somewhere.

This missing information is typical for low-grade IDC systems, since logging and evaluating all that downloaded is a much much bigger task.