Hardening the installation to share it safely

[srchild]

I see encouragements and instructions to share the installation on the Internet. I want to do that and I have tested that I can get it working using no-ip.com, and I can.

But before leaving these little servers on the Internet we should harden them against intrusion and takeover, and I don't see any advice on that beyond changing the default pi password.

It may not be too big a problem if a hacker damages the Birdnetpi installation and deletes data. But if they take it over and add it to a botnet and use it for DDoS attacks or configure it as a spamming mailserver then that is a problem! We also don't want them to be able to acquire a base within our networks from which to explore and attack other machines on our network.

Google found me this which is a reasonably good starting point:

https://chrisapproved.com/blog/raspberry-pi-hardening.html

A lot of it is applicable but it is not fully appropriate for Birdnetpi. Like other similar tutorials it tells you inactivate or delete the pi user, which you can't do if Birdnetpi has been installed as the pi user. It also advises on hardening nginx, but Birdnetpi uses Caddy instead of nginx. So there is scope for an FAQ or similar on hardening a Birdnetpi installation before sharing it on the Internet.

[mcguirepr89]

Hello @srchild

A few notes on BirdNET-Pi security, especially in regards to the link for "Raspberry Pi Hardening"

1. The installation guide does allow you to configure your installation for any user. Notice step 8. I suppose I will want to specifically encourage users to create a non-pi username here instead of merely suggesting it.
   With that said, currently it is super easy to determine the user by simply looking at the file path on the "Currently Analyzing" image on the "Overview" page, among other places that would indicate the user.
2. Folks intent on sharing their servers who are also comfortable managing SSH keys can disallow SSH password access during step 7 of the installation guide as well. This would certainly harden SSH access to only those who have a copy of your private SSH key pair, without regard to whether the default user password is known/leaked.
3. Along the lines of SSH and brute force prevention, installing fail2ban will prevent brute attacks were one to also open that SSH port to the WAN.
4. Similarly, if it were desired to harden access to the "Tools" > "Web Terminal", changing the GoTTY script from bash to login would add one more layer of shell protection.
5. Alternatively, the "Web Terminal" service can be disabled altogether to truly blockade remote shell access in conjunction with the steps above.
6. BirdNET-Pi opts to use Caddy over Nginx specifically for security (also ease, overhead and speed). Several features of Caddy are more secure than Nginx and Apache by default:
   1. Caddy only responds to web requests that are formatted and addressed to what is configured in its site address line in the /etc/caddy/Caddyfile. Unlike Nginx or Apache servers which will respond to any request so long as its destination was the port on which the server is configured to listen, Caddy will not respond to malformed (the type you see in bots and network sniffing tools) requests. For instance, if you try to reach your installation's web server via its IP address without configuring caddy to specifically respond to that IP address, you'll notice you do not get served a web page. This makes caddy more secure by default, so that's good.
   2. Another of Caddy's default security features is its ability to serve anything and everything over SSL with an automatic, forced redirect from the HTTP to the HTTPS port (even if you're serving the certificate over a different port, say 8443 for example). If the site address configured in the /etc/caddy/Caddyfile specifies the https:// protocol, caddy will check its TLD to determine whether to use a third party Certificate Authority (.com, .net, .org, and other TLD supported by LetsEncrypt) from LetsEncrypt or ZeroSSL, (depending on its success with LetsEncrypt) or its own CA to self sign a certificate to add the same level of encryption (256-bit). If no protocol nor port is specified, caddy defaults to using 443 to require TLS.
   3. One feature that does not come standard with Caddy, however, is rate-limiting to prevent brute-force attacks. This can again be address with fail2ban or can be added as a plugin to caddy with a little configuration. The recommendation, though, for folks concerned with security, would be to manually edit the automatically configured /etc/caddy/Caddyfile to use a non-standard BasicAuth user (instead of the standard birdnet user) and to change that Basic Auth password often.
7. Certainly disable the FTP service and any other service that you aren't using regularly.
8. Ensure that ONLY ports 80 and 443 are open to the world, as everything else is reverse-proxied through port 443 (80 needs to be open for the forced-redirect to port 443) to add TLS.

I will try to add more thoughts as they come up.
Thanks for putting these concerns into a discussion~~

My best regards,
Patrick

[mcguirepr89]

Update:

In an effort to be proactive about these concerns, I went ahead and changed a few things:

1. Spectrograms no longer reveal the system user
2. The log no longer reveals the system user
3. The Web Terminal no longer calls bash, but instead calls login so that knowing the system user and password are required to access the shell

[srchild]

Thanks for getting on to this so promptly.

I read somewhere the suggestion that removing the pi user is better than just disabling it, as the ubiquity of the pi user means that hacker scripts may by default target the pi user for a brute force attack. Fail2ban is good but can't stop all brute force attacks - I once found someone systematically trying to break into my server despite fail2ban being installed and working. They had a huge range of contiguous ip addresses available to them (a compromised corporate network perhaps?) and simply used another ip when fail2ban blocked the one they had been using.

As it happens my installation runs as pi user... What is the best way to transfer my installation to a different user? Can I migrate the current installation to a different user, or do I need to do a fresh install and then copy over the data files and database?

Thanks

[mcguirepr89]

As it happens my installation runs as pi user... What is the best way to transfer my installation to a different user? Can I migrate the current installation to a different user, or do I need to do a fresh install and then copy over the data files and database?

If it were me, I would just backup your database ~/BirdNET-Pi/scripts/birds.db and audio files ~/BirdSongs/Extracted/By_Date onto another computer or thumb drive and flash a new SD card with my newly desired security features, (e.g., unique username, SSH-key only access, unique hostname).

Then when the new system is back up, I would put the database and By_Date directory back in place and then ensure the ownership is as needed:

sudo -E chown -R $USER:$USER ~/Bird*
sudo -E chmod g+wr $USER:$USER ~/Bird*

and then that ought to suffice.

Let me know if you have trouble with that and I'll do my best to lend some help.

My best,
Patrick

[srchild]

Will do that soon. Thanks