Securing the Raspberry Shake and reducing the power consumption

Technical Support
1

Hi!

I’m trying to secure my Raspberry Shake, and I’m trying to reduce its power usage from unused services. I have a Raspberry Shake 4D, but I’m using it with a Raspberry Pi 3B+.

I figured out how to disable Bluetooth and Wifi by adding these lines to /boot/config.txt.

dtoverlay=disable-wifi
dtoverlay=disable-bt

I figured out that I can disable exim4.service (mail) and gpsd.service (GPS service) by running these commands.

sudo systemctl disable gpsd.service
sudo systemctl disable exim4.service

I see that it’s launching nmbd for NetBios, and it’s opening up the insecure FTP port. How do I disable those services on a Raspberry Pi?

I only need to SFTP files from this device, and use the web interface on port 80. What ports and services are essential for it to run and to participate in ShakeNet?

I think it’s trying to use NFS too, but I don’t want NFS to attempt to run.

3

Hello BlackDiamond, welcome to the community!

This is the page in our manual relative to reducing power consumption: How to reduce power consumption — Instructions on Setting Up Your Raspberry Shake

On the necessary ports, this is the dedicated page: Firewall issues? — Instructions on Setting Up Your Raspberry Shake

For the other options you are working with, this seems to do it of r the nmbd service: Samba: How to Disable LAN Samba Server Discovery - Raspberry Pi Stack Exchange

And this is the relative page for the NFS service: Network File System (NFS) - Raspberry Pi Documentation

We always encourage to try new things, who knows what good outcome could be created from that? And, in the case that something seems gone wrong, it is always possible to re-burn the microSD card and start again with a freshly installed OS.

4

Thanks for the pointers. The Samba instructions don’t help since the Raspberry Pi doesn’t seem to configure Samba through systemctl. It seems to be coming from /usr/local/bin. So it seems to be specific to the Raspberry shake image that I installed, which I think is a little worrisome because it’s harder to stop and harder to patch for security reasons.

I noticed that FTP is being run from within the docker container instead of outside of the container. I haven’t figured out how to disable that yet.

systemd─┬─agetty
        ├─avahi-autoipd───avahi-autoipd
        ├─avahi-daemon───avahi-daemon
        ├─cron───cron───sh───bash───ping
        ├─dbus-daemon
        ├─dhclient
        ├─dhcpcd
        ├─docker─┬─docker-containe─┬─docker-containe─┬─sh─┬─gunicorn───2*[gunicorn]
        │        │                 │                 │    ├─nginx───4*[nginx]
        │        │                 │                 │    └─vsftpd
        │        │                 │                 └─6*[{docker-containe}]
        │        │                 └─6*[{docker-containe}]
        │        ├─14*[exe───3*[{exe}]]
        │        └─8*[{docker}]
        ├─nmbd
        ├─ntpd───{ntpd}
        ├─rsyslogd───3*[{rsyslogd}]
        ├─sshd───sshd───sshd───bash───pstree
        ├─sudo───python
        ├─systemd───(sd-pam)
        ├─systemd-journal
        ├─systemd-logind
        ├─systemd-udevd
        ├─thd
        └─2*[wpa_supplicant]

I think these commands helped with the NFS handling.

myshake@raspberryshake:/opt $ sudo systemctl disable nfs-client.target
Removed /etc/systemd/system/remote-fs.target.wants/nfs-client.target.
Removed /etc/systemd/system/multi-user.target.wants/nfs-client.target.
myshake@raspberryshake:/opt $ sudo systemctl disable remote-fs.target
Removed /etc/systemd/system/multi-user.target.wants/remote-fs.target.
myshake@raspberryshake:/opt $ sudo systemctl disable remote-fs-pre.target

I also ran “sudo systemctl disable rpcbind”, but I suspect that the docker container may need that.

How do you permanently disable FTP from within the docker container?

Other than deleting /usr/local/bin/nmbd, how do I disable Samba?

These services aren’t needed, and they pose a security risk. I’d rather my device not be a part of a DDOS attack. Firewalls only work so far, and it’s better to just disable unused services.

