Re: [PLUG] SSH Hardening : Request for Best Practices

[Fred Stluka <fred@bristle.com>]

Louis,

I have several suggestions, most of which are described in more
detail in the "Unix Security" section of my Unix tips page:
    - http://bristle.com/Tips/Unix.htm#unix_security

Specifically:

- Install and run logwatch (tell me who's trying to get in)
    - http://bristle.com/Tips/Unix.htm#logwatch

- Install and run fail2ban (chase off those trying to get in), as
   Victor suggested.
    - http://bristle.com/Tips/Unix.htm#fail2ban

- Install and run tripwire (tell me if someone got in)
    - http://bristle.com/Tips/Unix.htm#tripwire

- Consider using port knocking (allow access only to those who
   know the right combination of other ports to try first), as
   Victor suggested.
    - http://bristle.com/Tips/Unix.htm#port_knocking

- Maybe even set up a honeypot (fake system that attacker
   can break into, but that tracks what he does and reports back
   to you):
    - http://bristle.com/Tips/Unix.htm#honey_pot

- Disable root login, as you said, and control all privileged
   operations via sudo, not su:
    - http://bristle.com/Tips/Unix.htm#su
    - http://bristle.com/Tips/Unix.htm#sudo

- Obviously, allow access only via ssh, not telnet or ftp which
   send passwords in plain text.  Note: scp, rsync, sftp and others
   are OK because they all use ssh under the covers.  See:
    - http://bristle.com/Tips/Unix.htm#ssh

- Use a non-standard port, as you said, and make it easier for
   yourself by specifying that port number in a client-side ssh
   config file:
    - http://bristle.com/Tips/Unix.htm#ssh_aliases

- Be aware that you can use ssh to execute a single command and
   immediately logoff, and that the single command can be a sudo
   command.  This combination makes it easier to write a client-side
   script that runs some of its code on the server.  See:
    - http://bristle.com/Tips/Unix.htm#sudo_via_ssh

- Disable password use and require ssh keys, as you and others
   have said.  Here's a client-side script to install an ssh key on a
   server:
    - http://bristle.com/Tips/Unix.htm#script_authorize_ssh_key

- Write client-side scripts to do frequent operations on various
   servers, and especially to do them on multiple servers if you
   manage lots of servers:
    - http://bristle.com/Tips/Unix.htm#use_scripts_for_frequent_ssh_access
    - 
http://bristle.com/Tips/Unix.htm#use_scripts_for_frequent_ssh_access_to_bash

- Limit access to not only a whitelist of usernames, as you said,
   but also to a whitelist of incoming IP addresses, as I think
   someone else mentioned.

- You may notice from the logwatch emails that someone is
   trying hard to get around fail2ban.  Fail2ban defaults to blocking
   an IP address entirely for 10 minutes, via the iptables firewall,
   after 3 failed attempts within 10 minutes.  So some bad actors
   try twice every 10 minutes, or 3 times every 11 minutes, etc.,
   assuming you used the fail2ban defaults.  I change the defaults
   to block for a week, instead of 10 minutes -- it's a simple
   one-line change to the config file.

- If you accidentally get locked out by fail2ban yourself, here's a
   script that will allow you back in.  You'll have to run it from an
   IP address that has not yet been blocked, like from another
   server that you manage:
    - http://bristle.com/Tips/Unix/ipunblock_fail2ban

- If you notice a particularly persistent attacker, you can just block
   them manually via iptables.  Here's the shell script I use to give
   the right iptables command, with options to do things like block
   or unblock, save the list of blocked addresses to a file that
   iptables re-loads after each reboot, etc:
    - http://bristle.com/Tips/Unix/ipblock

- Once you've identified a persistent bad actor, you may as well
   block them for all servers you manage, not just the one they
   attacked.  Here's the script I use to do so:
    - http://bristle.com/Tips/Mac/Unix/ipblockall

Enjoy!
--Fred
------------------------------------------------------------------------
Fred Stluka -- mailto:fred@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.
------------------------------------------------------------------------

On 7/26/17 9:07 AM, Louis K wrote:
> I'm in the process of hardening an ssh server on my home network I 
> plan on exposing so I can access it remotely. I've configured a number 
> of typical hardening approaches (non standard port, disable root 
> login, require keys, limit to single user).
>
> I'd love to hear people's general recommendations for best practices, 
> and have two specific questions:
> *  I'm considering adding two factor auth in addition to the ssh keys. 
> Is this overkill? I think in that case the 2-factor-auth really only 
> protects me against someone getting my key (i.e., stealing my laptop 
> and sshing in), which I _think_ is unlikely.
> * I'm going to configure sshgaurd, but but haven't decided on which 
> firewall to use yet. I'm not super passionate about firewalls so 
> simplicity is key. What are your opinions on pf vs ipfw vs iptables?
>
> Thanks in advance!
>
> Lou
>
>
> ___________________________________________________________________________
> Philadelphia Linux Users Group         --        http://www.phillylinux.org
> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
> General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug