3 months and 1M SSH attempts later

https://livesshattack.net/blog/2016-03-20/3-months-and-1-million-ssh-attempts-later

84 67 10 years ago

tdicola• 10 years ago

If you haven't already, get fail2ban setup on the box to slow down all the attacks. And disable password login and switch to certs instead.

sneak3• 10 years ago

SSH key based auth does not use certificates.

In the case of key-based-auth only, fail2ban is pointless.

Xorlev• 10 years ago

I wouldn't say pointless. It wastes an attacker's time if nothing else, otherwise you're essentially allowing that attacker to continue interacting with your server, and perhaps SSH isn't their only target.

muppetman• 10 years ago

I disagree. I run it because I drop all traffic from the /24 the scan comes from. Harsh, yes, but tough luck. It cuts down on unwanted network traffic.

viraptor2• 10 years ago

Actually it can use certificates. Not X509, but still simplified ones.

vacri• 10 years ago

fail2ban also reduces spam in your auth log and prods the bot to move along to the next target.

bigiain• 10 years ago

It can quite easily protect against things other than failed ssh attempts - I used to regularly configure it to blackhole IPs failing to log in correctly to WordPress backends... Anything else the box does that uses some form of authentication that writes out failures to a log file can be hooked up to fail2ban.

WillieStevenson6• 10 years ago

tdicola: To authenticate myself, I use an ssh key. However, the goal of this project was to log all attacks over ssh. So setting up fail2ban and disabling password login would prohibit this collection of data. I have a massive password in place, so I'm not worried in the least.

rmdoss2• 10 years ago

Better yet, deploy OSSEC there. I would recommend it with the latest patches from here:

https://dcid.me/ossec/

matt_wulfeck• 10 years ago

It's just another thing you need running on the server that must stay patched forever.

In my opinion less is better. RSA/4096-bit key encryption only. I don't even care if you use the root user. The ability for someone to crack a 4096-bit key is impossible in practice, and if your SSH server has a bug then it doesn't matter what fancy things you have setup.

logotype• 10 years ago

Change the SSH port...

windowsworkstoo• 10 years ago

The point was to have a look at what kind of attacks are launched on the general internet, so the point was to be attacked.

Also, changing the port does basically nothing these days, with stuff like Shodan around constantly port-scanning.

WillieStevenson6• 10 years ago

Like I mentioned above, changing the SSH port would only lessen the attempts on my box. I am interested in collecting as much data as possible.

achillean3• 10 years ago

Please don't rely on that alone: https://blog.shodan.io/hiding-in-plain-sight/

voltagex_• 10 years ago

strangely, searching Shodan for product:ssh port:443 finds nothing - when I know there are boxes around running sslh or similar to run both SSH and HTTPS on the same port. Seems like you can hide in plain sight when the scanner has no idea you're there.

cddotdotslash2• 10 years ago

Just FYI, I wouldn't log into any systems using credentials you find through this. A lot of people are obviously using credentials stolen from previous dumps, so there might be valid ones in there. Logging into a public facing router using stolen credentials is definitely a crime.

WillieStevenson6• 10 years ago

Just like it's a crime trying to ssh into a box that is not yours right? And besides I didn't do anything to the router. I was simply pointing out that you should change your default credentials and hide your router.

... should be a crime to not change the default credentials.

simoncion5• 10 years ago

Did you attempt to notify that poor schmuck who stood up that AirRouter with the default username and password?

abrookewood3• 10 years ago

You ever hear the saying "Two wrongs don't make a right"?

cddotdotslash2• 10 years ago

I'm not saying the machines attacking you aren't violating the law. I'm saying that publishing an IP address of someone's router, along with step by step directions of how to log into it, along with screenshots of you logging into it, is a violation of the computer fraud and abuse act. The law doesn't care where you got the address. And the reality is that that router's owner probably has no idea they are part of a botnet attacking other machines. I suggest you go back to university and take a few computer ethics courses before you wind up with a criminal record from your next project.

ChuckMcM• 10 years ago

Just for fun I ran an SSH server on a RasPi to basically allow any login and to simulate a Linux shell. And then captured the various things that people tried. If you're wondering what the "standard set" of script kiddy tricks are, I highly recommend it.

ambiate4• 10 years ago

15 years ago, that standard set used to be wget something from packetstormsecurity.org. If no wget: curl it. If no curl: just lynx it. else: move on to the next vulnerable server. Script kiddies were quite lazy back then. I feel old at thirty.

x0• 10 years ago

Hasn't changed for the most part. Though it's either exploit db, some creepy looking .pw site you've never heard of, and once or twice, the zips that github provides. And sometimes they'll just scp their stuff onto the box.

tlrobinson3• 10 years ago

"World's worst hacker" is pretty amusing: https://www.youtube.com/watch?v=oJagxe-Gvpw

ambiate4• 10 years ago

Its interesting how many HN users seem to be missing the point of a honeypot. He set this up deliberately to understand the frequency/types of attacks on a random machine on the internet.

From my past experience, most of those CN computers are actually US zero day'd/patched running root kits/worms. It just happens to be that CN computers are more likely to be unpatched/running ancient software.

noobermin• 10 years ago

From my past experience

I'm curious how you know this for sure.

ambiate4• 10 years ago

I plead the fifth. CFAA/RICO/Patriot Act.

My hint would be: before decentralized worms, there were IRC hubs. The 'owners' would typically use their native language for the various commands (I know English is used in more than the US, but..). Most of the time, they wouldn't even hide their host name on the IRC server.

I guess from a 'being legal' POV: anyone could infect themselves with the same root kit that's on a honeypot and find out quite a bit about the organizers.

rando289• 10 years ago

what is a CN computer?

alanh• 10 years ago

CN = china. So, computers based in china, although I am at a loss as to what the thread parent is saying exactly about "CN computers actually being US". Same with "zero day'd/patched" — aren’t those opposite notions?

Godel_unicode6• 10 years ago

"Hahahahahaha, a successful login"

Congratulations, you just violated the computer fraud and abuse act. Also, bravo for laying out for every reader of this post where they can find the vulnerable router and the credentials they can use to join you in breaking the law.

This is the exact opposite of responsible disclosure; people like the author are why we will never get a less draconian cfaa. Thanks for that.

abrookewood3• 10 years ago

My thoughts exactly ... and he posted the IP addresses, passwords & usernames of the sites he was able to access. Stupid.

xupybd2• 10 years ago

Congratulations, you just violated the computer fraud and abuse act. How can that be illegal?

Granted publishing it should be, but simply testing if someone has left the default password?

ambiate4• 10 years ago

CFAA is very broad. "intentionally accesses a computer without authorization or exceeds authorized access, and thereby obtains— C) information from any protected computer;"

A court could see "ambiate was authorized to use the work printer for printing -- ambiate hacked the printer to find out the fax machine number and sent a fax" in an absurd world.

This random internet person was never authorized to access this public router. Even if its set to a default username/password. That's the broadness the CFAA.

Just because you set your password to 'password99', doesn't mean you get more protections than the person who leaves their Cisco router set to 'cisco'.

Godel_unicode6• 10 years ago

Oh yeah. The "default password==consent" argument has not worked well.

This is one of the big differences between many professional penetration testers, and enthusiastic amateurs/blue team types. The professional red teamer has typically received long lectures about scope and RoE, and knows exactly how far you can legally go. Check the webpage that corresponds to some suspicious sshd log entries and note that it's a router? Totally fine. Attempt to notify the owner? Equally fine (pro-tip, you might not know who they are, but their ISP sure does). Brute-force their admin credentials (I recognize the hyperbole; the judge won't)? Hand-cuffs.

https://ilt.eff.org/index.php/Computer_Fraud_and_Abuse_Act_(...

WillieStevenson6• 10 years ago

My apologies. I have blocked out the content to prevent any further harm.

sneak3• 10 years ago

The phrase "responsible disclosure" exists only to frame full and public disclosure as irresponsible, which it is not.

It is victim blaming to lay the tyranny of the state at the feet of those who are doing research and publishing unredacted results, even if this specific author is indeed a moron.

ploxiln• 10 years ago

And also, the fact that billions of people could theoretically do what this guy did, is why the cfaa etc. is stupid. If you need to keep billions from making naughty voltage patterns to their modem ... you're doomed. You're just gonna have to fix the cfaa.

im3w1l• 10 years ago

On a tangent, how will the next generation of hackers learn the ropes? Will they be hopelessly outclassed by their foreign peers?

Godel_unicode6• 10 years ago

More or less the same way we did? Reading about vulnerabilities, reviewing metasploit modules, fuzzing applications on your local box, reading hack post-mortems (all of which is SOOO much easier than it used to be).

They will also have the huge leg-up of being able to download vm images like Kali and DamnVulnerable{Linux, WebApp} to practice with/on. When I think about how much time I spent early in my career hand-rolling a vulnerable machine so I could try out some new msf module, only to crash my laptop when it executed and have to start over...

This myth that everyone learned by hacking actual websites etc, and therefore this is the only (or even the best) way to learn needs to die in fire. Lots of elite practitioners learned their craft without doing anything that would be considered remotely illegal.

est2• 10 years ago

I changed my SSH login banner text to

Permission denied, please try again.

To confuse people. No matter failed or successful login, the prompt text will always be like that.

Godel_unicode6• 10 years ago

You deny them permission, then grant them permission to try again?

est2• 10 years ago

No matter failed or successful login, the prompt text will always be

Permission denied, please try again

yeukhon• 10 years ago

Showing off stuff like this is considered stupid, childish and idiotic. Based on the cache version of his publication, I am extremely tempted to report this to the proper authority. Not only you should stop publishing this kind of information, you should stop your project.

simoncion5• 10 years ago

Showing off stuff like this is considered stupid, childish and idiotic. ... Not only you should stop publishing this kind of information, you should stop your project.

I strongly disagree with both sentences.

pdkl954• 10 years ago

He's still going at it 100,000 ssh attempts later.

I got hit with >100,000 on my main desktop a few years ago when I was procrastinating fixing my heavy-handed fail2ban config. I noticed what was happening first from the lag it was causing. It turns out >10 SSH password attempts/second can eat up a significant portion of my 3GHz "Yorkfield"[1] CPU. It wasn't hard to discover the problem: the logfile was rapidly filling with failed SSH password attempts. This is particularly useless as I have used

    PasswordAuthentication no

for many years. There is no chance that the script was going to gain access, but the system load from the rejections was terrible. So yes, I fixed fail2ban and added a few more "instant-ban" rules against anybody that tries password authentication, but the real fix that was moving sshd to a random port. Invalid SSH connection attempts dropped to approximately zero immediately. It's trivial to find with a port scan, but in practice almost nobody has even bothered.

It's probably like the old joke where two hiker see a grizzly bear and one stops to re-tie his shoes. "You can't outrun a grizzly!" "I only have to outrun you."

[1] Q9650 (E0); it still works great, even if it's starting to show its age

tlrobinson3• 10 years ago

Out of curiosity, why is your desktop exposed directly to the internet (no NAT/firewall) at all?

pdkl954• 10 years ago

NAT doesn't provide security, and a ssh server isn't useful if you filter that port at the firewall.

obisw4n• 10 years ago

I think more cloud providers should do something like what Google Compute Cloud does, they have SSHGuard on their images by default so IPs get blocked after too many failed attempts.

3 months and 1M SSH attempts later

Related Stories