3

So guys, I messed up with the configs in a computer and let the SSH server open to the wild with ROOT login enabled. I'm trying to assess the potential damages, which I may never know for sure.

Regrets apart, this mistake lasted for over a year until I verified several SSH authentication attempts in secure.log (bots and/or skiddies) with random users, but some tried with root. The secure.log shows that all root connection attempts failed and no break-in evidence, but I may not rely on those logs anymore.

My hopes resort in the fact that I changed the default SSH port (not really a security measure) plus a 12-digit password (capital and noncapital letters plus symbols, so 72^12 possibilities), however I don't know if a 12-digit password is really worth a security matter these days. Even considering a swarm of bots (between 300k to 6M), it would take years to break the password, but DoS and DDoS are other possibilities and I wanna try to reach some peace of mind.

Unfortunately, I had to format and re-install Linux in this computer given ongoing needs, but I've kept /var/log/ files in case of an investigation. The network admin (the computer wasn't at my home) didn't notice any suspicious activity, then I came up with a few possibilities after some research:

  1. OK scenario: password was worth its length and it managed to hold any intruder.

Possible solution: I'd harden my security configs and (even) consider to keep the OS.

Comment: the intruder may have cleared the logs to trick me, so better to be sure and format anyway.

  1. Bad, but manageable scenario: someone managed to connect and setup a botnet/spammer/bitcoin miner.

Possible solution: I'd format the computer and harden my security configs.

Comment: no suspicious network activity had been noticed and I'd have noticed some CPU stress and/or other symptoms, but none seen. However, I used only SSH terminal with no graphic interface (tty) in this computer, so symptoms would be possibly less evident (?).

  1. Really a bad scenario: intruder accessed my computer, stole my data and/or ransomware.

Possible solution: I'd format the computer and harden my security configs.

Comment: OK I'd need to live with that, but the hardware would be reusable. Otherwise I'd know it for sure if my data were encrypted by the intruder in view of a ransom.

  1. Worst-case scenario: intruder break-in plus a rootkit/keylogger/sniffer/worm.

Possible solution: I'd format the computer and harden my security configs, unless a more serious intervention had been done, like BIOS or HDD/SSD firmware virus/rootkit.

Comment: I believe a hardware-level threat means game over for MB and SSD/HDD.

In summary: (1) would be fine; (2) seems very unlikely, since no alarms were triggered, (3) is bad, but hardware still OK, and (4) is the worst scenario. I believe a compromised root password is way worse than getting a rootkit from some suspicious downloaded app (just guessing), especially if it is nested into the hardware.

Therefore, scenario (4) worries me and I presume I don't have any means to find out if my computer had an intervention at hardware level. Per my research, BIOS and SSD/HDD firmware hacks are possible and usually meant for high-level targets (not my case), but rare for ordinary users and very hardware-dependent (I found lots of debate on internet).

So, did my 12-digit password play a good defense in this case?

If not, any thought/ideas/suggestions in ways I could verify my hardware are appreciated.

Johnny Dosh
  • 53
  • 3
  • 1
    Your title doesn't really seem to match the question you ask later on. – multithr3at3d Jun 21 '20 at 15:21
  • @multithr3at3d indeed, thanks. The question was in the title, but not clear stated in the text. My edit adds the question and also ransomware as possibility just for completeness (plus correction of minor misprints). – Johnny Dosh Jun 23 '20 at 02:39

2 Answers2

1

I used to exclusively use fail2ban in conjunction with blocklist.de to mitigate and report ssh brute force attacks. As I have gotten older and more experienced I have found that although this is effective it is not the best security model and it makes unnecessary server load. Now that I am older and more experienced I use ssh key pairs. This is what both Amazon and Microsoft use for their cloud services. I recommend doing this instead of relying heavily upon passwords. You can protect yourself with just an ssh key, and ssh key and a password or even an ssh key and a physical token like a yubikey. I have never set up a yubikey for ssh but I understand this has been implemented recently into ssh. If you want a good primer on generating and setting up ssh key pairs I recommend using the documentation written by github for setting up ssh key pairs. This is the most comprehensive documentation I have seen and I used it myself when I had to create a new stronger key when at a previous job because of the risks of an older encryption method.

Michael Lazin
  • 3
  • 1
  • What has been recently added to my knowledge is HMAC. However, the stored keys could be used for quite some time with `gpg-agent` used as SSH agent. `fail2ban` with IP sets should be a lot lighter on resources. I don't use it, but use a method whereby - upon successful authentication - the connecting client goes onto a whitelist set (via `pam_exec`) and clients connecting repeatedly without success going into a tarpit first (conntrack) and into an IP set a little while later. All these entries have timeouts attached, so a whitelist entry won't be valid indefinitely ... blocks will expire. – 0xC0000022L Jun 21 '20 at 17:16
  • Even if it's a good approach, but does not answers OP's question. – ThoriumBR Jun 21 '20 at 17:17
  • @ThoriumBR agreed, the question elicits speculation, opinions ... IMO it should be closed. – 0xC0000022L Jun 21 '20 at 22:11
0

A 12-char password in your case was secure enough, so in my opinion you don't need to worry. The "security blunder" of allowing remote root access was mitigated by the fact you used a password with sufficient entropy. Nevertheless, you should now consider improving the security of SSH (for example by using keys instead of passwords, or increasing the password length even more, or removing or disabling the root account, etc.).

Let's imagine an attacker used a botnet with 1 million machines. We could consider that to be a pretty large botnet, according to the sizes reported here. Let's imagine each bot was able to make 1 million attempts per second. That would actually be impossible, because SSH connections take time, SSH is usually configured to drop connections if there are too many concurrent ones, and your server probably wouldn't be able to support all this load anyway. Let's suppose the attack lasted one year, 24/7. Then, the attacker could have made 10^6 x 10^6 x 3600 x 24 x 365 attempts, that is 3.15 x 10^19 passwords. You said your 12-char password had to be guessed among 72^12 possibilities, that is 1.94x10^22 possibilities. The probability that the attacker guessed your password would then be less than 0.2%.

The truth is that no one is going to waste all the resources of their botnet for a whole year just to target your server, unless your server is an extremely important target for them (and maybe not even in that case). In remote bruteforce attacks, what usually happens is that the attackers just try a few common passwords, maybe including a few ones from databases of leaked passwords, and if they aren't successful they move on to another potential target.

reed
  • 15,538
  • 6
  • 44
  • 65
  • Remote root access is no problem ... _with key authentication_. How exactly did you assess that this was sufficiently secure? The inquirer clearly has a point in that the logs can no longer be trusted if we assume someone gained access ... so I'd be interested in the methodology. – 0xC0000022L Jun 21 '20 at 17:13
  • @0xC0000022L, it's already written in the answer, I thought it was clear. Basically the probability that an attack was successful is too low, so I assume the OP did not get hacked at all. – reed Jun 21 '20 at 21:24
  • @reed thanks for the details, I had considered a similar calculation to assess the possibility of a break-in. I also agree that wasting resources is not the goal for intruders, but let's consider that someone managed to break in. I believe the intruder would try to profit from it as fast as possible, so do you agree that scenarios (2) and (3) are the ones more likely to happen? – Johnny Dosh Jun 23 '20 at 02:36
  • @JohnnyDosh, if your analysis of the (hypothetical) attack isn't based on facts, it's just speculation. I don't have any statistics about what an attacker usually does when they find a root password. – reed Jun 23 '20 at 09:33