Hi,
I have performed some tests using public available MQTT broker services. If you have a solution that generates a lot of messages (like publishing video packages from live sources) you will find out that you very quickly will reach the upper limit of even the most expensive price plan. Price plans for such MQTT cloud services is not a good choice for video transmission. I also made some calculations for an alternative solution like installing a MQTT broker in EC2 (AWS) and that seems to be a much better option, at least from cost perspective
But then I thought, could it not be interesting to check if one could dedicate a RPi in the DMZ and install a personal broker there? Provided it is possible to make it secure enough. That would allow having a personal MQTT broker reachable both from your network and from internet allowing exchange of data in a secure way via MQTT over internet (using No-IP or simlar for hostname)
Any thoughts and ideas how you should secure the RPi in the DMZ in a good way?
Thanks, but that is not what I want, I'm not looking for a secure way to reach my private network, that is already solved, I have a VPN server running since years. Instead I'm looking for the possiblity to have a MQTT broker in the DMZ and make that secure
A DMZ is just a private network hanging off the edge of your LAN.
The trick is to make sure that:
You obviously need a domain name. But also you will need to have a proper certificate. Keep it separate from other certs (e.g. not a wild-card) and only ever push updated certs from your LAN to the DMZ. Never configure a cert update process on the DMZ server. Let's Encrypt is ideal because they enforce a short duration for the cert life. So even if someone steals your private keys, they will be replaced quite quickly.
If you can manage it, only ever push data into the DMZ
If you have to get data out into your LAN, use a PULL method
NEVER let a server in the DMZ have access to something on your LAN - the danger being that if someone manages to break into a server in the DMZ, they will almost certainly be able to break through into your more secure LAN.
Needless to say, you need a firewall between your LAN and the DMZ.
In a home setting, it is likely that you only have the firewall built into your router and so will have to make do. If you have a router with multiple switch ports, you should be able to put the DMZ on a separate port and configure it as a separate network. But whatever you have, if you cannot create a secure separation between your LAN and the DMZ, you will want an additional device that will let you create a separated network.
Obviously, you still need firewall rules between the DMZ and the WAN.
Also obviously, the only ports opened from WAN->DMZ should be the absolute minimum (hopefully jut port 443 and the secure MQTT port). From DMZ->LAN should be none. From LAN->DMZ should also be minimum.
Use different ID's and passwords on the DMZ. Use certificate access to log into the DMZ server from the LAN.
If you can, renumber the secure MQTT port for the WAN (using port translation maybe) since it will reduce the chances of someone scanning it.
Regularly check the server on the DMZ for configuration changes. Even better, push your standard config from the LAN on a very regular basis (at least weekly).
Also obvious: remove all unnecessary software from the DMZ server. Minimum s/w only. Consider actual hardening of the server.
I doubt this is exhaustive but if you can do most of this, you should be more than OK.
Julian, such a fantastic & detailed explanation, excellent! Before I do anything I will check what my existing network equipment is able to provide
M idea is that I could have a MQTT broker like that in the DMZ. The broker itself would have no access at all to my LAN. Systems on my LAN, like NR server would be able to publish and subscribe to topics in the MQTT broker but via the hostname provided by No-IP. So from LAN out via internet and then into the broker in the DMZ so to say, no direct connection from LAN to DMZ. Clients interested in the data would subscribe to the same topics in the same way, no direct connection from clients to the NR server on the LAN. So my thought was to keep it fully isolated from my LAN
Ideally, you would isolate the topics allowed on the DMZ broker and on the LAN broker, only sync those allowed topics and make sure the topics don't overlap with anything that you use internally. Though that does somewhat break the no send rule (DMZ->LAN), it is easier than trying to pull them.
Just make sure that you understand, anything sent by the DMZ broker is NOT TO BE TRUSTED on the LAN. So don't try to directly subscribe to any of those topics without sanitising them first.
Your broker can be set up to do sync of specific topic hierarchies so you can use that.
Just before you put a lot of work into it make sure that 443 inbound is open (as many ISPs block it)
Also check that your inbound secure MQTT port is allowed inbound.
Lots of ways to harden boxes - but i would recommend (if you can) two different firewalls between the LAN and the DMZ
So you would have one that is WAN > DMZ and then a 2nd one that is DMZ > LAN
Preferably based on different OS distributions and firewall packages - something like OpnSense on the internal side (based on BSD) and Untangle on the WAN facing side.
It is really easy to get the impression that publishing services to the internet is super easy. With docker stacks involving nodered, mqtt, traefik/ngnix, letsencrypt, etc. it seems to be a matter of "minutes".
However, there is so much more.
While I actually know about the principle concept of DMZ, I completely "forgot" about it in the context of youtube videos and blogs showing how easy things are. At least at the surface.
This thread is a reminder of the complexity involved to securely publish services to the internet. I was just about to test it (without DMZ), but I will finally stop doing it. Instead I will stick with the solution I find most feasible for me, which is a secure zerotier SDN. It would be a nice learning experience, though. But I am no pro and don't want to put myself at risk here.
It doesn't help you with your request @krambriw, I know. But your initial post as well as the profound input from @craigcurtin and @TotallyInformation reassured me to look elsewhere for challenges, hence I will spend my time with some other puzzles Thanks guys!
Well, while it is sad to put someone off having a go at things, I think that you are taking a wise path. There are far too many problematic networks and servers in the world already with - literally - armies of people and bots looking to exploit them.
If we have raised awareness of some of the complexities then I feel that we have done a good thing for the community.
It is all too easy in IT to assume that knowledge in one area means knowledge in all but of course this isn't true (don't get me started on the run-in's I've had with medical professionals who think that their many years of medical training make them IT experts!).
On the other hand, we should also be pragmatic. So if you need to put something on the web, there are ways to reduce the risk. But, you do need to assess the risks properly, as you have done here, and decide on the best approach.
As always, a warning that what we write here is based on experience but is not in any way professional advice. If you have something of value and need that to be accessible across the Internet, please do everyone a favour and get it professionally tested.
Thank you all for valuable guidance. I feel my home equipment is not "safe enough" to experiment with, putting a host in the DMZ host in my home router is not going to happen and I have not tried that, no way
Thanks guys!