Live data from Hacker News

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

brute.fail

71–80 of 268 posts

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

#71

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'd be cautious about stuff like this - if you annoy the wrong person that could paint a target on your back.

Ah where's your sense of fun ;)

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

#72
post #58

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.

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.

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

#74

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'd be cautious about stuff like this - if you annoy the wrong person that could paint a target on your back.

Realistically though, they'll probably timeout by themselves automatically if they haven't seen a password prompt after N seconds. TCP connections can hang overall, so having that would be basics anyway.

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

#75
post #62

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.

That seems like overkill. I just disable password authentication, and use SSH public keys only. It prevents brute force attacks completely.

This, and move the endpoint on an uninteresting port to lower the noise in the logs

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

#76

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…

Nice. Also an illustration that its good to establish one's inner motive first, like here might range from a desire for simple solutions, to another dimension of drama, which might indeed be desirable sometimes, for entertainment or for snapshots to use in a book one is writing. :)

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

#77
post #15
post #11

Earlier quoted context omitted.

it bugs me that they're not trying the passwords in lexigraphical order :-D also, who has sshd without `PermitRootPassword=no`? they need to broaden their horizons and try `admin`, `ec2-user`, and `ubuntu` /s

Who still allows password-based login for any SSH account, root or not? Keys, certificates, or Kerberos for all users.

I do. For some reason ssh keys became the group-think security advice to repeat ad nauseam. I often find people have only considered this very shallowly, and their reasoning is just "But OMG, entropy lolz" without actually seriously considering the available entropy and likely attack vectors and failure.

Why?

The benefits are largely theoretical if you choose sufficiently strong randomly generated passphrases, with some symbols and numbers mixed in, which I set my password manager to do. (Actually, I have a couple of super important, super long ones I keep only in my head.)

The draw-backs however are several:

1. I find that its not uncommon I find myself having to chain together ssh tunnels and other strange things to debug networking issues and need to login to another machine from a new machine that doesn't have the ssh-key. Treating servers as cattle exacerbates this issue since it's more likely to occur.

2. If a machine or server I use to manage stuff as a 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. Now, this is technically true of my password manager as well, except that the context / IP addresses, etc, is not going to be as obvious as it will be on the server where the attacker can see the running services, check logs, command histories, etc. With the password-based management, sure I could get hit by a keylogger, but everything won't be compromised by default.

3. In my experience, you're more likely to lock yourself out than let an attacker in. You basically still have to have your keys managed via some type of password manager anyway because otherwise you run the risk of getting locked out of everything in case you're away from your primary machine and need to address some emergency or something.

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

#78
post #11
post #5

Man, that one Brazilian IP really going hard

it bugs me that they're not trying the passwords in lexigraphical order :-D also, who has sshd without `PermitRootPassword=no`? they need to broaden their horizons and try `admin`, `ec2-user`, and `ubuntu` /s

I do on my home servers where I am the only one and do not need traceability?

Why do you ask, because it is dangerous?

I would love to learn something here.

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

#79

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…

[dead]

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

#80

Thinking about it, fail2ban is almost entirely a placebo given that your password should be basically impossible to brute force anyways if you have the knowledge to implement fail2ban.

It can conserve server resources to just stop responding to brute force attacks

If your server is a Gameboy, maybe.
Post reply on HN