is it enough to use caddy and your own domain name for more security ?

[Drake97]

I have a doubt, I currently have jellyfin running on a pc with ubuntu desktop, I go out to the internet with caddy proxing to my jellyfin service through port 8096 and in my router I have open the tcp ports 80 and 443 for HTTP and HTTPS respectively.
When I enter the url of my domain, it redirects directly to jellyfin, all ok with that, but my question is the following:
Is that enough ? can someone who has that URL and has some computer knowledge, get into my physical server via SSH for example ? I hope you can understand me and not to be paranoid or anything haha, I'm just curious.

Thanks and greetings.

[TheDreadPirate]

Since SSH does not listen on port 80 or 443, a hypothetical attacker would not be able to gain ssh access to your PC.

If you expose port 22 for remote shell access, that is a different story. But you can take extra steps to protect yourself.

The primary way I protect ssh is by using PKI ONLY, no password logins via ssh. That significantly increases the difficulty of gaining access via brute force.

Even with password logins, as long as you use a strong password and practive good password hygiene you are fine. Specifically limiting, or straight up not, reusing of passwords and definitely avoiding using passwords that have been leaked via data breaches on other sites.

Another user asked a similar question and my message boils down to "Take security seriously, but also don't worry too much." As long as you update regularly, make efforts to do basic hardening of exposed applications, and practice good password hygiene, the likelihood of being hacked are very very very remote.

[Drake97]

Since SSH does not listen on port 80 or 443, a hypothetical attacker would not be able to gain ssh access to your PC.

If you expose port 22 for remote shell access, that is a different story.  But you can take extra steps to protect yourself.

The primary way I protect ssh is by using PKI ONLY, no password logins via ssh.  That significantly increases the difficulty of gaining access via brute force.

Even with password logins, as long as you use a strong password and practive good password hygiene you are fine.  Specifically limiting, or straight up not, reusing of passwords and definitely avoiding using passwords that have been leaked via data breaches on other sites.

Another user asked a similar question and my message boils down to "Take security seriously, but also don't worry too much."  As long as you update regularly, make efforts to do basic hardening of exposed applications, and practice good password hygiene, the likelihood of being hacked are very very very remote.

i get it, thanks for the response

[jimdogx]

If you expose port 22 for remote shell access, that is a different story. But you can take extra steps to protect yourself.

The primary way I protect ssh is by using PKI ONLY, no password logins via ssh. That significantly increases the difficulty of gaining access via brute force.

I'll add to this.  Although very simple, if and when I do want to SSH remotely, I run SSH on a non-standard port.  Back in the day, when I ran SSH on port 22, the amount of remote failed login attempts from bots in my log files was insane.  Picking a random port helped a lot.

[TheDreadPirate]

If you expose port 22 for remote shell access, that is a different story. But you can take extra steps to protect yourself.

The primary way I protect ssh is by using PKI ONLY, no password logins via ssh. That significantly increases the difficulty of gaining access via brute force.

I'll add to this.  Although very simple, if and when I do want to SSH remotely, I run SSH on a non-standard port.  Back in the day, when I ran SSH on port 22, the amount of remote failed login attempts from bots in my log files was insane.  Picking a random port helped a lot.

This.  Very much this.  I also run all of my services on non-standard ports.  Except for the Matrix federation port.  Back when I was young and dumb, I had MS RDP on its standard port exposed publicly.  Thousands and thousands and thousands of failed login attempts.  Lesson learned.

Just don't become lazy with your other security best practices because you think "security by obscurity" is enough.

[Host-in-the-Shell]

A good rule of thumb is the ArchWiki Security page, which you should check from time to time. Not saying you need to implement all it lists there, but it can give you good ideas of what to do and improve. Although some things are Arch specific, most apply universally.