No, but if your front door isn’t in the same place as everybody else’s, then the less intelligent or lazy will miss it and pass on by.
As I said further up, it’s not security in and of itself, but it does cut down the noise, a lot.
No, but if your front door isn’t in the same place as everybody else’s, then the less intelligent or lazy will miss it and pass on by.
As I said further up, it’s not security in and of itself, but it does cut down the noise, a lot.
Well thanks again, initial testing indicates that works (base_url:
).
How hard would it be to implement some kind of basic&simple security check next to config file check in web UI? See for example Asuswrt web UI that suggests you the most secure settings and shows what risks there are in your current settings.
I use the free tier of cloudmqtt and bridge to it from MQTT hassio addon.
It means that there is no MQTT port exposed by me.
Instead topics (e.g from owntracks) are bridged from the cloud instance to my local instance.
The cloudmqtt instance has TLS encryption on traffic.
For those who believe using a high port doesn’t add to security, try setting up a honeypot to monitor port 22 and port 44103. Report back on your results please. Using port 8123 is like waving a flag saying I have Home Assistant running here. Attacking is far easier if you know what is answering on the inside. If a vulnerability is discovered in HA, I know what port I would be looking for.
I use country blocking. It doesn’t, in itself, make me secure. It does however add to the things I have piled in front of the door. I only have a port for a VPN available. More than two failed attempts, blocks the IP. The fewer attackers I have makes my life easier. The more difficult I can make the attackers job the better. Am I secure? No. Am I more secure than if I only relied on a password. Yes.
Finally, if you aren’t scanning log files every morning, you are missing the most important defense.
Ok… here we go.
How do you do country blocking and what logs do you scan?
I only run a consumer grade ISP router/modem so maybe I don’t have the ability to do either of those things?
You’re almost certainly correct.
If you run a reverse proxy like NGINX you can configure those to do geo blocking.
I believe the UniFi controller now supports geo-blocking
EDIT
Settings>>IP&firewall>>group filtering
Haven’t tried this and no clue how or if it works
You likely don’t have lots of advanced capabilities and that wasn’t necessarily my point. It is really about anything you can do will help security. I have my own router behind the ISP router so I have more capabilities. Advanced capabilities aren’t helpful if you can’t configure them correctly. Misconfiguration is everyone’s enemy. I would say don’t add more than you can reasonably manage and understand. As Tinkerer mentioned, a reverse proxy can add additional protections but make sure you monitor whatever you do add.
Pretty sure you need the Unifi Gateway router for the GEOIP settings. I tried the Gateway but it wasn’t as suitable as what I already have. It would have been nice to have APs, switches and router in one management tool but I couldn’t justify dropping a few capabilities.
Exactly. I have sort of moved from OH2 to HA. The openHAB Cloud Connector does not require incoming traffic. Instead the hosts connect to the web service.
OH provides a service for free that allows IFTTT recipes, but you can host it yourself.
To further mature HA and extend the current (payed) cloud service, this would be a nice feature.
A simple remote solution that does not open any holes is Google Remote Desktop. It is available for any platform. There are Android and iOS apps. You can access it from a Google website. https://remotedesktop.google.com
The only thing that it would be able to suggest is to set a password and enable ssl. Maybe change the default port. That would annoy me when I have it running behind Nginx and don’t need to change those settings.
Hi,
Just read the last comments and it might be wise to ones that are freaking out with hackers to add the following to the http component
http:
ip_ban_enabled: true
login_attempts_threshold: 3
I’ve set this to 5 and tested with some friends that wanted to get in.
it will create a file with IP_bans containing the list of IP that were blocked
afterwards, you can clean the file (delete IPs) if was just a test
Thank you @miguelromao I have implemented that now. By the way the ip_ban_enabled and login_attempts_threshold should be indented from the http line.
no problem.
and you are right on the indentation but this copy and paste is not working on the blockquote.
great you are more secure !
Use code blocks for code.
Just to add a little interesting reading. A security firm set up honeypots to simulate IOT devices exposed to the Internet and collected the data. You can read the report here. https://www.allot.com/wp-content/uploads/Mobile_Security_Trends_Q2_Web.pdf
The short version is that “Immediate successful attacks on the
devices, peaked at a rate of 1000 per hour”. If you aren’t taking measures beyond a password (SSL is not protection, it just protects the contents of the transmission) you need to rethink your security plan.
Hmmm, so lets say you have other devices on your IOT network. Like a Samsung TV, which gets compromised, and a hacker gets access to this, and starts snooping your traffic on your IOT or LAN network…
The argument for “There is no need to encrypt data on your local network” is from someone who has absolutely no clue about Security.
If MQTT traffic is not encrypted, and a malicious user gains access to your LAN / Wifi at home, then the encrypted payloads will contain your MQTT username & Password.
Once someone’s in your LAN you’ve already failed.