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

261–268 of 268 posts

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

#261

Post by ttsiodras »

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…

This is why I come to HN - brilliant ideas that I should have thought of before, but didn't!

I just changed my server, and uninstalled the - now truly useless - fail2ban. I use SSH keys of course, but without fail2ban my server's logs were constantly flooded with hacking attempts.

No longer - wireguard for the win. Thank you, chlorion!

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

#262

Post by mdaniel »

Jenda_ wrote: post #260
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 g…

Outstanding job! My opinion of mysql continues to improve :-/

As a curiosity, I found the submission link in the comments on that thread https://news.ycombinator.com/item?id=19305823

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

#263

Post by flangola7 »

bootsmann wrote: post #200
flangola7 wrote: post #174

Earlier quoted context omitted.

Not if you also block VPNs

Fingerprinting VPNs is quite hard so this isn’t a reliable solution.

There's plenty of services available that provide reliable VPN and proxy detection. Every large corporation uses them.

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

#264

Post by vsviridov »

bootsmann wrote: post #199
vsviridov wrote: post #24

For this reason I've put `endlessh` on port 22 and moved actual ssh elsewhere... Also started using Crowdsec recently, but not sure about if it's worth it... fail2ban out of the box works fine for SSH, but for dovecot and postfix it's somehow broken, and the configuration scripts are just too obtuse.

Do the dovecot and postfix scenarios work well for you with crowdsec? Always like hearing user stories :)

I think the blocklists have filtered out a bunch of that noise, so from a straigh-up dovecot logs I've not seen much yet...

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

#265

Post by Breza »

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…

Reminds me of a tactic I tried with telemarketing scams when on paternity leave. I got so many calls like "Your Social Security Number is about to be revoked" that I developed an entire persona with a name, address, SSN, income, debts, and other factors. I spent several baby-naps looking up jobs, apartments, car loan interest rates, and other factors to make the persona as realistic as possible. My wife talked me out of buying a $5 Visa gift card with cash so I could give the scammers a credit card number and keep them talking longer.

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

#267

Post by 01712934368 »

wkat4242 wrote: post #208
Gordonjcp wrote: post #202

Earlier quoted context omitted.

This is fine, though. "Security through obscurity is not security" but moving your SSH port to something not 22 will utterly eliminate brute force attacks. It's too much bother to go find it, and the bozos will just move on to the next machine with port 22 open.

That's still not really security but just a nuisance mitigation IMO :)

[flagged]
Post reply on HN