Live data from Hacker News

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

brute.fail

131–140 of 268 posts

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

#131

Earlier quoted context omitted.

This. I really do not understand why people use fail2ban when the threat is somewhere else. It won't stop a ddos but will certainly, at some point, prevent you from logging in.

20 years ago port-knocking was supposed to solve this issue for good but it seems to have been never really been taken up. I'm not sure why.

This is really only effective for password based logins, but most logins these days are key based

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

#132

This site is now brought down due to the collective brute forcing of HNers visiting the site, as if akin to a DDOS. How ironic.

Is it not working for you? I see over 350 active users at the moment.

I did get one report that it was blocked by a corporate network because the domain was newly registered.

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

#133
post #120

Earlier quoted context omitted.

20 years ago port-knocking was supposed to solve this issue for good but it seems to have been never really been taken up. I'm not sure why.

Because it doesn't solve any real problems if you have ssh password login disabled and filter out login failures from logs

With port knocking or a simple as having SSH on a non-standard port, the connection request stops before even opening the TCP connection. That's less load on the system, less logs, less writing to storage, etc. Less of what you don't want must surely be preferable.

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

#134

A remark on your fail.js, since you’re engaging here and I figure this could interest you or others: Once there are more than thirty rows, you fade rows in like this: row.style.opacity = 0; let intervalId = setInterval(function() { opacity = Number(window.getComputedStyle(row).getPropertyValue("opacity")); if (opacity This would be better done with a CSS animation or transition—it takes less code, and is smoother. My…

Talking about animations, the little animation next to "Connected to WebSocket" is an SVG. I did not know until today that SVGs may be animated. Nice to know.

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

#135
It's not that funny.

While there may be millions of useless attempts, it only takes 1 to get through.

Of course SSH has a great option in key / certificate auth. So if that's enforced it's not such a big deal. Many other systems don't (at least not until we finally implement Passkeys everywhere).

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

#136
post #58

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.

Not really. A lot of these bots are super duper dumb and continue slamming your server with handshake attempts even if password auth isn't even turned on. Every handshake is wasted CPU resources (and asymmetric crypto isn't cheap). It also makes it harder to see real dangers in the logs.

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

#137
post #87

Earlier quoted context omitted.

This. I really do not understand why people use fail2ban when the threat is somewhere else. It won't stop a ddos but will certainly, at some point, prevent you from logging in.

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 a while. Fail2Ban won't stop this though because a known exploit will let them through on the first attempt.

I personally view fail2ban more as nuisance control when it comes to SSH with password auth disabled. Minimizing the log crap, the wasted CPU resources by the failed handshakes. It's not really a security protection in that scenario. In other cases (e.g. web logins where passwords must be used) it of course is.

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

#138

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.

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

#139

Earlier quoted context omitted.

> This. I really do not understand why people use fail2ban when the threat is somewhere else. Fail2ban keeps my log short enough that I can review them daily, I don't have to sift through thousands of login attempt. > It won't stop a ddos but will certainly, at some point, prevent you from logging in. Yup, losing my key and having no password access will do that.

I'm not sure manual log scanning is all that interesting. You probably want to produce a list of successful logins and review that regularly.

If an attacker manages a succesful login you've already lost. Better to catch them in the act while they're scoping you out.

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

#140
post #80

Earlier quoted context omitted.

If your server is a Gameboy, maybe.

Also disk space - i don't want to keep 500 MB of failed login attempts just to have a week of syslog available.

Rotate your logs bud.

Also, suppressing these logs is the same as rapidly rotating new logs.

Post reply on HN