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

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

brute.fail

Post reply on HN
Print view View original

151–160 of 268 posts

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

#151

Post by rft »

duskwuff wrote: post #100
rhaps0dy wrote: post #92

Earlier quoted context omitted.

> ... need to login to another machine from a new machine that doesn't have the ssh-key. > gateway/proxy/vpn entry to my network has all my ssh keys on it, and it becomes compromised because of some 0-day, the attacker now basically has access to... multiple entire networks That's why you use SSH agent forwarding https://docs.github.com/en/authentication/connecting-to-gith... , so you never need to copy the private k…

On the other hand, SSH agent forwarding means exposing your SSH agent to the bastion host. If that gets compromised, an attacker may be able to move laterally to other systems your personal computer had SSH keys for.

You can also use ProxyJump to let SSH handle setting up tunnels for you. It logs into each hop via the tunnel(s), no need to forward your keys. Great thing is, once your ssh config is properly setup you don't care how convoluted the tunnel setup is; ProxyJump will connect to jump hosts via other jump hosts.

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

#152

Post by KomoD »

api wrote: post #146
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…

Try negotiating ssh compression and then sending terabytes of compressed zeroes. Might work for a badly implemented scanner.

Semi-related, I've just started serving large files to webserver scanners, some are so poorly made that they just download the entire file

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

#153

Post by lxgr »

Enginerrrd wrote: post #77
tjohns wrote: post #15

Earlier quoted context omitted.

Who still allows password-based login for any SSH account, root or not? Keys, certificates, or Kerberos for all users.

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…

> But OMG, entropy lolz

Public key authentication isn’t just providing more entropy than passwords.

Passwords (as used in SSH) are bearer tokens – send yours to the wrong server, once, and you‘re compromised, for this and future sessions. That’s not the case with public key authentication.

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

#154

Post by scrps »

sneak wrote: post #58
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…

Disable password authentication and fail2ban becomes completely unnecessary.

And/or run sshd exposed only to a wireguard or tailscale interface.

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

#155

Post by lxgr »

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…

> Your private keys shouldn't even be accessible to you, they should be on a secure enclave like a yubikey

That’s not the only reason or way to use SSH keys. Even when stored on disk (in plaintext or encrypted) they offer advantages over password authentication, e.g. making it impossible for an MITM to steal credentials or impersonate an authenticated client even without validating host keys.

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

#156

Post by sophacles »

wkat4242 wrote: post #137
thelopa wrote: post #87

Earlier quoted context omitted.

I disable password authentication and use fail2ban. It's unlikely they will be able to brute force my key, but no server is perfect. sshd might be compromised one day. I’d rather have an extra layer of defense just in case.

It's impossible they will brute force your key if you have a decent length. While I'm sure it is possible for some (mainly government) actors to brute force keys, I'm also sure these do not include the same low-hanging-fruit vandals blasting brute force attacks. And I'm also pretty sure you're not one of the select targets of these highly advanced actors. A vulnerability in sshd is indeed possible and happens once in…

Unless the maintainer of your distro's ssh package accidentally introduces an error that reduces the number of possible keys to, say - 32,767 total possible keys.[1] That's a brute-forcible number of keys that fail2ban would help mitigate.

(1: https://research.swtch.com/openssl)

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

#157

Post by chlorion »

I setup SSHD to listen on a wireguard interface rather than listening on all interfaces. This makes SSHD only accessible to wireguard peers rather than the entire internet.

A nice aspect of wireguard is that it's "steath", meaning that it does not respond to unauthenticated connections at all, so there is no way to probe and scan for wireguard listeners at all.

I think setting up daemons behind wireguard offers a lot of security. SSHD is probably fine to expose, but something like an IRC bouncer for example really benefits from being protected I think.

I use ZNC over wireguard for this reason! It also allows to use ZNC securely without the need to setup TLS certs, which IME is actually harder than setting up wireguard!

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

#158

Post by saulrh »

Kudos to 185.65.135.x, who attempted to log in with username hn_i_found_it right as I checked HN after work and opened the link, and who proceeded to attempt a number of different simple SQL, html, and js injections. I approve of this effort. I also approve of the author of this site, which appears to have survived this minor attack! :D
Post reply on HN