20
submitted 2 months ago by dontblink@feddit.it to c/selfhosted@lemmy.world

Some services run really good behind a reverse proxy on 443, but some others can really become an hassle.. And sometimes just opening other ports would be easier than to try configuring everything to work through 443.

An example that comes to my mind is SSH, yeah you can use SSLH to forward requests coming from 443 to 22, but it's so much easier to just leave 22 open..

Now, for SSH, if you have certificate authentication or a strong password, I think you can feel quite safe, but what about other random ports? What risks I'm exposing my server to if I open some of them when needed for a service? Is the effort of trying to pass everything through 443/80 worth it?

top 30 comments
sorted by: hot top controversial new old
[-] ryokimball@infosec.pub 8 points 2 months ago* (last edited 2 months ago)

If you are trying to access several different services through the internet to your home network, you are better off setting up a home VPN than trying to manage multiple public facing services. The more you publish directly to the public, the more difficult it is to keep up with everything; It is likely needlessly expanding your threat exposure. Plus you never know when a new exploit gets published against any of the services you have available.

[-] Dagnet@lemmy.world 0 points 2 months ago

Self hosted newbie here. What if those services are docker containers? Wouldn't the threat be isolated from the rest of the machine?

[-] Technus@lemmy.zip 3 points 2 months ago

No. Docker containers aren't a full sandbox. There's a number of exploits that can break out of a container and gain root access to the host.

[-] kurikai@lemmy.world 3 points 2 months ago

Rootless podman helps

[-] possiblylinux127@lemmy.zip 2 points 2 months ago

Yes and no

Breaking out of docker in a real life context would require either a massive misconfiguration or a major security vulnerability. Chances are you aren't going to have much in the way of lateral movement but it is always good to have defense in depth.

[-] oddlyqueer@lemmy.ml 3 points 2 months ago

it's an extra hurdle, but it's far from a guaranteed barrier. There's a whole class of exploits called container escapes (or hypervisor escapes if you're dealing with old-school VMs) that specifically focus on escalating an attack from a compromised container into whatever machine is hosting the container.

[-] Onomatopoeia@lemmy.cafe 1 points 2 months ago

Others have clarified, but I'd like to add that security isn't one thing - it's done in layers so each layer protects from potential failures in another layer.

This is called The Swiss Cheese Model. of risk mitigation.

If you take a bunch of random slices of Swiss cheese and stack them up, how likely is there to be a single hole that goes though every layer?

Using more layers reduces the risk of "hole alignment".

Here's an example model:

So a router that has no open ports, then a mesh VPN (wireguard/Tailscale) to access different services.

That VPN should have rules that only specific ports may be connected to specific hosts.

Hosts are on an isolated network (could be VLANS), with only specific ports permitted into the VLAN via the VPN (service dependent).

Each service and host should use unique names for admin/root, with complex passwords, and preferably 2FA (or in the case of SSH, certs).

Admin/root access should be limited to local devices, and if you want to get really restrictive, specific devices.

In the Enterprise it's not unusual to have an admin password management system that you have to request an admin password for a specific system, for a specific period of time (which is delivered via a secure mechanism, sometimes in person). This is logged, and when the requested time frame expires the password is changed.

Everyone's risk model and Swiss cheese layering will fall somewhere on this scale.

[-] non_burglar@lemmy.world 0 points 2 months ago

Is your container isolated from your internal network?

If I were to compromise your container, I'd immediately pivot to other systems on your private network.

Why do the difficult thing of breaking out of a container when there's a good chance I can use the credentials I got breaking in to your container to access other systems on your network?

[-] skankhunt42@lemmy.ca 7 points 2 months ago

It's not so much about the ports, its about what you're running that's accessible to the public.

If you have a single website on 443 and SSH on 22 (or a non-standard port like 6543) you're generally considered safe. This is 2 services and someone would need to attack one of the two to get in.

If you have a VPN on 4567 and everything behind the VPN then someone would need to hack the VPN to get in.

If you have 100 different things behind 443 then someone just needs to find a hole in one to get in.

Generally ssh, nginx, a VPN are all safe and they should be on their own ports.

[-] ryannathans@aussie.zone 1 points 2 months ago

