7

I set up my Linux Ubuntu machine as an SSH server through no-ip.com and it works great.

Recently I discovered the command,

sudo lastb -ad -F -w

which outputs a log of the most recent failed SSH login attempts. What measures can I take -- passive (e.g. better filtering of login attempt by location?) and active (e.g. manual IP blocks), and how? I realize this may be a redundant question here but I'd be grateful for links and specific linux terminal examples. I'm basically an IS neophyte.

Some dudes from China really want to ruin my day, I think, because this is a very small piece of the output (both IP's listed say they're from China on who.is):

root     ssh:notty    Sun Jan 31 23:48:58 2016 - Sun Jan 31 23:48:58 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:57 2016 - Sun Jan 31 23:48:57 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:55 2016 - Sun Jan 31 23:48:55 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:55 2016 - Sun Jan 31 23:48:55 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:52 2016 - Sun Jan 31 23:48:52 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:52 2016 - Sun Jan 31 23:48:52 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:49 2016 - Sun Jan 31 23:48:49 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:49 2016 - Sun Jan 31 23:48:49 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:46 2016 - Sun Jan 31 23:48:46 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:46 2016 - Sun Jan 31 23:48:46 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:43 2016 - Sun Jan 31 23:48:43 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:41 2016 - Sun Jan 31 23:48:41 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:38 2016 - Sun Jan 31 23:48:38 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:37 2016 - Sun Jan 31 23:48:37 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:35 2016 - Sun Jan 31 23:48:35 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:34 2016 - Sun Jan 31 23:48:34 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:32 2016 - Sun Jan 31 23:48:32 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com
root     ssh:notty    Sun Jan 31 23:48:32 2016 - Sun Jan 31 23:48:32 2016  (00:00)     182.100.67.173
root     ssh:notty    Sun Jan 31 23:48:30 2016 - Sun Jan 31 23:48:30 2016  (00:00)     12.145.195.113.adsl-pool.jx.chinaunicom.com

I suspect brute-force attempts to get access to my machine (The attempts are occurring literally every few seconds). Please assist.

  • I found this, which immediately stopped the attempts from the specific IP: sudo iptables -A INPUT -s 182.100.67.173 -j DROP. Any more rigorous ideas would be great. – khaverim Feb 1 '16 at 5:38
  • I also found this very good systematic tutorial: thefanclub.co.za/how-to/… – khaverim Feb 23 '17 at 3:46
19

Do as many mitigations as you can.

Your goal is to force a wide variety of potential attackers to spend more effort, resources, computer time (and thus electric bill), and most especially "skilled" (rare or scarce, and thus valuable) person-hours. No one protection works against every threat. Not every threat can be protected against while still remaining on the internet.

However, a large number of threats (script kiddies and low skilled or low resourced attackers) can be defeated almost all the time by having a defense in depth - many layers of good, solid security, each of which should - theoretically - be enough to defeat many threats on its own. Thus, when your system's iptables rules let someone in by accident, the SSHD certificate authentication keeps them out. When your SSHD service has a flaw, your VPN prevents anyone from seeing it. When both your VPN and your SSHD have a flaw at the same time, your firewall rules prevent most of the world's IP addresses from even attempting it, leaving only locals and large botnets to be able to try and exploit the vulnerabilities, which you patch as soon as possible.

