Live data from Hacker News

Large scale Internet SSH brute force attacks seem to have stopped here

utcc.utoronto.ca

111–120 of 127 posts

Re: Large scale Internet SSH brute force attacks seem to have stopped here

#111
post #9

On a related note, set up a website a few days ago. Brand new domain, newly opened port. But I've rented this VPS for a while so I guess its IP is already on a few lists. But anyways, it's interesting watching the logs for what I assume are tests of known exploits. GET /.gitconfig HTTP/1.0" 422 Unprocessable Entity GET /.git/config HTTP/1.0" 404 Not Found GET /owa/auth/x.js HTTP/1.0" 404 Not Found GET /ecp/Current/ex…

Just shows how regularly Microsoft exchange is attacked that this small list has three different exchange attacks.

Re: Large scale Internet SSH brute force attacks seem to have stopped here

#112

I'm still seeing the same number of attempts on my public SFTP servers. As a funny side note I found that by going through the hardening steps on ssh-audit [1], most of the bots can't even negotiate a connection. I only see them because I configured verbose logging. They seem to be using really old ssh libraries in the bot code that severely limit the ciphers available to them. Another interesting side effect is that…

I'm hoping that the folks running the bots use their bots' failure to negotiate a connection as a filter in a similar, but opposite, way that Nigerian scammers use ridiculously scammy, all caps, emails as a filter. It would significantly reduce log spam if each bot only ever connected once.

Anyone who responds to a Nigerian scam email is much more likely to be able to be successfully scammed. It is more efficient, for the scammer, that less credulous people get filtered out in the first step, so as not to waste time on them.

Similarly, any site where an ssh bot fails connection because the site operator removed e.g., weaker default ciphers is much less likely to support password auth for it to even be possible to have a password brute forced. It is more efficient for the bot operator to just move along to a more likely target.

Re: Large scale Internet SSH brute force attacks seem to have stopped here

#113

If you setup Fail2Ban and/or switch SSH from the default port 22 to something in the low 5 digits, then you should get very few attacks. Someone above talked about using layered/defense-in-depth approach to avoid zero-days and that's also a good idea, but it's more involved / sometimes impractical.

I run a port in the high 4 digits, have for a decade at least, and get...zero attacks.

Re: Large scale Internet SSH brute force attacks seem to have stopped here

#114

I'm still seeing the same number of attempts on my public SFTP servers. As a funny side note I found that by going through the hardening steps on ssh-audit [1], most of the bots can't even negotiate a connection. I only see them because I configured verbose logging. They seem to be using really old ssh libraries in the bot code that severely limit the ciphers available to them. Another interesting side effect is that…

> Another interesting side effect is that my ssh negotiation is much faster on high latency connections after the hardening. why?

Is it a slow bandwidth connection as well as low latency? It could be because curve25519/ed25519 are smaller packet sizes than other algorithms (and also just the length of the list of algorithms in the kexinit packet).

I would have expected the round trip count at the SSH level to be the same, but there could be more TCP round trips for window adjustment.

Plugging my own software, Dropbear's dbclient is a bit quicker at high latency - "ssh git@github.com" is 3 seconds (from Perth, Australia) vs 1.5 secs with dbclient. It makes use of the "guess kex" feature that most clients don't, and sends other packets sooner. Of course dbclient doesn't have all the useful features of OpenSSH, and isn't as performant at high bandwidth.

Re: Large scale Internet SSH brute force attacks seem to have stopped here

#115

Earlier quoted context omitted.

Honestly, I don't understand why people make reporting abuse so hard/labour-intensive. It is trivial to record netflow data (and most networks do that already), and then verify incoming abuse reports against those records.

is there a chance of forming some kind of a community fail2ban blocklist? I guess trusting the contributors and admins is the hard part here and that’s why spam lists are a double edged sword?

The CrowdSec folks have something similar to that:

https://crowdsec.net/ https://github.com/crowdsecurity/crowdsec

Re: Large scale Internet SSH brute force attacks seem to have stopped here

#116
post #49

This is why you should only be using SSH keys instead of a user/pw.

Yes, it may be a sign that SSH users have almost all migrated to keys.

Amazon and other cloud providers using key-based ssh as the entrance to their instances probably pushed it to mainstream.

Re: Large scale Internet SSH brute force attacks seem to have stopped here

#117

Still being attacked constantly. I gotta admit that I am a bit confused with the user names chosen: CISCO, User, adempiere, admin1, adminstrator, alarm, alem, amanda, ansible, apache2, apc, arma3server, as, assembla, azure, azureuser, bamboo, bilbomeakine, bill, blackvoid, carlos, cds, centos, chinochan, cloud, cloudera, codeship, contributor, csgo, csgoserver, csserver, debian, default, demo, deployer, dev, device,…

Z? Maybe from the russians with their Z symbol[0]? It depends on how recent that Z logging is. And kevin could be a homage to Kevin Mitnick[0]. Or maybe it's common in a certain region? Just my 2 cents.

[0] - https://en.wikipedia.org/wiki/Z_(military_symbol)

[1] - https://en.wikipedia.org/wiki/Kevin_Mitnick

Re: Large scale Internet SSH brute force attacks seem to have stopped here

#119
post #52

Earlier quoted context omitted.

Really? I see plenty of automated exploit attempts against my vhosts.

It works quite well when your hostname is private / not well known.

The bots show up within minutes of you getting a non-wildcard TLS cert because of the certificate transparency logs.
Post reply on HN