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

161–170 of 268 posts

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

#161

Post by KomoD »

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.

Earlier this month I was downloading top 1 million websites' robots.txt and some guy just served 100mb of whitespace :/

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

#162

Post by pnpnp »

KomoD wrote: post #161
lgats wrote: post #138

Earlier quoted context omitted.

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.

Earlier this month I was downloading top 1 million websites' robots.txt and some guy just served 100mb of whitespace :/

I love it!

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

#163

Post by hayley-patton »

KomoD wrote: post #161
lgats wrote: post #138

Earlier quoted context omitted.

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.

Earlier this month I was downloading top 1 million websites' robots.txt and some guy just served 100mb of whitespace :/

Once I was trying to scrape from some internal API, and made a request that used parameters the real client wouldn't make. I didn't expect curl to scream "FUCK YOU " at me. Presumably the name belonged to someone who scraped it before.

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

#164

Post by cyclotron3k »

fragmede wrote: post #49
ok_dad wrote: post #9

I kinda want to know the server's address so I can send a "hello_hn" message in the passwords there.

Upthread the author says one of the three servers is in Digital Ocean, which gives you an AS to target. Reverse engineer the web page so you can capture the websocket to your terminal, grep it for your IP, and search all of DO's ipv4 address space. use Shodan to limit your targets to only machines with an open port 22 to make it go faster.

Looks like it's been figured out. People are basically using it at a chat service now

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

#166

Post by elesiuta »

jrockway wrote: post #142
wkat4242 wrote: post #139

Earlier quoted context omitted.

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

If your SSH key leaks you're not going to have a warning. All you'll see is a login from yourself that you don't remember. I am pretty sure we turned off password authentication like 10 posts up this thread.

This is why I require both a private key and a password.

I have fail2ban configured to block IPs with invalid private keys after a couple attempts, and if the key is valid to email me and rate limit invalid password attempts.

This gives a more than sufficient warning if my key leaks which is already very unlikely, and this just makes it much more unlikely for both to be compromised, and only took an extra 5 minutes to configure.

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

#167

Post by slim »

chlorion wrote: post #157

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…

maybe telnet over wireguard ? :)

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

#169

Post by seized »

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.

Not for other services... I have fail2ban parsing my NVR logs. Wrong password three times and it permanently blocks the IP on my Opnsense firewall.

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

#170

Post by matheusmoreira »

wkat4242 wrote: post #141
bandrami wrote: post #101

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.

Port knocking as it's usually done is easily sniffed. Perhaps using a dynamic TOTP-like time based seed to constantly rotate the ports might help. But it sounds overly complex. It feels very like a "key under the third plant on the right" kinda thing. Not a solid security measure.

Single packet authorization. It's like the server is not even there unless you send a cryptographically signed packet

https://cipherdyne.org/fwknop/docs/SPA.html

Post reply on HN