5

After some further investigation, it seems that I need to use the following command.

sudo systemctl disable nmbd.service

Apparently the Raspberry Shake upgrade script is installing it in /lib/systemd/system, but it’s not listed by systemctl. So that made it hard to find.

That just means that I’m left with the following ports open at the moment. Obviously I’m keeping SSH and HTTP open. The ntpd and ntpdate processes seem to be conflicting with each other, and I’m not sure why.

myshake@raspberryshake:/lib/systemd/system $ netstat -ltu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN     
tcp        0      0 172.17.0.2:8000         0.0.0.0:*               LISTEN     
tcp6       0      0 [::]:5000               [::]:*                  LISTEN     
tcp6       0      0 [::]:10090              [::]:*                  LISTEN     
tcp6       0      0 [::]:10091              [::]:*                  LISTEN     
tcp6       0      0 [::]:10092              [::]:*                  LISTEN     
tcp6       0      0 [::]:10093              [::]:*                  LISTEN     
tcp6       0      0 [::]:10094              [::]:*                  LISTEN     
tcp6       0      0 [::]:10095              [::]:*                  LISTEN     
tcp6       0      0 [::]:http               [::]:*                  LISTEN     
tcp6       0      0 [::]:10096              [::]:*                  LISTEN     
tcp6       0      0 [::]:10097              [::]:*                  LISTEN     
tcp6       0      0 [::]:10098              [::]:*                  LISTEN     
tcp6       0      0 [::]:10099              [::]:*                  LISTEN     
tcp6       0      0 [::]:10100              [::]:*                  LISTEN     
tcp6       0      0 [::]:ftp                [::]:*                  LISTEN     
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN     
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*                          
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*                          
udp        0      0 169.254.43.250:ntp      0.0.0.0:*                          
udp        0      0 172.17.0.2:ntp          0.0.0.0:*                          
udp        0      0 192.168.1.89:ntp        0.0.0.0:*                          
udp        0      0 localhost:ntp           0.0.0.0:*                          
udp        0      0 0.0.0.0:ntp             0.0.0.0:*                          
udp        0      0 0.0.0.0:mdns            0.0.0.0:*                          
udp        0      0 0.0.0.0:48975           0.0.0.0:*                          
udp6       0      0 [::]:ntp                [::]:*                             
udp6       0      0 [::]:mdns               [::]:*                             
udp6       0      0 [::]:37145              [::]:*
6

hi there,

some information that may be of help for you in this regard:

  1. you are more than welcome to jump into the deep end of the system and modify it however you like, as you have.
  2. when power consumption is a consideration, turning off various services can help, but unless it’s related to actually disabling hardware, you probably won’t see much savings when disabling a software-only service which is not being used anyway.
  3. configuring the Pi to a more secure state is also something you are free to do, but the recommendation is that the Pi should be contained to a local LAN, behind a router that is, itself secure from external intrusion. that is, unless you explicitly expose the Pi itself to the WWW WAN, breaking into the Pi will not be possible.
  4. disabling FTP inside docker will be something that we can look into, but as described in #3, having this enabled is not inherently a risk you need to be concerned about.

in fact, in the more than four years that the Shakes have been shipping, we have not received a single report of a unit that has been compromised when sitting on a LAN behind a router.

cheers, hope this provides some additional clarity for your task.

richard

1 Like
7

VSFTP has had multiple CERT advisories, and I don’t see any potential future undiscovered vulnerabilities will stop. In fact, web browsers, like Chrome, will be removing FTP functionality. So FTP functionality doesn’t seem compelling to have.

When I used nmap on the device, it did show some vulnerabilities in how it was configured by default. The results were concerning but it wasn’t alarming.

From my experience with maintaining secure servers in the past, just because it’s behind a firewall, it doesn’t mean that it’s secure. I’ve seen the Blaster worm use the Windows DCOM RPC service, and it spread behind firewalls when an insecure infected device went behind the firewall. The Stuxnet worm also leveraged insecure services behind air gapped networks by using compromised computers that moved in and out of the network.

So the lack of reports of issues doesn’t really instill confidence about the device being secure and being unable to be used for malice. The Mirai worm depended on many network attached devices using lax security and default passwords. The Raspberry Shake doesn’t seem too much different from those devices used by the Mirai worm.

I’d be happy to write a script or documentation to make the Raspberry Shake more secure. Though if I disable VSFTP, I’d like it to be permanently disabled and not reenabled after an update.

Also yes I know that power consumption is generally not as affected by the software when compared to the hardware. I’d still like to keep it running on a UPS for as many minutes as possible after a power outage.

8

hello,

there’s absolutely nothing wrong with being as secure as possible, of course. please feel free to forward any suggestions in this regard (though please mail these to me directly, if you don’t mind).

regarding some of your observations, some more info:

  1. nmbd service is used to broadcast rs.local IP address to the LAN for easy discovery of the Shake from another computer, disabling this will also disable rs.local

  2. sftp and scp are available for data file transfer to / from other machines on the LAN - turn these off and data copies using these protocols will no longer be possible

  3. gpsd should be turned on only when a GPS dongle is detected, we will look into why this is being started when it shouldn’t be (though GPSD is not generally regarded as a risk in any case).

  4. VSFTP is enabled only inside the front-end docker container to support data file transfer using the front-end configuration interface (ACTIONS::DOWNLOAD::DATA). that FTP will be not supported in future releases of web browsers will break this functionality, obviously; this will need to be revisited in a future release.

