Quick question, I am getting very confused with all the protocols and methods of transferring data securely and easily.
I have a PI3, And a remote server running Ubuntu, Node-Red and MongoDB. From the server I want to read a one wire temperate sensor on the PI, based on some processing on the remote server, I then want to activate a relay on the PI. Simple, I thought!!
I would prefer not to run Node-Red on the PI for security purposes. What is the best protocol for communicating with the PI. If I could avoid port forwarding also it would be good, as the PI will be used in different locations. I have read about Flask, MQTT etc, but I'm just not sure which is easiest and quickest deploy.
The PI will mainly be used in hotels and and public wifi. I have had the PI hacked already on a hotel network through Node-red, that was the only reason I was avoiding it.
I would use MQTT as that's what it's designed for (communicating with devices), the Pi being the client and a MQTT server of your choosing that accessable on the Internet.
As you only have sensors/relays on the pi, I would use something like ESP32's, Pi's are a bit over kill.
Firstly, you can run NR on the Pi by binding it to 127.0.0.1 instead of binding it to all interfaces. That way, only traffic internal to the Pi will be able to communicate. You should also be configuring IPTABLES to block all external traffic as well of course since you are operating the Pi in a totally untrusted environment. This would be helpful to translate the data to MQTT. I would then configure a local broker such that it will only talk on localhost and the IP name/address of your remote server. Then you can make the local broker sync the appropriate topics to the remote server.
Definitely don't use a VPN. Assume that your Pi is compromised and treat data from it as untrusted (filter it). MQTT over a TLS secured connection would be good since the data is serialised to text. Restrict data from the Pi to a specific topic structure so that you can sanitise it and keep it separate from any other traffic. You will also want to put a user id and password on the MQTT connection but this should be changed after every trip.
Don't forget that, if you leave the Pi in your hotel room, the room itself is not trusted, it isn't just the WiFi that isn't trusted. That's to say that there are potentially lots of people with access to your room. This is a particular issue in some countries such as Russia but even in supposedly "safe" countries, you can get unexpected "guests".
Make sure that you change the default user and password to something strong.
I recommend doing a clean build of your Pi and keeping it safe at home. Then when you return, rebuild from the clean image. In case you think this to be overkill, I can say with certainty that I know about many cases of devices left in rooms that have been interfered with & most government employees who have to travel will have their devices at least wiped, even destroyed when they return from travel to certain countries.
We are also seeing a large number of hijacked sessions from devices that are on public WiFi (including hotels, etc) and from compromised mobile devices (esp. Android). This is a particular problem for web apps where the developers believe that JWT is a security mechanism - it isn't. That's because the tokens are not checked against the device and network they originated from. A very typical scenario is that tokens are hijacked and sent to a botnet which then attempts to do a token replay attack. Apps with just a simple JWT (as per most tutorials on the subject) can then be accessed with ease. This has gotten so bad that we are now restricting access to our systems to UK-only.
Of course, I also agree with Robbo that using an ESP32 based system would be better still. The ESP32 is powerful enough to do proper TLS encryption and so would be preferred here over its less powerful cousin the ESP8266.
Thank you very much for your detailed reply. MQTT seems to be the way to go. My thinking would be to also use a hosted version of MQTT, such as cloudmqtt.com, I think this would also isolate the server at the home. I travel with work alot, working on my own projects is a way of passing time. The only reason I use a pi is for portability and ease of setup each time. One device and and any charger will work it.
In terms of restricting your devices to UK, if you dont mind me asking, what method are you using to control this?
If you already have a VPS running, you could also run your own broker using Mosquitto. However, a hosted version would be fine as long as you are putting low-value data through it.
MQTT brokers have some clever ways to automatically sync data typically so it should be fairly easy to link it all together.
It varies depending on the system. We make extensive use of Office 365 and Azure and that has very good location based and other restrictions that can be applied. Some other enterprise cloud services have similar restrictions (e.g. ServiceNow). For on-premise or IaaS/PaaS systems, they generally have a firewall that can be used to help restrict access (there are db's of IP addresses by country of origin). None of these are perfect but at least they cut down the noise on our security monitoring.
In this specific case, I wouldn't actually recommend that for the same reason as I wouldn't use a VPN. As you cannot guarantee the status of the Pi, doing an SSH to your remote server is a risk. If someone/something has compromised the device, capturing the login is fairly trivial.
Sorry - i actually menat that the Pi originated the SSH tunnel with preshared keys (so no passwords available to capture) . Then on the receiving end the SSH tunnel was restricted to only talk to the host with MQTT and only MQTT was allowed across the SSH Tunnel
You might as well just use MQTT over TLS then, and unless you encrypt the pi the login details will be available on the pi, but then you’ll need physical access every time you boot the pi.
And with the certificate, you have access to the remote machine so if someone/thing grabs it, they can get into the remote device. Even with restrictions in place, that is another attack surface that is a lot more significant than a simple TLS connection.
In any case, you really need to reset the credentials when you return home - or more often if you are staying at multiple locations on a trip. This would be a case where a password is easier to manage than a certificate.
Hi, I would like to suggest a different approach here. Seems to me that focus on security kinda sidetracked the end goal.
As I understand it correctly.
You want to have a device, which actually will be deployed and raspPI to play on your travels.
As I understand it you want sent environmental info to your DB.
I would suggest to use HTTPS API.
Your nodes would become ESP32 as that's only what they would be doing. Get temp, hum, etc. and send it to off to server.
As guys pointed out, as soon as you leave it somewhere, it can be compromised. Depends how much you want to invest in research on protecting the ESP32, it might be simple as removing USB connector in your case.
On your server side, you can do a lot, but can start with simple Express server with couple of API endpoints. This would handle incoming data and protect from the rest.
Behind that you can have your Node-Red with another API endpoint for Express app to talk to.
Then you can do whatever you want in Node-Red.
You can have all that running in one VPS in containers. Have Node-Red on not public docker network. I do have that exposed on public internet on random port. So I am able to edit Node-Red flow easy. With amount of data you will be getting from your devices, it should be able to run on very low resources.
One more thing to consider, your MongoDB might not be super awesome for timeseries data. I use InfluxDB for example for capturing time series data.
I understand, where you coming from as I have started similar for my own project. ... Have a node and send to VPS. And after realising all intricacies I end up with docker images (can do auto Let's Encrypt). It took quite a long time to get all together, but you will end up with re-usable framework. So worth it
I would like to thank @TotallyInformation to sum up, what actually happen in real life.
Sorry for the late replies, I have been travelling. Some great suggestions, @tomasinouk thank you for your detailed message, I like the container idea.
It is amazing in this IOT world, how a secure protocol that can be deployed across numerous devices has not yet been developed, they all seem to have many dependencies.
Another reason I am gravitating towards the PI, is the reliability of a wired connection, as this is a prototype project, that may someday go commercial I am also looking at the novasom board. This is an industrial version of the PI and would be ideal for commercial deployment, then running an application with Node-red embedded and an MQTT broker on the server.
If anyone has any further thoughts I really appreciate them.
John
