Brute.Fail: Watch brute force attacks fail in real time

Post by nubinetwork » Sat, Jun 03, 2023, 1:04 PM UTC

OrangeMusic wrote: post #196

mdaniel wrote: post #27

Earlier quoted context omitted.

I was actually thinking about that: OT1H, fail2ban would really clean up the list, so it's not monopolized by the one joker, but OTOH given sufficient spans of time it would make the output go quiet, which for this specific case defeats the purpose I actually much prefer the projects that give the caller a fake shell, and watch what they type after "breaking in." It'd be the Kitboga of ssh attacks :-D

> give the caller a fake shell, and watch what they type after "breaking in." Oh YES! Do it, please! We could learn a lot!

Post by jlund-molfese » Sat, Jun 03, 2023, 1:23 PM UTC

wkat4242 wrote: post #208

Gordonjcp wrote: post #202

Earlier quoted context omitted.

This is fine, though. "Security through obscurity is not security" but moving your SSH port to something not 22 will utterly eliminate brute force attacks. It's too much bother to go find it, and the bozos will just move on to the next machine with port 22 open.

That's still not really security but just a nuisance mitigation IMO :)

Post by freedomben » Sat, Jun 03, 2023, 1:57 PM UTC

ikiris wrote: post #104

Enginerrrd wrote: post #77

Earlier quoted context omitted.

I do. For some reason ssh keys became the group-think security advice to repeat ad nauseam. I often find people have only considered this very shallowly, and their reasoning is just "But OMG, entropy lolz" without actually seriously considering the available entropy and likely attack vectors and failure. Why? The benefits are largely theoretical if you choose sufficiently strong randomly generated passphrases, with s…

All of your items are just "i'm doing this wrong" combined with not understanding how keys even work. Your private keys shouldn't even be accessible to you, they should be on a secure enclave like a yubikey, and you should forward the token along the chains. No risks, and basically painless, especially if you switch to certs so you don't even have to know the public keys ahead of time on the servers, just all trust t…

Post by heyoni » Sat, Jun 03, 2023, 3:05 PM UTC

ChuckMcM wrote: post #53

So funny story, for a while I worked on a 'reverse' exploit. Which is to say morphing the response from ssh to the client with large malformed packets. The idea was to crash the client making the request. In my case I found these attacks would have like 6 to 10 attempts from the same source address. By time stamping the requests, I could evaluate if the next attack from the same address came more quickly or more slow…

Post by gitgud » Sat, Jun 03, 2023, 4:14 PM UTC

lgats wrote: post #138

ChuckMcM wrote: post #53

So funny story, for a while I worked on a 'reverse' exploit. Which is to say morphing the response from ssh to the client with large malformed packets. The idea was to crash the client making the request. In my case I found these attacks would have like 6 to 10 attempts from the same source address. By time stamping the requests, I could evaluate if the next attack from the same address came more quickly or more slow…

Another fun one is sending a redirect to a gzip bomb or extremely large file (i.e. speedtest download file) for when certain non-existant URLs are requested, i.e. /wp-login.php on a non-wordpress site.