I’m setting up a new server and am planning to try applications such as Jellyfin, Baikal, Nextcloud, Syncthing, Immich, Home Assistant, SearXNG, CryptPad, and possibly Element/Synapse if my little pi4 can handle it.

I’ll probably only have three users, so I’m hoping to fit a fair amount on my pi4 (8GB RAM), but will add mini PC if I need to. I do not plan on making any service publicly available without logging in as a user on my Yunohost server. I will eventually switch to a Docker setup, but for now the Yunohost debian setup is much more user-friendly for me, and everything has been pretty functional as-is.

I’m mostly concerned for a baseline level of security. One user suggested:

  • patch/upgrade your kernel and services regularly
  • run a hardened kernel with stack protection and address space randomization
  • Put a firewall between you and the internet with only minimal ports open
  • Scan your machine and ensure no extra ports are open
  • Disable/remove every device driver the kernel has that you aren’t using
  • Remove all software on the device that isn’t in active use or part of your debugging toolset, and disable all features of services you don’t need.
  • Add an extra trustworthy layer of authorization to nextcloud before you can talk to PhP
  • Disable root ssh access completely
  • Disable user ssh access except for via ssh key
  • Encrypt the most critical data client side, so access to the server doesn’t give access to the data (e.g. my passwd database is in nextcloud, but the key to unlock it isn’t)
  • Use 2-factor authentication
  • Only allow access over VPN
  • Firewall whitelist only networks you know you and your users might be accessing from. No reason why a host on a random ISP from Kazachstan should be allowed to even attempt a login.

Plan: From that, I plan to take the suggestion for

  • disabling root SSH and only use the authentication key setup
  • change the default SSH port, port forward through a VPN service
  • use encrypted backups on client side (phones and computers)
  • Yunohost to my knowledge uses nftables built-in for a firewall, so I can default block everything and whitelist the services I need

Yunohost does not yet support 2FA login, but suggests to disable the web api if it will not be used, to decrease attack surface.

Questions:

  1. Would security for ports be sufficient to use a VPN service like Wireguard or Proton VPN and enable port forwarding? Or simply disable unused ports?

  2. Should I disable ports that Yunohost defaults on? These are: TCP ports 22, 25 53, 80, 443, 587, 993, 5222, 6269 and UDP ports 53, 1900, 5353. I am new to network stuff but understand that 22 is the default SSH until I were to change it, 80 is needed for HTTP, 443 is needed for HTTPS, and Element would probably need 5222.

  3. Is blocking everything via firewall and only whitelisting services I use feasible? Is that necessary if running the whole thing with port forwarding through the VPN? I’m concerned that I won’t be able to manually figure out every service my applications need.

I understand there is a balance between security and compatibility/usability, but I would like to have a reasonable amount of confidence that my files and photos will not be easily taken. Any insight is greatly appreciated.

  • NotEasyBeingGreen@slrpnk.netEnglish
    1·
    6 hours ago

    All I do:

    • Run updates daily
    • Disable password logins
    • Run sshguard
    • Daily backups to a cloud and off-site host

    I think that’s it. I have my host exposed to the Internet. As far as I know, it’s fine.

    BTW, sshguard is for the IMAP and SMTP that run on the host, which do allow password logins. But it helps reduce load from brute force attacks on port 22 (which are pointless anyway).

    I’m much more worried about my son installing dodgy Minecraft mods, or my wife installing another app that she saw on TikTok. I really should put them each on a separate VLAN…

  • tal@lemmy.todayEnglish
    5·
    11 hours ago

    change the default SSH port

    Any port scanner — take nmap — is going to turn this up.

    SSH is also trivial to fingerprint as a protocol. Here’s me running netcat to my local SSH instance:

    $ nc localhost 22
