Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Observations from two weeks of SSH brute force attacks

lightbluetouchpaper.org

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Observations from two weeks of SSH brute force attacks

#41

Post by rlvesco7 »

lloeki wrote: post #35
peterwwillis wrote: post #29

A long time ago I used to have a general purpose server on a DSL line with port 22 open. I thought everything was fairly secure, patched up, etc... I never thought brute forcers would be able to guess one of my accounts (which was a friend's account actually). The kicker? The password was the username. I found out about the rootkit a few days after they got in. I tell ya, kids these days just don't know how to hide a…

For brute forcing, without resorting to port knocking, fail2ban works well and has a pluggable system to handle more than ssh.

Does fail2ban work against brute force distributed attacks?

I've noticed a few attacks that seem to be orchestrated from the same people but using different IPs.

Re: Observations from two weeks of SSH brute force attacks

#42

Post by nuclear_eclipse »

rlvesco7 wrote: post #41
lloeki wrote: post #35

Earlier quoted context omitted.

For brute forcing, without resorting to port knocking, fail2ban works well and has a pluggable system to handle more than ssh.

Does fail2ban work against brute force distributed attacks? I've noticed a few attacks that seem to be orchestrated from the same people but using different IPs.

It doesn't specifically target distributed attacks, but I'm not really sure how something like that could know whether incoming requests are part of a botnet or ligitimate logins.

Re: Observations from two weeks of SSH brute force attacks

#43

Post by Florin_Andrei »

hackermom wrote: post #32
nvarsj wrote: post #23

Earlier quoted context omitted.

Or better yet, don't run SSH at all. Leave it to the pros. I had an experience about a year ago on one of my home servers that convinced me of this. It was a Debian machine that I kept religiously up to date (daily cronjob and manual checking). It only had an external SSH port, I used log2ban, and disabled all logins except for one non-root user. I got the common ssh brute force spam. Then one day I happened to be ch…

In your specific case, this wouldn't have happened if your SSHd had listened to something else than port 22.

s/wouldn't have happened/would've been much less likely/

Re: Observations from two weeks of SSH brute force attacks

#44

Post by nuclear_eclipse »

bradleyland wrote: post #33
mike-cardwell wrote: post #22

Earlier quoted context omitted.

How do you "require" that they use a pass phrase with their key? You can tell them to do it, but it's up to them if they actually do.

I personally stand there with them (or over Skype) and ask them to show me how they manage their keys. Most devs know how to use ssh-agent. Those who don't are really excited to learn that they can increase security without an increase in effort. Password uniqueness, on the other hand, is something that requires continuous effort. There's an ongoing temptation to reuse the strong password that they've memorized for m…

> Best: SSH-key authentication with passphrase (prevents unauthorized use of private key if stolen)

It doesn't prevent unauthorized use, it just makes it more difficult to attack with brute force. Once someone gets your private key, you should always assume it has been compromised, and replace it immediately. It's only a matter of time and resources before a determined thief has cracked your passphrase.

Edit: not to say I disagree with your recommendation that it's best, just pointing out that compromised private keys should not be taken lightly.

Re: Observations from two weeks of SSH brute force attacks

#45

Post by param »

rlvesco7 wrote: post #2

I've been running a similar experiment. And noticed similar things as the author. However, I decided to run an additional experiment to contact Amazon since the IP was originating from an EC2 instance. Amazon contacted me after I filed an abuse report and said they were investigating. A week goes by and I'm still getting hammered. So I email Amazon and asked when it will be resolved. No response. So I email again, ag…

One of my linode servers was compromised and was used to originate such attacks. Linode proactively shut down the machine after a 24 hr notice period.

Unfortunately, I wasn't expecting this, so I missed their email and only realized the problem once my linode was offline.

I wouldn't be thrilled about either linode OR amazon

Re: Observations from two weeks of SSH brute force attacks

#46

Post by fjarlq »

nvarsj wrote: post #23
radimm wrote: post #5

Just move your SSH off the port 22, hide it behind another instance and/or use fail2ban. 99% of problems with SSH scans/attacks sorted

Or better yet, don't run SSH at all. Leave it to the pros. I had an experience about a year ago on one of my home servers that convinced me of this. It was a Debian machine that I kept religiously up to date (daily cronjob and manual checking). It only had an external SSH port, I used log2ban, and disabled all logins except for one non-root user. I got the common ssh brute force spam. Then one day I happened to be ch…

What exploit was it specifically?

Re: Observations from two weeks of SSH brute force attacks

#47

Post by aptwebapps »

param wrote: post #45
rlvesco7 wrote: post #2

I've been running a similar experiment. And noticed similar things as the author. However, I decided to run an additional experiment to contact Amazon since the IP was originating from an EC2 instance. Amazon contacted me after I filed an abuse report and said they were investigating. A week goes by and I'm still getting hammered. So I email Amazon and asked when it will be resolved. No response. So I email again, ag…

One of my linode servers was compromised and was used to originate such attacks. Linode proactively shut down the machine after a 24 hr notice period. Unfortunately, I wasn't expecting this, so I missed their email and only realized the problem once my linode was offline. I wouldn't be thrilled about either linode OR amazon

The Internet at large, on the other hand, would be quite happy with Linode in this particular instance.

Was there some other way they should have contacted you?

Re: Observations from two weeks of SSH brute force attacks

#48

Post by rat87 »

mike-cardwell wrote: post #10
radimm wrote: post #7

Earlier quoted context omitted.

sure, I hope nobody is using password based authentication for SSH anyway :)

