The other comments have already touched upon specific security recommendations and useful learning material. But since you did request an ELI5, I figured I’d throw in some simple advice.
I don’t know much about Tailscale, but it looks to be an encrypted VPN into your server. This pipe to your server is secure from actors spying on your public WiFi connection, but would not help if – for example – your laptop is compromised and uses the VPN to further attack your server. To that end, the principle of “defense in depth” says that the server itself should have its own firewall, as a secondary or tertiary layer to keep the bad things away.
Your server firewall should default to reject*/block all inbound connections, with explicit exceptions only for services you intend to expose, such as a web server, SSH server, JellyFin, etc. Once an inbound connection is approved through the firewall, the outgoing reply to the client would also be allowed through, as would any follow-up traffic that is part of that same connection. This is connection-tracking, which all stateful firewalls can perform. Debian/Ubuntu use ufw as the default firewall, and it is IMO very easy to configure for common services or port numbers.
The next thing you can do to secure the server itself is to limit your attack space. Don’t use password authentication if you can avoid it, and use good, complex passwords where you must. Your SSH server can be configured to silently reject passwords and only accept public-key authentication, and your JellyFin authentication can be generated and stored by a good password manager.
At this point, we could go on about per-application recommendations, but just having a firewall on your server staves off a lot of script-kiddie level of attacks, from outside or even within your LAN.
The difference between reject and block in the firewall context is that reject causes a reply to be sent back to the client, positively informing them that access is denied and to not try again. The drawback is that this reveals that a firewall is in place, but is also valuable information when debugging a network connection. Whereas block silently discards network traffic, the same result as if the network lost the packet. IMO, block should only ever be used for WAN firewalls – to not reveal too much info to a potential attacker – but internally, firewalls within a LAN should use reject, as the benefits outweigh the risk of a network intruder who is already on the LAN.
As for the bonus question, with that much hardware, you could do interesting things such as experimenting with a Kubernetes cluster, or a ZFS filesystem. Or maybe you can do Chia mining with all that disk space, or Folding@Home (and CureCoin). If you’re more into just VMs and how they network together, it would be a good test bench to learn about Layer 2 forwarding and Layer 3 routing, if you wanted to understand how IPv6* traffic traverses multiple (virtual) Ethernet links.
Note: I am an IPv6 fanboy and promote it wherever I can over legacy IP (aka IPv4)
Finally, from the hardware specs you’ve given, might this be some sort of Dell or HPE server? If so, I would strongly urge you to enable the Lights-out Management (LOM) functionality (Dell calls this iDRAC; HPE calls it iLO), if you haven’t already. It may be the single most important tool for any system administrator, which is your role now, since you are in charge of this server. In short, LOM is like having a KVM, plus power control, and the ability to push physical buttons on the server and attach USB drives, all via a slick HTML5 interface.
I’ll make sure to give the firewall a shot, then - I couldn’t explain it for the life of me but for whatever reason it’s always just gone straight over my head. Not like it’s too complex or anything… just a lack of willingness to learn! But that is changing :)
And it’s a Supermicro blade - I’ve already set up IPMI LOM! One of my favorite tools. I do a decent amount of sysadmin stuff at work, and we actually use somewhat similar servers - so luckily, I know what I’m doing there. But at work, IT does all of the firewall setup and everything for us, because we’re on one huge VPN - so I don’t ever have to worry about (or learn) security. Which explains some of why I don’t know it yet.