Live data from Hacker News

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

brute.fail

81–90 of 268 posts

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

#82
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.

[deleted]

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

#83
post #58

Earlier quoted context omitted.

Disable password authentication and fail2ban becomes completely unnecessary.

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.

It keeps the logs cleaner. If you either don't look at the logs at all, or have fancy log analysis systems, then it does not matter. But if you are in the middle, and just manually look at the logs every once in a while, this would be a great help.

If you are logging in via ssh, the chances of being locked out arr low - using password auth is a bad idea, and once you set up ssh keys, the connection will always succeed. And in case of rare event like new system setup, you can always ssh via some other system, -J is great for that.

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

#84
post #62

Earlier quoted context omitted.

That seems like overkill. I just disable password authentication, and use SSH public keys only. It prevents brute force attacks completely.

This, and move the endpoint on an uninteresting port to lower the noise in the logs

... and avoid automated attacks in case a 0-day in the pre-authentication OpenSSH server code shows up

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

#85

Earlier quoted context omitted.

Nice idea. From the docs: Endlessh is an SSH tarpit that very slowly sends an endless, random SSH banner. It keeps SSH clients locked up for hours or even days at a time. The purpose is to put your real SSH server on another port and then let the script kiddies get stuck in this tarpit instead of bothering a real server. Since the tarpit is in the banner before any cryptographic exchange occurs, this program doesn't…

I'd be cautious about stuff like this - if you annoy the wrong person that could paint a target on your back.

Don't discourage someone else from doing it and risk their not coming back to update us on the results. This popcorn is not going to eat itself.

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

#86

I have an RDP server open to the internet(on a custom port) and it just receives an absolutely relentless stream of login attempts with all kinds of random logins. That's a private server on a private home IP, not associated with a known domain or anything. Changing the port stops it for about 24 hours then it starts again.

Why not VPN?

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

#87
post #58

Earlier quoted context omitted.

Disable password authentication and fail2ban becomes completely unnecessary.

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.

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

#88
post #80

Earlier quoted context omitted.

It can conserve server resources to just stop responding to brute force attacks

If your server is a Gameboy, maybe.

A Gameboy would probably have the computing resources to do a thousand such calculations a millisecond.

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

#89

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…

Thanks! This is incredibly helpful! I searched around a bit at like 3 AM while I was building it, but couldn't find a simple clean example like what you provided. Once traffic dies down i'll swap it out.

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

#90

I have an RDP server open to the internet(on a custom port) and it just receives an absolutely relentless stream of login attempts with all kinds of random logins. That's a private server on a private home IP, not associated with a known domain or anything. Changing the port stops it for about 24 hours then it starts again.

I know nothing about networking, so pardon the ignorance: Why isn't there (or is there) some kind of service you can use to map some crazy URL to your personalip:port, like... http://obscuremyshit.com/393nnasjhf83u98723401 = personalip:port And only when a connection is referred from that source, does the RDP server even expose itself? And for all other traffic that hits personalip:port, it does absolutely nothing?

Is there some referrer field in the RDP protocol handshake that I'm not aware of?
Post reply on HN