Why I have switched off my Raspberry Shake, for now at least

[Hadders]

In a word, security.

Firstly I want to say I have no concerns about any immediate security issues.

Secondly, the Raspberry Shake system continues to be my favourite project, I have used it almost everyday for the past 2.5 years.

My decision is purely precautionary while I decide what to do next.

The trigger for this was the Version 21 update in November 2025 which to my surprise happened without any intervention from me. I did not know it was possible for this to occur and so this raised security concerns in my mind. If it was possible for automatic deployment of new software what would happen if the Raspberry Shake servers were compromised and a malign actor instigated a malicious update, the answer is my internal private network would now be at risk.

Of course any device on an internal private network which is not directly controlled could do the same and ivor added some context to this, it is entirely up to me to ensure proper network security is in place.

@ivor

regarding root access to the unit: all Raspberry Shake seismometers are essentially an appliance, where we will make updates from time to time to the system as deemed necessary and interesting, where these updates constitute both bug-fixes and enhancements. indeed, this is covered in the Shake user license:

We reserve the right to make any changes to the Raspberry Shake Operating System and there is no guarantee that your follow-on systems will not break.

Having said all this the new web interface is very clean, though to be honest I rarely ever use it, preferring instead to use the ShakeNet app or sometimes Data View and Station View websites. In fact the only reason why I would use it is to see the temperature of my Raspberry Pi but now that helpful metric has unfortunately gone

Today is the first time since the V21 November 2025 update I’ve looked into this properly. I wanted to see if there is a way to turn this auto-update mechanism off, but even if I found it I’m left wondering what other components there are which I’d also need to take care of.

This also brings me into deeper concerns. I’ve never been entirely certain what the recommended procedure is for keeping the host operating system up-to-date and seem to recall from looking at the forums previously that not performing any updates is the preferred route in case anything breaks. This makes sense but given my system is running debian_version 10.3 and End of LTS was 2024-06-30 it is now well out of date. I haven’t even looked at what’s going on in the Docker containers. Raspberry Shake updates are a grey area to me.

While I’m on the subject the mobile ShakeNet app still preforms a paste from the clipboard when used see ShakeNet pasted from your clipboard, so again with security in mind I try and perform a copy of a single word before opening the app to minimise on information leak, to say the least this is tedious & I don’t always remember.

So what next? I don’t know. I could buy a more advanced router which will allow me to segment my network, etc, but the thought of having to take on more work puts me off doing that & adds complexity, it took me just over two months to find time to look at this! The quickest easiest solution is to turn it off for now and that is what I have done.

PS: If this topic is covered anywhere else please excuse me, it’s a while since I’ve gone through the forum.

[Jeffi]

I’d personally like to be able to regularly run apt updates to mitigate against vulnerabilities and install some additional utilities I have on the rest of my PIs for management and monitoring using MQTT on my Home Assistant, such as alert me when the temp or CPU util exceeds a threshold. This would need ShakeNet to be deployed on the latest Debian. There’s a few posts and a helpful guide on how to do this but I’ve not yet had the opportunity to try it, but it’s simply a case of removing the original SD and keeping as your backup should things go south, then creating a new image on a new SD and installing ShakeNet on top. Rainy day project.

I have noticed a few open ports have been deprecated across the last two updates that I was using to monitor my shakes from NEMS, arguably hardening the devices by reducing their port footprint, which is good practice. I’m not sure if their old version of Debian has a vulnerability footprint that should concern me - if this were the case then I could create a DMZ for them and potentially ring fence any potential hacking to those devices. So far firewall logs have not indicated any unwelcome connections.

I get why they take an appliance based approach to ensure as much stability as possible but I’m glad it’s not totally locked down like my black box Pi based AIS receiver that I can’t even log into.

[ivor]

hello hadders,

Glad to hear you’ve enjoyed your Shake and the various applications we’ve created to make the data both useful and interesting, it never gets old for the team to read this type of feedback. And thanks for you post, this will allow me to respond here directly to clarify a few design and security points for your benefit as well as that of any other readers coming across this thread.

You’ve touched on several issues in your post that I will endeavor to address here, each in turn.