Thus, I say again, put in as many mitigations at as many levels as possible. You cannot know in advance which ones have undiscovered vulnerabilities, and which order those will be exploited in.

  • Make certain you only allow SSH v2

    • sshd_config

      • Protocol 2
  • Stay patched

  • Use your iptables to allow ONLY the IP addresses or ranges you actually use

  • Set up your SSH to allow access ONLY by certificate, not by username/password, per the Ubuntu help site SSH/OpenSSH/Configuring page

    • sshd_config

      • PubkeyAuthentication yes

      • PasswordAuthentication no

    • If you use an encrypted home directory

      • AuthorizedKeysFile /etc/ssh/%u/authorized_keys
    • If not, the normal setting for home directories can work

      • AuthorizedKeysFile %h/.ssh/authorized_keys

      • Make sure there's not excessive permissions to it.

        • chmod 700 ~/.ssh

        • chmod 600 ~/.ssh/authorized_keys

        • chmod go-w ~

    • And set up as strong a certificate as you can. Generating keys is covered at the Ubuntu help site SSH/OpenSSH/Keys page

      • I'd start with a 4096 bit RSA key or an ed25519 key with a long, strong passphrase. Be sure to generate it locally, type in a long, strong passphrase when prompted, use -o to ensure the new OpenSSH 6.5 key format, and make sure the server never has anything but the public key.

        • ssh-keygen -o -t ed25519 -f ~/.ssh/id_ed25519

        • ssh-keygen -o -b 4096 -t rsa -f ~/.ssh/id_rsa

        • To check length on an existing key, use ssh-keygen -e -f mykeyfile

    • If you can, restrict keys in the authorized_keys file to a specific IP address or set of hostnames

      • from="192.168.1.2" ssh-rsa ABCDE...012 test@test.test

      • from="*.test.test,!BadPC.test.test" ssh-ed25519 ABCDE...012 test@test.test

    • If you're on OpenSSH 6.8 or higher, you can restrict authorized keys to certain types as well in sshd_config

      • PubkeyAcceptedKeyTypes ssh-ed25519*,ssh-rsa*
  • Use fail2ban to make brute force attempts take more effort (i.e. make them use a botnet instead of only one machine, or make them take a lot of time)

    • Setting up certificates (keys) is superior if you're asking which one to do first
  • Reduce your login grace time

    • If you're using certificates, you have the option to crank it WAY down unless you use very, very slow connections

      • LoginGraceTime 8
    • Otherwise, well, how fast do you type?

      • LoginGraceTime 20
  • Control your cipher suite choices with information from Mozilla.org Security/Guidelines/OpenSSH

    • Since it's your server, and only you are getting in, you can select a very, very tight grouping such that only the most modern clients are allowed. Perhaps

    • HostKey /etc/ssh/ssh_host_rsa_key

      • sudo ssh-keygen -o -N '' -b 4096 -t rsa -f /etc/ssh/ssh_host_rsa_key

        • or

        • HostKey /etc/ssh/ssh_host_ed25519_key

        • sudo ssh-keygen -o -N '' -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

      • obviously match your HostKey filenames exactly!

        • or both (most preferred first)

        • remove all dsa keys entirely; they're fixed at a pathetic 1024 bits for SSH

    • Use ssh -Q directives to determine what your system supports for the cipher suite options

    • KexAlgorithms curve25519-sha256@libssh.org

    • Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com

    • MACs hmac-sha2-512-etm@openssh.com

    • Or whatever specific choices make you feel safest

    • And keep up with the literature; when there's a flaw in something you've chosen, choose something that doesn't have known flaws at that point in time.

  • Use your iptables (or firewall) with blocklists from I-blocklist

  • Use your iptables (or firewall) with geographical or ISP based IP lists; one such source of geographical lists is maxmind.com

  • Switch to a port in the dynamic (ephemeral) port range of 49152 to 65535 per RFC6335

    • And only bind to the IP addresses required
  • Block everything other port on that server via iptables; chances are you're getting hit by a LOT of attacks

    • Especially harden your MySQL database, if any - I see a LOT of MySQL (and SQL Server) attacks on my IDS, and I've never run either one or had either port open. Set them to local, non-routable IP's only, etc., long passwords, disable them, etc.

    • Especially disable any web servers, set them to local, non-routable IP's only, etc.

  • Use port knocking per the Ubuntu help site or a DigitalOcean article

  • Rate limit new connection attempts, per this answer to ServerFault question "Hundreds of failed ssh logins"

iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 5 --name SSH --rsource -j DROP

iptables -A INPUT -p tcp --dport 22 -m recent --set --name SSH --rsource -j ACCEPT

  • Consider using chroot per the Debian documentation "OpenSSH SFTP chroot() with ChrootDirectory"

  • Ensure rhosts is disabled with the sshd_config option

    • IgnoreRhosts yes

    • RhostsRSAAuthentication no

    • RhostsAuthentication no

  • Add more restrictions to the pre-authentication unprivileged process

    • UsePrivilegeSeparation sandbox
  • If you aren't using fowarding or tunnelling, disable it in sshd_config

    • X11Forwarding no

    • AllowTcpForwarding no

    • GatewayPorts no

    • PermitTunnel no

  • Prevent other insecure setup in directories or permissions

    • StrictModes yes

    • And then go through your permissions and settings until it works again :)

  • Disable host based authentication

    • HostbasedAuthentication no
  • Note that per This Serverfault answer to "OpenSSH daemon ignores ServerKeyBits directive", the old ServerKeyBits sshd_config directive is no longer applicable, since you don't allow SSH v1 in the first place.

  • Don't allow root in sshd_config

    • PermitRootLogin no
  • Don't allow different users - perhaps service users on some package you install - to have other options

    • PermitUserEnvironment no
  • Install a separate, all-up firewall like pfSense or a Ubiquiti Edgerouter Lite between that machine and the outside world.

    • And then use the built-in VPN IN ADDITION TO your hardened SSH login

    • Also with certificate based logins, not username/password based logins

    • If you use OpenVPN

      • Make sure to use a --tls-auth "ta.key" pre-shared key as well

      • And choose better ciphers than the default

    • And use the blocklists mentioned above at this level also

As DeerHunter mentioned, changing ssh and/or iptables and/or other firewall settings without any other way in can result in a lack of ability to SSH in.

| improve this answer | |
  • 3
    One note of caution: fiddling with SSH configuration parameters without any other way to access the box is tantamount to taking a loaded shotgun and aiming it at your foot. – Deer Hunter Feb 1 '16 at 9:18
  • +1 for a good answer, but "renders fail2ban ineffective" is wrong. Certainly enforcing keypairs is effective against the crude ssh worms circulating the internet, but blocking an IP address (not just port) and logging the activity when it is misbehaving slows down a targeted attack a lot. – symcbean Feb 3 '16 at 10:39
  • @symcbean - I just checked again, and any reference I had to the fail2ban vs certificates wasn't very good, so I've edited the post. Thank you! – Anti-weakpasswords Feb 6 '16 at 16:54
3

Here you go:

  • Generete SSH keys + protect them with password
  • Allow only specific user to login (AllowUsers)
  • Allow from specific IP username@192.168.1.1
  • Change default port
  • Create firewall rules
  • and last thing install fail2ban.
| improve this answer | |
0

You successfully blocked that specific ip, but let me tell you something you're gonna get thousands of such malicious computers trying to brute force your ssh in order to get into your box.

Some tips:

  • Switch to authentication via certificates than passwords
  • Change default ssh port (this is quite helpful - default is 22)

Some lower level tips:

| improve this answer | |
  • 1
    -1 for password authentication. – Deer Hunter Feb 1 '16 at 7:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.