while it is always true that a machine turned on is open to attack, it is not true that all machines in the world are equally vulnerable. by and large, Shake units are not installed on large networks where machines frequently come and go, these machines possibly acting as a trojan horse. the Shakes are also not used to communicate with the outside world except to contact NTP servers and to forward data to the data server. and, the Shakes are not intended to be accessed by anyone outside the local LAN or a VPN. users are advised to guarantee their LAN and router are secure. as well, when the LAN router security is breached, a bad actor would still need to break into the Shake’s Pi, not obvious or straightforward when the end-user has followed the recommended guidelines (#1: change the default password when configuring the unit the first time).

as i said: if you would like to share the totality of your findings and recommendations, we will look at these in depth and would be very happy to take the opportunity to further secure the Shakes in a future release.

thanks again for your efforts and insights.

richard

1 Like
9

Interesting. If I disable BT via Dtoverlay, my shake will not boot properly and tells me it cannot read the board serial number. Remove it, and it works fine. Wanted to document this anomaly for others since the usual reason for that error is the board being loose or disconnected.

1 Like
10

Yeah, I’m not sure what happened with dtoverlay=disable-bt. Other documentation on the internet says that it can be used. I’m unsure if the following commands will properly disable bluetooth and reduce the power.

sudo systemctl disable hciuart.service
sudo systemctl disable bluetooth.service

These commands also seem helpful to stop unused services.

sudo systemctl disable gpsd.service
sudo systemctl disable exim4.service
sudo systemctl disable nmbd.service
sudo systemctl disable avahi-daemon.service
sudo systemctl disable nfs-client.target
sudo systemctl disable remote-fs.target
sudo systemctl disable remote-fs-pre.target

I’m only using ssh, sftp and scp (more secure protocols). I’m also using the web interface even though that is insecure because it’s using HTTP instead of HTTPS, which can be an issue when entering the root password.

I set mine to use a static IP address. So I don’t need the NetBIOS functionality from nmbd. I’m not mounting any remote file systems. So I don’t need NFS or remote-fs. I don’t need it to use mail or potentially be a part of a spam relay accidentally. So I disable exim. I don’t have a GPS accessory. So I disable gpsd. I don’t use Bonjour in my network intentionally. So I disable avahi-daemon.

For some odd reason, ntpd and nptdate are both running. Also there is an ntp service running. I don’t think they like running at the same time. I see that “sudo systemctl list-units --type=service” usually lists one of those 2 failing to start. I think the first one to start wins ownership of the NTP port. It looks like a race condition. I read that ntpd is better, and perhaps it would be a good idea to stop ntpdate, but I’m unsure.

I’ll have to try to see if rpcbind and bootpc are still needed. I’ll also have to figure out a way to permanently disable vsftpd, which seems to be started from within the docker container’s start.sh in the rsh-fe-config docker image.

If guess if I want to improve the power consumption when on battery power, I should really look at the processes using power, which the command below.

myshake@raspberryshake:/opt $ ps -eo pid,ppid,%mem,%cpu,cmd --sort=-%cpu | head -15
  PID  PPID %MEM %CPU CMD
 1164  1153  1.6  5.9 python app.py -i 172.17.0.2 -p 8000
 1287  1197  2.0  5.1 /usr/bin/python3 /usr/bin/gunicorn -b 0.0.0.0:5000 app:app -w 2 --timeout 300000
 1288  1197  2.0  5.1 /usr/bin/python3 /usr/bin/gunicorn -b 0.0.0.0:5000 app:app -w 2 --timeout 300000
 9029     2  0.0  2.2 [kworker/u8:0]
24385     2  0.0  2.0 [kworker/u8:1]
 5987  5967  0.4  1.8 /opt/seiscomp/acquisition/bin/odf_SL_plugin --config-dir=/opt/settings/seiscomp odf
 7861  4595  0.2  1.7 heli_ewII /opt/settings/dataC/heli_ewII.d
  130     2  0.0  1.6 [kworker/u8:3]
31025     2  0.0  1.5 [kworker/u8:2]
 6430  4595  2.0  0.6 ows -c /opt/settings/dataC/ows.conf
  402     1  2.8  0.4 /usr/bin/docker daemon -H fd://
 1193  1191  0.1  0.2 nginx: worker process
 5967  4206  0.3  0.2 seedlink -v -f /opt/seiscomp/acquisition/config/seedlink.ini
   67     2  0.0  0.1 [mmcqd/0]

It looks like some Python scripts are using the most CPU time and thus the most power consumption. I’m hoping my battery backup will be able to handle it long enough before the power comes back after a large earthquake. One time it was out for a couple of hours after one earthquake.

11

hi,

to follow up:
the following services will be permanently disabled in the next Shake-OS release:

  1. exim4
  2. rpcbind and friends
  3. nfs-client
  4. remote-fs
  5. remote-fs-pre

other explanations:

  1. the front-end config interface is intentionally insecure, since:
    1.1. it is intended to only be used on a LAN, where access between machines is assumed to be trusted
    1.2. making this secure (URL prefaces with https://) requires a valid security certificate that would need to be specific for each Shake unit, which would also need to be properly renewed over all time. given 1.1, this is unnecessary.

  2. programs ntpdate and ntpd do two different things and both are absolutely necessary for the system to properly function:
    2.1. ntpdate is used to set the system clock at system boot, ntpd cannot do this. once the program fetches the proper time from the server, the system clock is set and the program exits.
    2.2 ntpd is the NTP daemon, started immediately after ntpdate exits and runs for all time. it is responsible for keeping the Pi clock in sync with whichever NTP servers the daemon is connected to.

  3. bootpc is needed by DHCP. when assigning a fixed IP, this service may not be needed (you will need to experiment), but in any case, does not use power or is a security risk.

  4. you mention the insecurity of the front-end and entering root password. but root user is disabled and accessing its password is not allowed nor needed. all commands can be preceded with sudo on the command line when logged in to the unit using ssh.

  5. vsftp is used by the front-end to transfer the data files using FTP. as previously described, this will necessarily be replaced (or simply removed) since FTP will become unavailable in future versions of browsers.

  6. the python process is also related to the front-end program and is active only when the front-end itself is active. typical, normal operations of the Shake do not require the front-end interface to remain active when not explicitly engaged with it.

thanks again for all the feedback, this has been very helpful. and i hope to have been helpful in return. please let us know if you have any further questions or observations.

cheers,
richard

2 Likes
12

I’m probably commenting on something that is already known and I didn’t get the memo - but, I tried the same and had the same experience as you described. I tried disabling BT more out of curiosity than anything. My SSH sessions probably use more energy than idle BT :wink:

1 Like