And I hope nobody is using key based authentication for SSH without storing the private part of their SSH key on an external smart card only, which is unlocked by an external hardware pin pad. I was being pedantic of course. Password based SSH authentication is fine for 99% of the cases, as long as they use a "secure" password and don't leak it by writing it down or reusing it elsewhere.

Whats wrong with writing it down on a sticky note taped to the box if the box is in a locked area?

Re: Observations from two weeks of SSH brute force attacks

#49

Post by mike-cardwell »

bradleyland wrote: post #33
mike-cardwell wrote: post #22

Earlier quoted context omitted.

How do you "require" that they use a pass phrase with their key? You can tell them to do it, but it's up to them if they actually do.

I personally stand there with them (or over Skype) and ask them to show me how they manage their keys. Most devs know how to use ssh-agent. Those who don't are really excited to learn that they can increase security without an increase in effort. Password uniqueness, on the other hand, is something that requires continuous effort. There's an ongoing temptation to reuse the strong password that they've memorized for m…

"external drive" is not what a smart card is. You can not read the key from the smart card. The actual crypto operations involved in performing the authentication are handled on the card it's self.

If your key is on a smart card it can not be stolen, even if the machine you're ssh'ing from has been compromised. This has real value and is not "insane"

In your setup, if their machine is compromised, it doesn't matter if they password protect the key, the attacker can key log the key password or replace the ssh executable with one which leaks the key, then ssh into your servers at will.

Re: Observations from two weeks of SSH brute force attacks

#50

Post by gnosis »

mike-cardwell wrote: post #49
bradleyland wrote: post #33

Earlier quoted context omitted.

I personally stand there with them (or over Skype) and ask them to show me how they manage their keys. Most devs know how to use ssh-agent. Those who don't are really excited to learn that they can increase security without an increase in effort. Password uniqueness, on the other hand, is something that requires continuous effort. There's an ongoing temptation to reuse the strong password that they've memorized for m…

"external drive" is not what a smart card is. You can not read the key from the smart card. The actual crypto operations involved in performing the authentication are handled on the card it's self. If your key is on a smart card it can not be stolen, even if the machine you're ssh'ing from has been compromised. This has real value and is not "insane" In your setup, if their machine is compromised, it doesn't matter i…

"If your key is on a smart card it can not be stolen, even if the machine you're ssh'ing from has been compromised."

If the machine you're ssh'ing from has been compromised by a halfway competent attacker, there's no need for them to get the key from the smart card. They can log in to the remote machine by simply piggybacking on to your ssh session (with a compromised ssh client).

Post reply on HN