Live data from Hacker News

Securing a Linux Server

kenhv.com

11–20 of 27 posts

Re: Securing a Linux Server

#11

This is neat. Modern take and very pragmatic.

Modern take would be to simply not open anything to the outside world - except WireGuard (TailScale or such).

From there everything is either considered "localhost" or a local network.

You can setup one or two central boxes (actual home lab "server" where you already have HTTP based services, and a raspberry pi zero 2 for backup) with TailScale.

With remote devices (including phones) in same tailscale network - you can access anything in home network as if you're physically home (but also have ACLs for kids/friends/etc).

On the other (professional) end - well then NginX and SSH are not even on the same network interface. And you run NginX LB/ReverseProxy on separate boxes compared to where actual apps/websites are ...etc.

Re: Securing a Linux Server

#13
post #8

Earlier quoted context omitted.

Instead of rate limiting, more than a decade ago I started simply changing SSH port from 22 to something else. In case I needed to proxy through home, or access something like web ui for home heating system - I simply used ssh tunnel (socks localhost etc)... Of course now all that is simply done via WireGuard/Tailscale/etc.

I'd even go one step further and say portknocking would do a lot of good too, in addition to changing the default SSH port.

If anyone actually does this - please have a backup for the time when either Fail2Ban or/and PortKnocking (so both) fail or lock you out.

Re: Securing a Linux Server

#14

This is neat. Modern take and very pragmatic.

Modern take would be to simply not open anything to the outside world - except WireGuard (TailScale or such). From there everything is either considered "localhost" or a local network. You can setup one or two central boxes (actual home lab "server" where you already have HTTP based services, and a raspberry pi zero 2 for backup) with TailScale. With remote devices (including phones) in same tailscale network - you c…

Wouldn't that violate the concept of zero trust?

Re: Securing a Linux Server

#15

Is there any point in Fail2ban if you're using keys and have disabled passwords? I guess defense in depth and all that

> Is there any point in Fail2Ban if you're using keys and have disabled passwords? I’d say no. Back in the mid 2000s, I used to use Fail2Ban as an extra layer of defense but users on Stack Exchange and Hacker News (like tptacek¹) convinced me that it was pointless if I’d already disabled password authentication. To minimise noise in my logs and to have an extra layer of defense, I only allow TCP access to Port 22 (wi…

I move SSH to a different port... I know it's easy enough to discover through a port scan, but it cuts a LOT of noise down. For home, I only allow the wireguard port from the outside.

I tend to start with Ubuntu Server these days as the SSH config is pretty much where I want in the box and will import my public key during setup. I also now use Caddy for reverse-proxy duties over Nginx.

Re: Securing a Linux Server

#16

Earlier quoted context omitted.

I'd even go one step further and say portknocking would do a lot of good too, in addition to changing the default SSH port.

If anyone actually does this - please have a backup for the time when either Fail2Ban or/and PortKnocking (so both) fail or lock you out.

I've never had knockd fail me, can you fill me in on what pitfall got yours to go down? Just in case.

Re: Securing a Linux Server

#17

Is there any point in Fail2ban if you're using keys and have disabled passwords? I guess defense in depth and all that

> Is there any point in Fail2Ban if you're using keys and have disabled passwords? I’d say no. Back in the mid 2000s, I used to use Fail2Ban as an extra layer of defense but users on Stack Exchange and Hacker News (like tptacek¹) convinced me that it was pointless if I’d already disabled password authentication. To minimise noise in my logs and to have an extra layer of defense, I only allow TCP access to Port 22 (wi…

I put ssh on ipv6 only on a cloud vps I was using. Crickets. No one ever noticed it was there.

Re: Securing a Linux Server

#18

Earlier quoted context omitted.

If anyone actually does this - please have a backup for the time when either Fail2Ban or/and PortKnocking (so both) fail or lock you out.

I've never had knockd fail me, can you fill me in on what pitfall got yours to go down? Just in case.

Besides dummy stuff like wrong config of knockd itself - which hopefully gets ironed out during initial (local/on-prem setup).

Every now and then particular knock ports might be blocked (DROP) by cliënt side ISP/wifi/etc you happen to be using at the moment.

Or your fiber optic connection package gets a speed boost, along with being moved behind CGNAT.

OK in my case switching from cable to fiber already included ending up behind a CGNAT, but people already on that ISP actually got that 2in1 surprise.

Re: Securing a Linux Server

#19

Earlier quoted context omitted.

Modern take would be to simply not open anything to the outside world - except WireGuard (TailScale or such). From there everything is either considered "localhost" or a local network. You can setup one or two central boxes (actual home lab "server" where you already have HTTP based services, and a raspberry pi zero 2 for backup) with TailScale. With remote devices (including phones) in same tailscale network - you c…

Wouldn't that violate the concept of zero trust?

Which "zero trust" are you thinking off?

In case of "zero trust network" the answer is no it doesn't violate.

With WireGuard or TailScale/CloudFlare/etc you still know/verify identity of every person/device that has access to the (virtual and through it real) network.

Re: Securing a Linux Server

#20

Earlier quoted context omitted.

> Is there any point in Fail2Ban if you're using keys and have disabled passwords? I’d say no. Back in the mid 2000s, I used to use Fail2Ban as an extra layer of defense but users on Stack Exchange and Hacker News (like tptacek¹) convinced me that it was pointless if I’d already disabled password authentication. To minimise noise in my logs and to have an extra layer of defense, I only allow TCP access to Port 22 (wi…

I put ssh on ipv6 only on a cloud vps I was using. Crickets. No one ever noticed it was there.

Oh they knew. Just no one has IPv6 to connect.
Post reply on HN