As you note, the security related to all types of devices is ever-present and an increasing concern over all time. Indeed, notepad++ was very recently hacked; Microsoft allowed a 3rd party security firm to release an update that resulted in disruption of air travel all over the world last year; openAI was recently hacked; and the list goes on. I do not list these examples to suggest exceptional risk everywhere, but to illustrate that updates and services provided on-line each require the end-user to both trust and hand responsibility of security over to the provider. This aspect of vendor / end-user relationship is a universal feature of modern software systems, and not a Shake-specific design choice. Thus, like any internet-connected device, the Shake must be configured by both us and the end-user such that the ability of a malicious actor to compromise it is mitigated to the greatest extent possible.

I will repeat here the security measures that are baked-in, which can also be found in the on-line documentation:

• No Shake servers “reach in” to the Shake to do any work, ever. There is no requirement to “punch holes” through the firewall to make access possible in this manner
• Shake documentation strongly advises to place the Shake behind a router / firewall, in order to take advantage of all the protections this provides.
  • In fact, when the assigned IP address is recognized to be public, at boot-up, a warning message is printed to the postboot.log file, strongly suggesting this is a bad idea
• root login access from outside the Pi is not possible, access to root functionality can only occur once logged in to the Pi using the myshake user
• Changing the myshake password is also strongly encouraged during the initial configuration phase
• Thus, when all the suggestions are followed, we believe the Shake is more secure than most other devices connected to the internet from inside a router-protected LAN. This is especially true since the Shake is not a type of device that downloads both apps and data from unknown and untrusted sources, (unlike a phone / tablet / computer / etc., for example).
  • Of note: in the eight+ years the Shakes have been on-line, we are unaware of a single instance in which a unit has been compromised in the field, in any way

Regarding the automatic updates: First, the Shake is designed and supported as an appliance, not a general-purpose computer. Second, the updates are documented in a few places in the online manual, most obviously as part of the Quick-Start Guide. A change log is available for each release, making all modifications as transparent as possible. Unattended updates are the standard operating model for appliance and IoT types of devices, precisely because user interaction with the underlying OS is neither expected nor reliable. These updates allow us to enhance the system to provide richer functionality over the life-time of the instrument. Not to mention, updating all instruments equally keeps the fleet of Shakes distributed throughout the world all running the same version. Given that we are the party responsible for keeping the Shake up-and-running, applying updates automatically is crucial to the overall health of the global network.

The “what if?” question you pose is tempting to consider, and I can do nothing more than reassure you that our servers are secure. But again, this risk is in now way specific to Shake instruments: all devices which download updates are vulnerable in this manner. It is unclear why this risk would be considered higher for Shake instruments than for any other device that receives software updates, it is not.

As for OS updates, since the Pi is not locked down in any way, you are free to try to update the OS as you please. But, as stated in the manual, we provide no guarantee that it will continue to work as expected / required. This is because the Shake-OS contains a few minor tweaks to the underlying OS which are necessary for the Shake use-case scenario. And while the underlying version of the Pi-OS may be beyond its LTS date, when the above-listed security measures are implemented, there is no increase in security risk resulting from the OS being post-LTS.

And lastly, the docker containers are nothing more than the programs running the overall Shake system. That they are docker containers is 100% irrelevant to any issue of security risk. They should be seen and understood no differently than when the containerized programs were running directly on the host-side Pi itself.

I hope this clarifies the design intent and security guidelines and principles of the Shake platform.

Richard
Raspberry Shake

[Hadders]

Richard / ivor, thank you very much for taking the time to respond.

It is unclear why this risk would be considered higher for Shake instruments than for any other device that receives software updates, it is not.

A valid point & I agree. Possibly the only difference is my own failure to recognise RS updates can automatically be applied. However most other systems (e.g. OS updates, app updates) can be configured to only occur with explicit approval, although in reality I appreciate this is just the illusion of choice as I’m fairly sure any system could apply an update if it wanted to irrespective of a ‘setting’.

Now that I understand more I’ll focus my efforts on finding a solution which works for me & also allows future proofing as no doubt I add more fascinating RS type citizen science / community projects to my interests.