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

201–210 of 268 posts

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

#201

Post by LaputanMachine »

oriettaxx wrote: post #192
menotyou wrote: post #45

I put on my firewall a block for incoming traffic for all IPs outside Europe which helped a lot with the quantity of attempts.

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/

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

#202

Post by Gordonjcp »

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.

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.

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

#203

Post by blueflow »

boringuser2 wrote: post #140
blueflow wrote: post #99

Earlier quoted context omitted.

Also disk space - i don't want to keep 500 MB of failed login attempts just to have a week of syslog available.

Rotate your logs bud. Also, suppressing these logs is the same as rapidly rotating new logs.

Rotating only splits the data up into N files, not make it consume less space for a week of logs.

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

#204

Post by BrandoElFollito »

tredre3 wrote: post #108
BrandoElFollito wrote: post #72

Earlier quoted context omitted.

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.

> This. I really do not understand why people use fail2ban when the threat is somewhere else. Fail2ban keeps my log short enough that I can review them daily, I don't have to sift through thousands of login attempt. > It won't stop a ddos but will certainly, at some point, prevent you from logging in. Yup, losing my key and having no password access will do that.

I move my port to an uninteresting place and it considerably reduces the amount of logs. If this was a nuisance I would filter out the messages

> Yup, losing my key and having no password access will do that.

You can also lose your password. Or forget it if you know it by heart. But in any case you can use a password instead of a key - it just needs to be good enough (= long and not in cracking dictionaries)

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

#205

Post by BrandoElFollito »

theamk wrote: post #83
BrandoElFollito wrote: post #72

Earlier quoted context omitted.

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 succee…

> It keeps the logs cleaner.

I move my port somewhere else to reduce the clutter

> manually look at the logs every once in a while

I imagine that this is more by curiosity than anything else (which is a perfectly normal reason to do that - I do it from time to time just because). For logs analysis and alerting I have automated systems.

> using password auth is a bad idea

It is not if the password is correct, security speaking.

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

#206

Post by oriettaxx »

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/

thanks!

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

#207

Post by runeks »

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’s a server accepting a TCP connection?

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

#208

Post by wkat4242 »

Gordonjcp wrote: post #202
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.

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 :)

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

#209

Post by Gordonjcp »

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 :)

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

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

#210

Post by nvarsj »

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.

And change the sshd port. I use my birth year. 0 brute force attempts in the logs after that.
Post reply on HN