SSH-2.0-OpenSSH_10.0p2 Debian-7+deb13u2
^C
$

    It ain’t rocket science to identify an SSH server.

    I personally think that port-knocking isn’t a great idea and just adds hassle and brittleness to something, but I’d do a port-knocking setup before I tried running sshd on a nonstandard port.

    If you honestly don’t trust SSH, then okay, fine, wrap it with a VPN or something with real security so there’s another layer (of course, that raises the issue of whether you trust the VPN software not to have remote exploits). Or have one host that you can reach and bounce from there to another host or something.

    There are ways that I’d say are useful to try and secure an SSH instance. Use keys rather than passwords. Whitelist user accounts that can be connected to remotely.

    But anyone who is likely to be a real risk to your system is going to be able to find an ssh server running on a nonstandard port.

  • Ooops@feddit.orgEnglish
    5·
    11 hours ago

    Security through obscurity never works, so changing you SSH port does barely anything

    … for security that is.

    What it does is keep a lot of automated bots from spamming your server. No, they don’t have any chances to get access when key authentification is used (and they won’t try either… most go for the incredible low hanging fruits like admin/admin user/password sets), but they can become a strain on your own ressources.

    What actually helps (and is usually configurable with any firewall) is rate limiting access. Just blocking someone’s access for 10 seconds after a failed attempt will make absolutely no difference for you but a big one for those spammers. Now add some incremental increase after multiple fails and you are perfectly set.

    PS: 53 is the standard port for DNS when your server operates as such.

    PPS: Don’t use it. People should really let that stuff die and exclusively run encrypted DNS (via TLS, HTTPS or Quic…)

  • irmadlad@lemmy.worldEnglish
    7·
    15 hours ago

    change the default SSH port

    I run most everything on a nonstandard port if I can get away with it. However, a bot scan of your server will reveal everything about the ports on your server.

    There are literally tons of ways to skin the security cat and you’ll probably hear a ton of them mentioned. Personally, I use the evil Cloudflare Tunnels/Zero Trust with Tailscale as an overlay on the server and on the standalone pFsense firewall. Cloudflare Tunnels/Zero Trust there is no need to fiddle with NAT, closing/opening ports, etc. Install it on the server, and it takes care of the rest. You will need a FQDN which you can change the nameservers to the ones Cloudflare will assign. The free tier is more than generous and covers a lot of ground as far as security.

    Disable root ssh access completely

    You can, and this ties in with nonstandard ssh port, use key pairs.

    Scan your machine and ensure no extra ports are open

    Lynis is a great way to get a handle on what needs to be done to your server as far as hardening it. Run a scan, in a few minutes it will spit out a list of things that need attention. Not all of the recommendations will be applicable to your server.

    You can always use host allow/host deny to really tighten things up. The only users that will have critical access are the ones you assign in the config.

    Fail2ban is effective, along with Crowdsec, Wazuh, etc

  • Decronym@lemmy.decronym.xyzBEnglish
    1·
    6 hours ago

    Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

    Fewer Letters More Letters
    DNS Domain Name Service/System
    HTTP Hypertext Transfer Protocol, the Web
    HTTPS HTTP over SSL
    IMAP Internet Message Access Protocol for email
    SMTP Simple Mail Transfer Protocol
    SSH Secure Shell for remote terminal access
    SSL Secure Sockets Layer, for transparent encryption
    TLS Transport Layer Security, supersedes SSL
    VPN Virtual Private Network

    [Thread #239 for this comm, first seen 16th Apr 2026, 01:00] [FAQ] [Full list] [Contact] [Source code]

  • folekaule@lemmy.worldEnglish
    3·
    15 hours ago

    I’m not a cyber security expert, but I think about it this way:

    First, consider your threat model. What could possibly go wrong? What do I do if the worst thing happens? What information do I need to protect? If everything is already public (like blog posts), maybe there isn’t much of a threat of information loss. If you keep your tax documents on there, maybe rethink that.

    Second: think defense in depth. None of these measures will make you totally safe, but every barrier is another thing that can make a hacker’s life more difficult. You move the ssh port and it’s not as easily found by someone who’s just literally scanning the entire Internet for open ssh ports. It’s trivial to find, sure, but at least you dodged one bullet.

    OK, they found your ssh port. Now they’re gonna start scanning for common username/password combinations. Fail2ban will stop this by blocking access after a few failures. If your credentials have leaked somewhere, the hackers may have a good guess at it though. But you’re OK because you’re using a key pair not your usual password (please don’t have a “usual password”).

    Bad luck: they guessed your password. Or maybe they exploited a bug in your web server software (must have been a zero-day because you kept things up to date). Their exploit needs to open a server port for them to talk to, though. You blocked it on your firewall so that didn’t work. They try a reverse shell, but you blocked outgoing connections, too. Well done.

    And on it goes.

    If they keep trying, they will eventually succeed, but they have to try a lot harder when you lock things down, and the longer they are at it, the more opportunity you have to notice.

  • illusionist@lemmy.zipEnglish
    1·
    15 hours ago

    No need to change ssh port. Why would you do that? Just use a secure password, or better use key pairs

    Most servers are just normal ubuntu, debian, fedora server and they work fine. Why do you need a hardened kernel?

    Why would you have to scan your machine for open ports if you didn’t open them?

    Moreover, the router has the firewall that is visible from WAN, not your computer. Check that firewall, open 443 and 80 there.

    Use an image based server os like fedora coreos so you don’t mess with the installed packages.