Need help understanding how the following happened. I am definitely not an expert. The following hacking attempt happened to my HomeAssistant server from an IP address in Singapore, and I am trying to figure out how they got through my firewall default deny WAN rule. I have no ports open or forwarded at all. Here is report from my HASS server: I do not have any Apple Macintosh machines, though I do have a HomeKit bridge and HomeKit devices, and an iPhone.
Logger: homeassistant.components.http.ban
Source: components/http/ban.py:138
Integration: HTTP (documentation, issues)
First occurred: 6:19:26 AM (1 occurrence)
Last logged: 6:19:26 AM
Login attempt or request with invalid authentication from 104.28.222.47 (104.28.222.47). Requested URL: ‘/api/config’. (Mozilla/5.0 (Macintosh; Intel Mac OS X 14_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.4 Safari/605.1.15)
would love any insights or comments you might have…
seems the would be attacker was using a MacIntosh… I am on Windows.
could it be my HASS server is compromised and advertising its location to the outside ? or woudl it be my windows machine which I use to log-in to the HASS server ?
That’s fine. Is that the only rule? If not what about other rules?
Also how do you reach back to your HA when you are out and about? Or you simply don’t do that?
pfsense should have got plenty of logs and this event should show up somewhere - otherwise you’d have other problem on the firewall side. Anywhere in any of those logs saying the same IP? Or what do you see around that time frame?
Thank you for that; I’ve read the post. However, in my case the “attack” came from the outside (Singapore according to the IP geolocation) and somehow it knew the LAN IP for my HASS server…
I use the Nabu Casa suscription to access my HASS from outside.
Thanks for the notes ! I do have outbound firewall rules, but absolutely no inbound rules for the WAN. I’ve checked the State Table in pfSense, and my HASS server has 3 states active, none of them is for the IP in question:
all HomeAssistant server (HASS) states:
10.121.1.60 → 3.216.7.170 Amazon Technologies Inc. USA
10.121.1.60 → 40.160.72.112 OVH US LLC
10.121.1.60 → 52.203.190.4 Amazon Technologies Inc. USA
I am also inquiring with the pfSense forum, and this is a recent comment I got, when I stated I used Nabu Casa’s service for acessing my HASS instance from the outside:
“Oh geez, that should have been your first suspect. A remote access service for your home assistant. Someone is likely scanning the urls the service uses to let you access your instance.”
And EXACTLY what i said - Script kiddies - this is how it works - Automatic scanning.
The ipaddr can be represented by an external addr or it can passthrough the real external addr depending on source traffic etc. That said it’s almost certainly a redirect through some unsuspecting user’s pwn’d pc…
Same thing as the thread above. Your choices are.
Don’t expose your instance
use a VPN based connection that is not visible to the outside.
Have enough mitigation to not worry about it.
I use a combo of those but for opsec Im not telling you which (it’s not #1)
Most are not interested in YOU unless you’ve pissed off a nation-state recently the remaining baddies are just scraping as many fish up as they can and running them through known nets. AI makes this PNENOMONALLY faster and cheaper for the bad guys.
Many thanks for the reply ! …I figured using Nabu Casa’s service woudl be “safe” …I believe Nabu Casa uses some sort of VPN connection ? option #1 is not an option for me, as I do need access to HASS from the outside… I think I get “your drift” on #2, and may add MFA to login to my HASS server (though that is a bit of a PITA when I am away)…
They (Nabu) CANNOT - like Commander Scott, laws of Physics kind of cannot) block the caller else they’d block YOU… How can they possibly know you aren’t that person until AFTER challenge fails - at which they drop the caller and you get that logitem. And an ipban entry if it becomes repeated and/or excessive.
If they dropped the session you at anytime BEFORE… you don’t get in. If we could tell it was you in the first place - they would but chicken… meet egg.
A Vpn - like WireGuard, TailScale doesn’t have an endpoint advertised like that UNLESS you’re already logged in to another service somehow - SO there’s your I know who you are, therefore I can prevent NOT YOU from seeing the endpoint
If you still want it exposed AND want to be protected - yes you have the right idea.
LONG Secure password (OVER 15 characters alphanumeric and complex)
and/or
(I prefer) a passphrase - something REALLY PHREAKING long 20+ char including alphanumerics and complex that you can actually remember offhand
and/or
Your preferred MFA provider. (Really if you’re going to expose it I like this at a MINIMUM bar)
Thanks again. I’d be lying if I say that I understand everything you say (…not as savvy as I’d like ot be…LOL) but I think I get the gist of it. I had been considering Tailscale, and maybe that will be a good option. Also, I was not aware of the last bits you mention, but will look into them, Thanks !
..however, from some of your comments I gather that perhaps my PC is infected and thus the leak enabling this attack try? I have ran MRT and Defender often and no infections, though I suppose that does not mean I am 100% fine…
anyways, thanks again ! hopefully this will not keep on happening…
Nope.
This is your guess, and there is no evidence so far in this thread. If you want to prove your guess to be true, find the evidence to approve or disapprove. Otherwise this remains to be your guess.
And then, you have the IP and you have the time stamp in the first post. Are you sure you do not see anything happening in any pfSense logs??
Is the state table above from the time of the event?
Thank you both for the last two notes. My logic was that perhaps my PC (if infected) at some point made a connection to the outside and leaked my LANs info (including the HASS server IP) etc, which then allowed the attack to come from the outside… however,as stated, I haveno proof of this, so yes, it is my guess, and likely a wrong one…
The states table I included earlier was at the time I wrote the post, so much later than the attack, and the firewall logs had nothing on this at the time.
Following is another comment from my inquiry at the pfSense forum, which the poster helping me got from Claude:
From Claude:
"Why guessing doesn’t work but discovery does. The subdomain is a long random hex string, so brute-forcing the namespace is hopeless, and you can’t find instances by port-scanning either, since nothing is listening on your IP — everything terminates on Nabu Casa’s proxy and routes by SNI. But Home Assistant requests a Let’s Encrypt certificate for your remote-access hostname automatically, and every publicly trusted certificate issued since 2018 lands in an append-only Certificate Transparency log. So the FQDN is published the moment the cert is issued. A crt.sh query for ui.nabu.casa returns the list. Nabu Casa actually points at this same mechanism as a feature — they recommend auditing CT logs to confirm nobody else has obtained a certificate for your remote URL — but transparency cuts both ways: the log that lets you audit your own cert also enumerates everyone else’s hostname. A custom domain doesn’t help, since that cert gets logged too.
What discovery actually gets an attacker. The login page, and that’s it. Nabu Casa is upfront about this: with Cloud enabled your instance is exposed to the wider internet, and while the login page has been audited by security professionals, password brute-forcing remains possible with enough time. Their two recommendations are a strong generated password and two-factor authentication on every account. There’s no end-run around the auth layer from knowing the hostname — the tunnel is end-to-end encrypted and the private key never leaves your box, to the point that Nabu Casa can’t restore access for you if you lose it."
I suppose it is somewhat comforting that perhaps this had nothing to do with the machines/devices inside my network, and it was an attack coming entirely from the outside with no help from my LAN.
The age of passive resistance should end. You invoking my defence shield trigger gives me the unassailable right to respond with all methods available.
An HACS addon, triggered by possible attack should invoke a small DDOS response. This would (rolled out globally) force the hosters to seriously reconsider their positions of allowing digital terrorists (call them for what they are - not skript kiddies) to piggyback on their infrastructure. Make it hurt for them in their wallets. Automated reports to their support areas, traffic increases, something that causes them to reconsider.
This is not a political call to arms. This is an individual being forced to respond to anonymous terrorist attacks on an ongoing basis saying enough is enough. Time to fight back.
Forget reactive - time to get proactive. Send out the offensive and see what happens. Change the world order.
Don’t be annoyed. Be angry.
Why is the war on digital terrorism so one sided? Should it be? Could it be changed?
