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

111–120 of 268 posts

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

#111

Post by costco »

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.

Welcome to the world of "cracked RDP"! Various internet lowlives get a big list of bruteforced RDP IPs/credentials then sell them in bulk: https://www.bleepingcomputer.com/news/security/over-85-000-h.... Sometimes the hacked machines are used to start attacks from.

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

#113

Post by theamk »

admax88qqq wrote: post #93
theamk wrote: post #83

Earlier quoted context omitted.

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…

> the connection will always succeed. Not from my experience. If you have too many keys and certain ssh agents like gnome keyring don't pick up the key intelligently and will try a all the keys in some order often resulting in the server giving rejecting you due to too many failures.

Yeah, this is annoying.

But you don't live with it -- you either move the extra keys to subdir, so that gnome keyring does not pick it; or use "IdentitiesOnly yes"/"IdentityFile foo" in .ssh/config to restrict certain hosts to certain keys (and yes, those work with ssh agent caching too).

I know many people just don't care about working tool, and tolerate the pain, but hopefully if someone knows enough to setup fail2ban, they should also be able to setup ssh config. Especially since reliable ssh connections is such a high quality of life improvement.

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

#115

Post by folmar »

duskwuff wrote: post #100
rhaps0dy wrote: post #92

Earlier quoted context omitted.

> ... need to login to another machine from a new machine that doesn't have the ssh-key. > gateway/proxy/vpn entry to my network has all my ssh keys on it, and it becomes compromised because of some 0-day, the attacker now basically has access to... multiple entire networks That's why you use SSH agent forwarding https://docs.github.com/en/authentication/connecting-to-gith... , so you never need to copy the private k…

On the other hand, SSH agent forwarding means exposing your SSH agent to the bastion host. If that gets compromised, an attacker may be able to move laterally to other systems your personal computer had SSH keys for.

Just use `ssh-add -c` and confirm each use. If you have _really_ old ssh (which is probably insecure anyway) using gpg-agent as ssh-agent had this feature a few year earlier, but we are talking archeology here.

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

#116

Post by londons_explore »

avodonosov wrote: post #91

Some of these credentials could be of legitime users who have just mistyped the IP address.

I'm of the opinion that if they accidentally leak their credentials to anyone, they might as well leak them to everyone.

Sure, the risk of compromise goes up, but the whole culture of "we only sent those passwords once on unencrypted ftp across the internet" leads to powerful nation state spies having a field day...

If all unencrypted data sent over the internet were in a big public archive for everyone to see, then people would soon clean up their security habits.

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

#118

Post by oehpr »

admax88qqq wrote: post #93
theamk wrote: post #83

Earlier quoted context omitted.

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…

> the connection will always succeed. Not from my experience. If you have too many keys and certain ssh agents like gnome keyring don't pick up the key intelligently and will try a all the keys in some order often resulting in the server giving rejecting you due to too many failures.

Yes I've hit this as well! Such an annoying behaviour.

However I think it's a good habit to make records in `~/.ssh/config` for each of your servers anyway just to keep tabs what, where, who, and with what keys.

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

#120

Post by NavinF »

bandrami wrote: post #101
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.

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.

Because it doesn't solve any real problems if you have ssh password login disabled and filter out login failures from logs
Post reply on HN