Hi,
I've had a few problems with the Minster Bells and Music System while trying to upgrade the two Pis to bullseye. One was related to autostarting flask which I raised on the Raspberry Pi Forums, but this morphed into a general discussion about autostarting software in general. See https://forums.raspberrypi.com/viewtopic.php?t=314455, where the user thagrol criticises our strategy.
He has a point of course and I hope I've laid out our reasons for going the way we did. However, I think maybe we should think about this and discuss it.
Please add your thoughts into the comments below.
Network Security
Re: Network Security
Hmm, did you post the wrong link? I can't see any mention of WMT here.
Regardless I'm sure there are improvements to make, and I will happily review changes (and make them) when the VPN server is back in place and tested operational (there are of course those firewall changes to make as well, which we shouldn't discuss here until they're done).
Regardless I'm sure there are improvements to make, and I will happily review changes (and make them) when the VPN server is back in place and tested operational (there are of course those firewall changes to make as well, which we shouldn't discuss here until they're done).
Hamish
Re: Network Security
No. That's the link I meant. It points at a series of Guides written by thagrol; one contains the description on how to autostart programs at boot up (see boot.zip)
Terry
Re: Network Security
Hmm, I see.
Well, the way we have it configured won't run at every login, even over SSH, because we check the VTY/TTY number in the shell startup script don't we? I can't remember if we used .profile or .bashrc.
Might be useful to have it on a different VTY/TTY, but then whoever replaces us has one more thing to understand. It might be better to use screen to run it, and then we can run another command later to view the screen session and see all the output (in case eg there are unhandled errors).
I shy away from using sudo as I think passwordless sudo, which is required for this to work, is in general not a great idea. I don't know if we disabled passwordless sudo for the river system pis, but we probably should.
Well, the way we have it configured won't run at every login, even over SSH, because we check the VTY/TTY number in the shell startup script don't we? I can't remember if we used .profile or .bashrc.
Might be useful to have it on a different VTY/TTY, but then whoever replaces us has one more thing to understand. It might be better to use screen to run it, and then we can run another command later to view the screen session and see all the output (in case eg there are unhandled errors).
I shy away from using sudo as I think passwordless sudo, which is required for this to work, is in general not a great idea. I don't know if we disabled passwordless sudo for the river system pis, but we probably should.
Hamish
Re: Network Security
Yes. I've realised that in my original post, I referred to the discussion of the RPi Forum and then gave you the link to his document. The original link is https://forums.raspberrypi.com/viewtopi ... 3#p1956953.
You will see that I explained how we did it and he accepted that.
I personally like the way we do it. I think it was suggested very early on in the life of the WMT (then River System) network to:hamishmb wrote: ↑04/01/2022, 13:11Might be useful to have it on a different VTY/TTY, but then whoever replaces us has one more thing to understand. It might be better to use screen to run it, and then we can run another command later to view the screen session and see all the output (in case eg there are unhandled errors).
I shy away from using sudo as I think passwordless sudo, which is required for this to work, is in general not a great idea. I don't know if we disabled passwordless sudo for the river system pis, but we probably should.
- Prevent multiple launches of the code when we logged in over SSH.
- To ensure that all software ran as the default user so that log files etc aren't owned by root.
Terry
Re: Network Security
Seems reasonable to me.
Perhaps when the system is fully complete (if we ever stop making amendments to it
), we can make that change, as changing configuration and code shouldn't be needed at that point. That said, why would you need sudo to update the code on those systems? I would have thought it would be owned by www-data or similar on the Webserver at least.
The autologin point is valid. However, all the systems on that network have different passwords and are configured for security. We could of course run a vulnerability scanner on them al periodically and have them report if anything is wrong.
Some I have run on a pi include:
- rkhunter
- lynis
They both take a very long time to run on Pis, but are very comprehensive. Might be a good idea for hardening. I didn't find anything very concerning running them on a fairly stock install of Raspbian Buster light though, so might be a bit of a time-sink for very little gain.
Perhaps when the system is fully complete (if we ever stop making amendments to it
), we can make that change, as changing configuration and code shouldn't be needed at that point. That said, why would you need sudo to update the code on those systems? I would have thought it would be owned by www-data or similar on the Webserver at least.The autologin point is valid. However, all the systems on that network have different passwords and are configured for security. We could of course run a vulnerability scanner on them al periodically and have them report if anything is wrong.
Some I have run on a pi include:
- rkhunter
- lynis
They both take a very long time to run on Pis, but are very comprehensive. Might be a good idea for hardening. I didn't find anything very concerning running them on a fairly stock install of Raspbian Buster light though, so might be a bit of a time-sink for very little gain.
Hamish
Re: Network Security
Both the Webserver and the VPN Server are directly connected to the Office Network and hence to the Internet. If someone did manage to crack the Office Network, then there is a possibility that they could then get into the WMT Network via one or other of these Pis.
Both Pis have non-standard usernames (eg not 'pi') and passwords that are difficult to crack. I accept that it isn't as bad once you are logged into the other Pis on the network because their passwords aren't designed to resist centuries of brute-force hacking, so we could change them to requiring passwords for sudo. The easiest way would be to change their usernames because passwordless sudo only works for 'pi'.
Terry
Re: Network Security
Yeah, changing the usernames is not a bad idea. We can also use visudo to edit and remove the corresponding entry from /etc/sudoers.
Yes that's definitely true, but why should the code running on those servers be owned by root? Shouldn't it be owned by eg the webserver software (nginx?)?
Yes that's definitely true, but why should the code running on those servers be owned by root? Shouldn't it be owned by eg the webserver software (nginx?)?
Hamish