SSH Hardening

scottalanmiller

That's all that we do. You can only do so much to harden something that has to be exposed.

stacksofplates

Last place I was we had to set only certain ciphers and MACs, had banners, etc but that was a specific case. We also did limit the SSH access to only be from the config management server to not allow people to log into the VMs. The workstations were able to be SSH'd into.

stacksofplates

Also fail2ban isn't going to do anything with only key auth. The access gets denied before it has a chance to do anything.

I found this out the hard way when I was essentially DOS'd from remotely accessing my system when someone did actually attempt to break in. The load on the system spiked for around 2 hours.

stacksofplates

Here was a topic I had posted a while back: https://mangolassi.it/topic/10391/fairly-hardened-jump-box (I didn't realize fail2ban would be essentially useless with keys when I posted this). The password required was the system password, not the key password.

Using 2FA is a good option too. I use my Yubikey with Duo or the phone one touch response from Duo for access to my systems.

The advantage to the extra hardening is it's essentially invisible to you (other than the 2FA and password requirement obv).

JaredBusch

@stacksofplates said in SSH Hardening:

Also fail2ban isn't going to do anything with only key auth. The access gets denied before it has a chance to do anything.

Actually, it still catches it. I tested that.

At least on Fedora using systemd it does.

JaredBusch

@stacksofplates first hit on a new one I just setup. The system that prompted me to make this post in fact. I forgot to install whois, that is fixed now.

JaredBusch

@stacksofplates said in SSH Hardening:

Here was a topic I had posted a while back

Good post, but total overkill to me. What is the point of the connection from an IT point of view if not to manage the system? Yet your hardening restricts any administration except at the local console.

I log in to systems via SSH in order to reboot them, or update WTF ever application they are running. Tasks that your security will stop.

DustinB3403

@JaredBusch said in SSH Hardening:

@stacksofplates said in SSH Hardening:

Here was a topic I had posted a while back

Good post, but total overkill to me. What is the point of the connection from an IT point of view if not to manage the system? Yet your hardening restricts any administration except at the local console.

I log in to systems via SSH in order to reboot them, or update WTF ever application they are running. Tasks that your security will stop.

You mean you don't want to drive to every client site/data center/home office and update things from the comfort of their own space?

marcinozga

Install Lynis, it'll audit your SSH config and suggest areas to improve.

stacksofplates

@JaredBusch said in SSH Hardening:

@stacksofplates said in SSH Hardening:

Here was a topic I had posted a while back

Good post, but total overkill to me. What is the point of the connection from an IT point of view if not to manage the system? Yet your hardening restricts any administration except at the local console.

I log in to systems via SSH in order to reboot them, or update WTF ever application they are running. Tasks that your security will stop.

That was just a jump box. It was a way to get in to other stuff to do the admin. It is overkill for you just had ideas if you wanted them.

stacksofplates

@JaredBusch said in SSH Hardening:

@stacksofplates said in SSH Hardening:
Also fail2ban isn't going to do anything with only key auth. The access gets denied before it has a chance to do anything.
Actually, it still catches it. I tested that.

At least on Fedora using systemd it does.

Ah they must have changed it. It used to be SSH denied the request before it ever hit PAM so fail2ban did nothing.

stacksofplates

@stacksofplates said in SSH Hardening:

@JaredBusch said in SSH Hardening:
@stacksofplates said in SSH Hardening:
Also fail2ban isn't going to do anything with only key auth. The access gets denied before it has a chance to do anything.
Actually, it still catches it. I tested that.

At least on Fedora using systemd it does.
Ah they must have changed it. It used to be SSH denied the request before it ever hit PAM so fail2ban did nothing.

I also could have set it up wrong but I thought I remembered someone else saying the same thing on stack exchange or somewhere.

JaredBusch

@stacksofplates said in SSH Hardening:

@JaredBusch said in SSH Hardening:

@stacksofplates said in SSH Hardening:

Here was a topic I had posted a while back

Good post, but total overkill to me. What is the point of the connection from an IT point of view if not to manage the system? Yet your hardening restricts any administration except at the local console.

I log in to systems via SSH in order to reboot them, or update WTF ever application they are running. Tasks that your security will stop.

That was just a jump box. It was a way to get in to other stuff to do the admin. It is overkill for you just had ideas if you wanted them.

Definitely a good post with good ideas.

JaredBusch

@JaredBusch said in SSH Hardening:

[sshd]
# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode   = normal

Note, the commented out #mode = normal. If you change that to ddos, it will also cause fail2ban to log failed attempts to the disabled root account, and valid users with invalid, or no, key.

JaredBusch

So I set this up again on a new jump box today.

SSH attempts did not log until I changed the mode to ddos

Solved SSH Hardening