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

251–260 of 268 posts

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

#251

Post by sieabahlpark »

michaelcampbell wrote: post #248
bytesandbots wrote: post #240

Earlier quoted context omitted.

It can cause your site to end up on Google's safe Browsing black list which can be a death sentence for a business. Google has automated process for identifying malware and black list such websites. Almost all browsers use this list to warn users. This is why it is also dangerous to host anonymous uploaded files even for a short time. https://news.ycombinator.com/item?id=25802366

> It can cause your site to end up on Google's safe Browsing black list If it's a file that nothing on your site links to, and doesn't really "exist" how would google ever index it? Especially if you put in as a deny in robots.txt, which as far as I'm aware, Google honors.

[dead]

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

#252

Post by Gordonjcp »

wkat4242 wrote: post #226
Gordonjcp wrote: post #209

Earlier quoted context omitted.

It's both, really. If you're not getting scanned, you've reduced an attack surface, and that can only be good.

Well, I view it as hiding an attack surface. It's still there, just harder to find. But I know I'm a bit of an absolutist on security.

You put a lock on your bike.

But you also put it in the shed, and lock the shed.

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

#254

Post by justsomehnguy »

omgmajk wrote: post #39
gambiting wrote: post #38

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.

Yeah, we have the same problem. I made a custom firewall rule and a python script that watches the windows logs for multiple failed logins to combat this and it seems to work pretty well but there's always new ips.

https://github.com/al-ign/Protect-RDSFromBruteforce

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

#255

Post by ikiris »

freedomben wrote: post #235
ikiris wrote: post #104

Earlier quoted context omitted.

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…

GP is deeply concerned about getting locked out, and your solution is to use a secure enclave?

with certs its not a problem to swap keys out.

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

#257

Post by fireant »

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…

Wow that's a cool evolutionary algorithm in practice! I'm actually surprised it worked, especially with the amount of fuzzing I'd expect ssh ecosystem to receive (well perhaps the servers do, but not the clients haha).

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

#258

Post by tornato7 »

avidiax wrote: post #211
kenniskrag wrote: post #35

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 spent 10 minutes to set this up. I was shocked to see that I got my first taker less than a second after I opened port 22 on my firewall. https://www.abuseipdb.com/check/178.62.237.183 Unfortunately, it only wasted 30 seconds of that IP's time. It's not clear what type of tarpit would waste the most of the operator's time. Maybe something like a "byzantine VM", that seems exploitable, takes payloads, passes initial…

Remember the guy who asked ChatGPT to pretend to be a terminal, you could probably do something similar to mess with SSH intruders.

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

#259

Post by drpixie »

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…

INCONCEIVABLE!

You keep using that word. I do not think it means what you think it means.

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

#260

Post by Jenda_ »

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…

MySQL has a weird feature, by default enabled in many clients, that the server can request a file from the client.

I have requested /etc/shadow, cracked the hash for root password, and ssh'd back into the botnet node that was bruteforcing passwords. I then shared the information with the webhoster where the botnet was running and a local infamous antivirus company (Avast before it was leaked that they are evil) and got a t-shirt.

https://www.abclinuxu.cz/blog/jenda/2019/2/exploiting-mysql-...

Post reply on HN