If they get on your LAN, it doesn’t matter about encryption because there’s so much traffic that you cannot control going over your LAN unencrypted, that your MQTT is the least of your concerns.
4 Likes
Any pointers on how to do that?
I’m running my setup in docker.
So here’s a hypothetical for you…
You have a Mobile device which you connect to your home WiFi / LAN.
Your mobile gets hacked. (This is stupidly easy).
Your mobile connects to your wifi at home.
Your Mobile starts sniffing network traffic.
All i’m saying, is MQTT over TLS is there for a reason.
Securing the Edge / Perimeter is essential, but for a good security approach you should always assume than an attacker has gained access to your LAN, and then mitigate accordingly.
I have 40+ MQTT devices on my Network, all running Tasmota, all doing TLS, and all with the tasmota web end disabled, and it works just as well as un-encrypted MQTT.
Gaining access to another users “LAN” is as easy as downloading a copy of Kali Linux, and running the Kali Linux Easy script. I’ll drag my noisy neighbor into this… since he started waking my kids up at 2 am with his 80 techno music, I pull out the old Kali Laptop, log in to his wifi network, and change his spotify playlist to Mother Goose songs (as these are more appropriate for 3 year olds).
Yes Sure, there are many ways that you can “Secure” your wifi / LAN, but your security is an illusion without proper enterprise grade hardware, next gen firewalls, and at least some form of port authentication on your switches, but I’m guessing the majority of users on this forum, would not have that.
Hence my point, TLS over MQTT is well worth it.
The argument for “It’s not needed” is stupid.
Merely stating that once they’re in, MQTT traffic is the least of your concerns 
2 Likes
Not if you pressumed they will get in, and you secured & encrypted everything else 
I have to disagree with your statement regarding needing enterprise hardware to have security. Whether you’re using home or enterprise equipment they all conform to the same standard. WPA2 is the same on either type of hardware.
If you hacked into your neighbours WiFi it was due to them using WEP and not WPA/WPA2.
The most important thing on either home or enterprise hardware is to have a device that’s still supported and to apply all security updates.
Not true, WPA has serious flaws, and WPA2 is vulnerable to quite a few different types of attack vectors.
Could you provide some references for practical efficiency? I do have heard of flaws. But those were more of theoretical nature requiring computation power not available to average users. If all that is needed is a beefy mining rack I’d accept that as a valid issue for people who believe they could become victims of highly targeted attacks.
1 Like
I doubt these attacks are common in the wild, certainly not against non-interesting residential WiFi networks.
This website goes into one of these attacks quite nicely, but makes this concession:
We are not in a position to determine if this vulnerability has been (or is being) actively exploited in the wild.
Are hackers already exploiting this vulnerability?
Not yet. But as with many newly discovered vulnerabilities, it is only a matter of time before hackers find ways to exploit this weakness to their advantage.
Most of the vulnerabilities are due to faults in WPS or through brute force dictionary attacks. If your password is more then a simple, single word then brute force is realistically not going to work. Disabling of WPS should be automatic if the router is still supported and the firmware is up to date.
@danielperna84 here what @JumpMaster said as well as the deauth attack vector.
Apparently WPA3 (WiFi 6) is nearly unbreakable from what I am hearing and reading.
Just sharing my experience with security.
I was just another HA user, exposed my instance to the internet by using DuckDNS with LetsEncrypt. Everything password protected and IP Ban enabled after 5 attempts. I am also using NGINX Proxy.
Then I moved to having my own domain and using Cloudflare. On Cloudflare I set the Firewall to:
- Show JScript Challenge to high risk countries (China, Brazil, Bulgaria, Hungary, Russia, etc)
- Block well known bots (bad or good, I just whitelisted GoogleAssistant which is considered a bot),
- Block IP with high treat scores,
- JS Challenge the ones with low threat scores
- Browser Integrity Check
- Security Level to Medium (will challenge more visitors with a Challenge)
Advantages of Cloudflare is that your IP is never exposed unlike DuckDNS or Route53, when you’re using their DNS service they will be a proxy. So trying to resolve my domain actually exposes Cloudflare proxy servers, not the origin server. On Route53 or DuckDNS it will expose your real public IP.
I thought I was alright, I saw nothing wrong or strange going on, the IP ban never banned other IP other than my own when I was testing or making changes on HA.
I had some issues at work when accessing my instance because of the JScript Challenge (I whitelisted my IP later on), also Google Assistance wouldn’t work sometimes until I whitelisted it.
I thought I was golden when it came to security, only one port open in my router, NGINX, everything password protected, IP Ban, Cloudflare firewall, 2FA, etc.
Then I started using using UniFi USG and ditched my not so old router and enabled the IPS (Intrusion Prevention System) in the USG this is what I got in just a few days:
The DShield and Spamhaus all happened when I was torrenting, probably nothing to worry about, most likely false alerts just because these IPs are flagged. However the remaining attacks captured by the IPS of USG were all related to exploit attempts, mainly these two types:
- ET EXPLOIT Joomla RCE M2 (Serialized PHP in UA)
- ET EXPLOIT Joomla RCE (JDatabaseDriverMysqli)
Just so you guys know I am not using Joomla, Wordpress or anything related. As soon as these are detected the source IPs are being blocked. But I am surprised by this…
I would have never know about all of these security risks if I hadn’t switched to UniFi USG or enabled the IPS. I was using a TPLink Archer C9 v5 which is supposed to be quite a decent router, however I couldn’t flash DDWRT into it and the device_tracker component stopped working with the original firmware so that’s what made me change my router.
Nearly all consumer routers don’t have a decent IPS/Security settings aside from a standard Firewall and maybe flood filtering or DDoS protection.
Definitely gonna use Firewalls, probably even move onto PfSense or go the VPN way, however I still need to expose my instance for Google Assistant and HTML5 notifications.
Nabu casa doesn’t offer HTML5 push notifications as far as I am aware, do they? At this point I am bit concerned by the security. I heard changing ports to non standard ports (for example 443 to 1443) will definitely bring down these risks by quite a lot, as most of these are bots scanning or running exploits on well-known popular ports and for popular platforms such as PHP web servers, Joomla, Wordpress, etc.
How do you do that ?
You could also implement Cloudflare Access to limit the access to your domain.
This:
So basically a Firewall Rule that blocks all Known Bots (there’s no way to whitelist or blacklist specific bots, it will block ALL bots), then you create an URI rule that allows your Google Assistant callback URI as per the Google Assistant docs and set it with higher priority:
https://[YOUR HOME ASSISTANT URL:PORT]/api/google_assistant
In my case I just set one rule, URI type with “contains=api/google_assistant” and set to allow, and moved it to the top of my list.
Or if you want to do it properly then you allow based on IP addresses from Google servers.
1 Like
Is this traffic on an open port or actually communicating with anything on your network?
There are a ton of bots and scanners out there. Your router by default drop all traffic that you aren’t allowing in. This could all be noise unless actually on an open port or related to actual traffic on your network.
1 Like
@silvrr The IPS will not report anything that is not trying to get thru any open ports, so in this case all of these alerts are actually trying to get to my actual HomeAssistant instance.
I can see some alerts from my own IP trying to get out and my IPS dropping these connection as they some were found to be going to flagged IPs (just torrenting).
Do you know how to blacklist IPs using the NGINX Proxy Manager? There’s quite a lack of documentation and I am using the version which is mostly UI based.
@elRadix As for Cloudflare Access is 3 and 5 bucks respectively, which is not bad but I’d rather keep it free or just switch to Nabu Casa which will cost me exactly the same without all the overhead.
Have you give it a try tho? I am curious to see how this will affect MQTT or Ariela Android Client, I don’t think the later one will work at all. The good thing is that I could expose more stuff on like Plex, Nextcloud and so on and just pay 3 bucks a month… Because of NGINX they won’t be able to get in just with my origin IP and if they try to get in by domain name they would run into Cloudflare Access. I think I will give it a try and report back on it…
Cloudflare Access is free for up to 5 connected users. I have 2 users connected never had to pay.
For Ariela this would not work unless the dev adds support to the app.
Overall it’s much more secure as you have the control who will have access to your domain.
1 Like
Yeah, you’re right. I will definitely go the Cloudflare Access route and I think I will try to get Ariela working some other way, most of the time I will be connected via VPN and I only need it for the device_tracker so I will still be able to use as long as I am connected to my VPN.
Do you have port 443 open by chance? I saw a lot more noise on my instance while opening 443. With 8123 open I get 1-2 hits a day and mostly from known scanners (shodan, stretchoid).
It’s been awhile since I dropped my USG, but I recall you could block by region with it. Why not drop China?
Edit: may be easier to whitelist the countries you need. Not sure if the USG can do this though.
1 Like
@silvrr Yes, I have port 443 open. And yes the USG has GeoIP Filtering but there’s a caveat… You either use the GeoIP Filtering or the IPS, but you can’t have both active at the same time because they haven’t figure out that yet at Ubiquiti. 
At this point I’d rather keep using IPS as I can see the benefit of it when you have open ports and it also monitors the outgoing traffic.
Cloudflare access seems to be working like a charm tho but it breaks Google Assistant. I could set a bypass policy for Google API server IPs but nothing useful comes up from a few web searches. Basically all the info is outdated or they ask you to check your log and do a reverse lookup to see the IPs being used by Google API.
UPDATE:
For those interested in Cloudflare access, just apply Cloudflare access to:
whateverisyourdomain.com/frontend_latest/authorize.html
The important bit is the one in bold. Every time you want to access your instance and you’re not authenticated you will be redirected to it. Once you’re redirected Cloudflare Access will kick in.
This won’t break any webhook, APIs or whatever else you’re running on your instance as these will have their callback URL such as
whateverisyourdomain.com/api/googleassistant/
whateverisyourdomain.com/api/webhook/
Thanks a lot @elRadix. This is definitely the way to go. Now I will monitor, I was starting to get alerts almost every single day, let’s see how it goes from now on! They should hit Cloudflare Access and won’t get past it.
Now I can safely expose my Nextcloud, Plex and so on…
Basically I will have to authenticate on Cloudflare Access (unless I set a rule to bypass this authentication), then the application own authentication method which are mostly backed up by Fail2Ban, IP ban or similar. On top of that the IPS is blocking common exploits and flagged IPs.
More than enough for a commoner which doesn’t have any “important” data in there and will deter most hacking attempts.
1 Like