Exposing SSH is not recommended, it's a hot attack target. Expose a VPN and use that to SSH in.

[-] 0x0@lemmy.zip 0 points 2 months ago

Or use port-knocking for SSH.

[-] sfjvvssss@lemmy.world 0 points 2 months ago

While this helps getting volume down it just adds a layer of obscurity and the service behind should still be treated and maintained as if it was fully public-facing.

[-] ganymede@lemmy.ml 1 points 2 months ago* (last edited 2 months ago)

while the most bare bones knocking implementation may be classed as obscurity, there's certainly plenty of implementations which i wouldn't class as obscurity.

[-] possiblylinux127@lemmy.zip 2 points 2 months ago

With SSH it is easier to do key authentication. Certificate authentication is supported but it is a little more hassle. Don't use password authentication as it is deprecated and not secure.

The key with SSH (openssh specifically) is that it is heavily audited so it is unlikely to have any issues. The problem is when you start exposing self hosted services with lots of attack surface. You need to be very careful when exposing services as web services are very hard to secure and can be the source of a compromise that you may or may not be aware of.

It is much safer to use a overlay VPN or some other frontend for authentication like mTLS or an authenticated reverse proxy.

[-] cmnybo@discuss.tchncs.de 1 points 2 months ago

Be sure to keep everything up to date too. Even openssh has had multiple vulnerabilities just this year.

[-] possiblylinux127@lemmy.zip 1 points 2 months ago* (last edited 2 months ago)

Always good advise

However, OpenSSH is pretty solid security wise. https://www.openssh.com/security.html

Note: it is best to check the official security pages instead of random websites.

[-] bigfondue@lemmy.world 2 points 2 months ago* (last edited 2 months ago)

If you can disable IPv4 on sshd then it really isn't an issue. I know, security through obscurity isn't robust, but when I had sshd with IPv4 enabled, I was getting around 6 - 10 failed login attempts a minute. People iterate through all the IPv4 addresses since there are only 4,294,967,296 possible addresses. There are 340,282,366,920,938,463,463,374,607,431,768,211,456 possible IPv6 addresses, so the chance of someone randomly stumbling upon your address is fucking astronomically tiny. When I disabled IPv4 a couple years ago I've had exactly zero failed logins that weren't me being a sloppy typist.

[-] ganymede@lemmy.ml 1 points 2 months ago

People iterate through all the IPv4 addresses since there are only 4,294,967,296 possible addresses. There are 340,282,366,920,938,463,463,374,607,431,768,211,456 possible IPv6 addresses

i love your thinking!!

do you have a backup in case you accidentally find yourself locked out from an ipv4-only network?

[-] bigfondue@lemmy.world 2 points 2 months ago* (last edited 2 months ago)

Not really. My home network doesn't have any port forwarding so nothing is exposed. I have a VPS, but nothing really important is on there, and I pretty much exclusively use it from home. Anyway all those failed logins were just trying defaults like user admin password admin. If you have a strong password or ssh key it really doesn't matter, but I just hated knowing people were trying to get in, even if it was just half-assed attempts to find a unsecured machine.

If I really needed to use IP4 to get in, I could always just log onto Vultr's web console and enable IP4 again.

[-] Smokeydope@lemmy.world 1 points 2 months ago* (last edited 2 months ago)

Less danger than OPsec nerds hype up but enough of a concern you want at least a reverse proxy. The new FOSS replacement for cloudflare on the block is Anubis https://github.com/TecharoHQ/anubis, while Im not the biggest fan of seeing chibi anime funkopop girl thing wag its finger at me for a second or two as it test connection, I cannot deny the results seem effective enough that all the cool kids on the FOSS circle all are switching to it over cloudflare.

I just learned how to get my first website and domain and stuff setup locally this summer so theres some network admin stuff im still figuring out. I don't have any complex scripting or php or whatever so all the bots that try scanning for admin pages are never going to hit anything it just pollutes the logs. People are all nuts about scraping bots in current year but when I was a kid allowing your sites to be indexed and crawled was what let people discover it through engines, I don't care if botnets scan through my permissively licensed public writing.

[-] blargh513@sh.itjust.works 1 points 2 months ago

