Getting PR_END_OF_FILE_ERROR on Firefox, anyone else?
I was too.. I then disabled DNS over https (which was pointing at nextdns) and it started working. Not sure if that was coincidence or an actual fix
Brute.Fail: Watch brute force attacks fail in real time
61–70 of 268 posts
Re: Brute.Fail: Watch brute force attacks fail in real time
#62For 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.
Re: Brute.Fail: Watch brute force attacks fail in real time
#63So 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…
You still got the response packets?
Re: Brute.Fail: Watch brute force attacks fail in real time
#64This is amazing!
Are you open sourcing this?
Can others stream their logs to your servers and have a crowdsourced list of attackers in real time together with their activity?
Re: Brute.Fail: Watch brute force attacks fail in real time
#65Thinking 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.
Re: Brute.Fail: Watch brute force attacks fail in real time
#66I 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.
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?
There are numerous ways ways around it (port knocking, VPN) that gambiting (for whatever reason) is choosing not to employ. Your idea is a good one though
Re: Brute.Fail: Watch brute force attacks fail in real time
#67I kinda want to know the server's address so I can send a "hello_hn" message in the passwords there.
I tried the IP resolved by the domain "brute.fail" but it doesn't accept SSH connections :)
I tried mikedamm.com (the author's domain) and it does accept SSH but my failed login attempts don't show up.
Re: Brute.Fail: Watch brute force attacks fail in real time
#68So 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.
You still get the attacks and they show in the logs
Also, it’s not just ssh, there are brute force attacks for pretty much any service that you run
Our logs show automated attempts to run exploits on our web servers everyday
Re: Brute.Fail: Watch brute force attacks fail in real time
#69I 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.
Yeah, we have the same problem. I made a custom firewall rule and a python script that watches the windows logs for multiple failed logins to combat this and it seems to work pretty well but there's always new ips.
IPBan does that:
Re: Brute.Fail: Watch brute force attacks fail in real time
#70If this doesn't get to install fail2ban don't know what will.
I don't see the point of fail2ban on a server without password login, except to keep the log file tidy. That isn't worth risk of locking out legitimate users due to misconfiguration or user error. CMV.
Keeping the log file tidy isn't just an OCD thing. If you're searching for a needle in a haystack, where needle is "suspicious login", and the haystack is "all of the login attempts from the past the months", your job is made much easier when the haystack is much smaller.
That said, the fail2ban defaults are way too low and I've locked myself out with them. They can be turned way up (ban after way many more attempts) so that there's no risk of locking out legitimate users. (Assuming your users didn't forget their exact password and then generated a small dictionary to try with.) On a server with potential misconfiguration, accepting passwords is one of them.