Live data from Hacker News

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

utcc.utoronto.ca

51–60 of 127 posts

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

#51
post #43
post #23

Fail2ban blocked 1087 ip addresses in the last week, which seems normal. I reset it and it has blocked eleven ip addresses in the last hour, mainly China and Digital Ocean as usual. Just to see what happens, I'v tried sending abuse reports about ssh brute force, vnc brute force and phishing sites, by the standard method of doing a whois lookup on the ip for the abuse email address. Some server and web hosting compani…

Doesnt fail2ban have an option that will automatically send out abuse complaints for you?

There's something ironic about that.

A bot tries to mass ssh login on entire subnets.

A bot on one machine blocks the first bot and notified their hosting provider.

A bot on the hosting provider responds with a web form for reporting abuse.

A bot tries to fill out the web form, but is hit with a captcha.

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

#52
post #11

Earlier quoted context omitted.

That's why I recommend always pointing the default virtual host in the apache or nginx configuration to an empty static site, and making the real site visible only as a named virtual host (requiring the correct Host header), even when the server will be used only for a single site. Most of these automated exploit attempts will never send the correct Host header, and therefore will only see the default virtual host.

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

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

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

#53

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.

Perhaps VPS providers should monitor for things like huge volumes of outgoing SSH login attempts, the same way they monitor for crypto mining.

[deleted]

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

#54
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…

I have found nginx bad bot blocker [1] very handy for this. I have it setup to respond with 444 and it allows me to add my own rules very easily.

https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blo...

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

#55

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?

Well that and sane people just disable password auth. fail2ban is a 90s sysadmin solution to a nonexistent problem.

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

#56
Little offtopic:

"One of the things I've learned from this is that targeted blocking of only a few IPs is disproportionately effective at stopping brute force"

This is very much true also for other types of attacks/scan/etc.

Are you blocking Azure/OVH range on firewall ?

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

#57
post #55

Earlier quoted context omitted.

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?

Well that and sane people just disable password auth. fail2ban is a 90s sysadmin solution to a nonexistent problem.

IP reputation is a problem wider then just SSH password brute-forcing - see HTTP(S) brute-force example elsewhere in this thread.

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

#58
post #35

Earlier quoted context omitted.

Yep, I run a barely popular static site, but people do love trying all the attacks on it: https://gist.github.com/Q726kbXuN/85c947a5d37cb01f72f82318d0... This is two weeks of 404s

Instead of 404, possibly redirect them to an ad page and retire early? Half joking...

Naw, advertisers are pretty good at detecting bots. Your CPM will quickly drop to 0.

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

#59

Earlier quoted context omitted.

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

Watching the connection in verbose it appears the cipher list from both the client and server side being significantly shorter and matching on both sides speeds up the negotiation. There may also be other factors but that is what sticks out to me. I've not dug deep enough into this to see if utilizing different ciphers is also part of the speed-up.

RFC 4253 says about the key exchange:

> Each side MAY guess which algorithm the other side is using, and MAY send an initial key exchange packet according to the algorithm, if appropriate for the preferred method.

If you only support one method, that guess will always be correct, and you save a round trip.

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

#60

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?

Fewer roundtrips to exchange less data, multiplied by the latency per round trip => lower total time.
Post reply on HN