Get a WAF. Sophos firewall is free if you want to diy. If not, use cloudflare.

Opening ports, logging, monitoring, nailing up allow listed IP addresses and dicking around with fail2ban is such a timesuck. None of that crap will stop something from exploiting a vulnerability.

Some things are worth farming out to a 3rd party. Plus, you can just point your DNS entry over and be mostly done. No more dynamic IP bs.

[-] Itdidnttrickledown@lemmy.world 1 points 2 months ago

Move the port to a high port. Install fail2ban and set it to ban quickly. The downside of that is if you fat finger your login more than a couple of times it might ban you. I have whitelist on mine of the IP addresses I know I will be logging in from. I also run TCP wrappers which far too many people screech about it being depreciated. it works and also if set up properly logs all login attempts. I get about three or four a month on my random high port. Of course most of this depends on you trying to gain access from known addresses or subnet.

I only have the ssh login as a backup. I run wireguard with the ports set to something other than the default port. It allows me to gain access to my home network quickly. While its always possible there might be some bug that would allow someone to access it in the future it works as well as any other solution.

[-] vane@lemmy.world 1 points 2 months ago* (last edited 2 months ago)

you can reverse proxy other ports than 443 and ex. upstream ssh, the advantage of having reverse proxy over everything is to have traffic in one place so you can manage it, that's why for example kubernetes have ingress server, example nginx / openresty upstream ssh, you can restrict traffic to limited amount of IP etc.

stream {
    upstream ssh {
        server          127.0.0.1:22;
    }

    server {
        listen          2222;
        ssl_preread     on;
        proxy_pass      ssh;
    }
}
[-] non_burglar@lemmy.world 0 points 2 months ago

Presuming you have not limited edge port 22 to one or two IPS and that you are not translating a high port to 22 internal, the danger is that you are allowing the entire internet to hammer away at your ssh. If you have this described setup, you will most definitely see the evidence of attempts to break in in your SSH endpoint and firewall logs.

Zero days for SSH do exist, so it's just a matter of time before you're compromised if you leave this open.

[-] possiblylinux127@lemmy.zip 2 points 2 months ago* (last edited 2 months ago)

This is security theater

Flaws in SSH do happen but they are very rare. The solution to this is defense in depth which is different than security by obscurity.

[-] abs_mess@lemmy.blahaj.zone 0 points 2 months ago

Not a sysadmin, just a casual IT.

If it is open, it is going to get hit by scanners, scrapers, everything and the sun, even if it is secure. Generally, 443 for your websites via reverse proxy with an IP whitelist + password is okay. Not special, lets you add subdomains, very convenient.

Now, there isn't anything special about any given port, but you still need to have some form of access control that you need to set up. If it is an API have some sort of API key in place. Implement 2FA. Try to isolate the service from the machine. Isolate the machine from bare metal. Keep the bare metal machine isolated from your home network. Take up farming. Change the default port and add some form of access alerts/logs. Have some sort of fail2ban service in place because you will be firehosed with scripts and bad traffic.

Maybe some of the stuff I recommend is paranoid overkill, but I don't know enough to cut corners. Security is a hassle, a breach is a nightmare.

[-] possiblylinux127@lemmy.zip 1 points 2 months ago

IP whitelists are not terribly secure and are quite a hassle.

Instead use a overlay VPN or some sort of extra security layer like mTLS or Authelia

[-] 01189998819991197253@infosec.pub -1 points 2 months ago

Imagine opening all the windows in your flat. Then leaving them open for a month. What would happen? How many insects would make their new home in your home? How many critters and cats would do the same?

Now, each window is a port. Your flat is your network. Each critter or cat is a bad actor. Each insect is a bot or virus.

[-] possiblylinux127@lemmy.zip 1 points 2 months ago

To expand on this a bit:

A lot of attacks are automated since the goal is to compromise as many hosts as possible. These hosts are then used in a botnet or sold to people on shader websites to use as proxies.

[-] atzanteol@sh.itjust.works 1 points 2 months ago

This is an awful analogy...

this post was submitted on 03 Oct 2025
20 points (100.0% liked)

Selfhosted

53767 readers
78 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS