Brute.Fail: Watch brute force attacks fail in real time • Hacker News Board

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

#221

Post by omegabravo » Sat, Jun 03, 2023, 11:00 AM UTC

runeks wrote: post #207

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…

> 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 did not know this. That’s really cool. Is it done over a stateless protocol like UDP, or is a TCP connection opened first? Ie. is it impossible to see if there’s even a server there at all, or is it first revealed that there’…

It's over UDP, you can't probe for wireguard AFAIK

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

#222

Post by BrandoElFollito » Sat, Jun 03, 2023, 11:01 AM UTC

tjoff wrote: post #219

BrandoElFollito wrote: post #218

Earlier quoted context omitted.

Assuming that your comment is serious, where is the threat in your opinion?

Bad passwords.

Then I do not understand. Keys are the answer to bad passwords (among other things)

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

#223

Post by tjoff » Sat, Jun 03, 2023, 11:17 AM UTC

BrandoElFollito wrote: post #222

tjoff wrote: post #219

Earlier quoted context omitted.

Bad passwords.

Then I do not understand. Keys are the answer to bad passwords (among other things)

It is one answer. Good passwords is another.

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

#224

Post by jamesnorden » Sat, Jun 03, 2023, 11:24 AM UTC

mike_d wrote: post #43

koolba wrote: post #32

Earlier quoted context omitted.

How short we talking? Since there's multiple opportunities to inject code, it's possible to split out the payload across multiple fields: https://www.highseverity.com/2011/06/xss-in-confined-spaces.... Ten characters per block is enough for: /* */eval(/* */'....'+/* */'....'+/* */'....'+/* ... */)/* */ Best to escape everything at render time.

Everything is escaped server side before it is sent to the client. Shoot me an email and I will let you play with it after the HN traffic dies down.

[dead]

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

#225

Post by KomoD » Sat, Jun 03, 2023, 11:28 AM UTC

mike_d wrote: post #181

KomoD wrote: post #149

"Yes things other than SSH occasionally show up" Like what?

HTTP/HTTPS basic auth, FTP/FTPS, LDAP, SSH, and a few other protocols are supported. I only show ones that actively try credentials, not just port scans.

Interesting!

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

#226

Post by wkat4242 » Sat, Jun 03, 2023, 12:19 PM UTC

Gordonjcp wrote: post #209

wkat4242 wrote: post #208

Earlier quoted context omitted.

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

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.

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

#227

Post by MrGagi » Sat, Jun 03, 2023, 12:19 PM UTC

It's crazy how much bots can keep trying to enter, and this bot from China really keeps trying, fail2ban really saves our ass

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

#228

Post by wkat4242 » Sat, Jun 03, 2023, 12:24 PM UTC

matheusmoreira wrote: post #170

wkat4242 wrote: post #141

Earlier quoted context omitted.

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

Nice solution. I hadn't heard of it. I immediately thought of replay attacks because it's a one-way protocol but it looks like they mitigated those as well.

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

#229

Post by KomoD » Sat, Jun 03, 2023, 12:29 PM UTC

hayley-patton wrote: post #163

KomoD wrote: post #161

Earlier quoted context omitted.

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.

LOL, that is great.

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

#230

Post by nubinetwork » Sat, Jun 03, 2023, 1:00 PM UTC

LaputanMachine wrote: post #201

oriettaxx wrote: post #192

Earlier quoted context omitted.

is it possible? how did you filter? (I've tried 2 years ago: at that time even aws is not able to provide a reliable EU ip list)

I use this setup [1] on my servers. IPs are mapped to countries using Maxmind's GeoLite2 database. Linux's Tcp Wrappers are configured to block access for all IPs that aren't in my country. A custom fail2ban jail adds all IPs that get blocked by the Tcp Wrappers to the system's firewall. [1]: https://www.axllent.org/docs/ssh-geoip/

People still use TCP wrappers? I thought that went out of style 20 years ago.