Live data from Hacker News

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

brute.fail

141–150 of 268 posts

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

#141

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.

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.

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

#142

Earlier quoted context omitted.

I'm not sure manual log scanning is all that interesting. You probably want to produce a list of successful logins and review that regularly.

If an attacker manages a succesful login you've already lost. Better to catch them in the act while they're scoping you out.

If your SSH key leaks you're not going to have a warning. All you'll see is a login from yourself that you don't remember.

I am pretty sure we turned off password authentication like 10 posts up this thread.

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

#143

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

Very naive question: can a bad actor just use a VPN to get around this?

Yes

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

#144

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…

Distributed valgrind

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

#146

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…

Try negotiating ssh compression and then sending terabytes of compressed zeroes. Might work for a badly implemented scanner.

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

#147

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.

It is not. Deleting my spam folder is not the same as deleting yesterdays email.

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

#148

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.

Better: just ban password logins, and use cryptographic keys instead.

Use Role Based Access Control

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

#150
post #90

Earlier quoted context omitted.

I know nothing about networking, so pardon the ignorance: Why isn't there (or is there) some kind of service you can use to map some crazy URL to your personalip:port, like... http://obscuremyshit.com/393nnasjhf83u98723401 = personalip:port And only when a connection is referred from that source, does the RDP server even expose itself? And for all other traffic that hits personalip:port, it does absolutely nothing?

Is there some referrer field in the RDP protocol handshake that I'm not aware of?

The issue in GP's idea is, that there isn't such a referrer field (his first sentence is correct). And even if RDP has it, the service would be limited to RDP, and GP's idea is probably to have it for any service thinkable, e.g. also SSH.

A solution on top of that would be for this obscuremyshit.com service to have a client-side listener. So if I get a hit on the page obscuremyshit.com/393nnasjhf83u98723401 from IP x.y.z, the obscuremyshit client running on the target cimputer gets a signal from the obscuremyshit server to "Open port 22 and allow a connection from the IP x.y.z" (I guess that means the client would have to be in control of the firewall rules), and then the computer with the IP x.y.z would have to establish a connection within a timeframe.

Of course it would get more complicated if e.g. the above URL is hit from a different IP address (e.g. from someone's phone over 5G, and the SSH connection wants to come from a laptop over a cafe WiFi).

Post reply on HN