"Yes things other than SSH occasionally show up" Like what?
HTTP/HTTPS basic auth, FTP/FTPS, LDAP, SSH, and a few other protocols are supported. I only show ones that actively try credentials, not just port scans.
Brute.Fail: Watch brute force attacks fail in real time
181–190 of 268 posts
Re: Brute.Fail: Watch brute force attacks fail in real time
#182Earlier quoted context omitted.
They're impotent little weasels who couldn't hit a target the size of a barn, so the risk is minimal.
"do not guess that it will be your weakest opponent nor guess what they will try, prepare for your strongest adversary and all that they can do" -- mutatis mutandis, Sun Tzu, Art of War
Not to disagree with infallible thousands of years old advice, but surely resources are in far shorter supply than potential attacks, so we have to prioritize and filter.
Re: Brute.Fail: Watch brute force attacks fail in real time
#183I 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.
Why not VPN?
Because it's a disposable server running in an isolated VM that I need for one reason only and even if someone does break in(impossible with these random logins, and I assume RDP doesn't have any currently known security faults) then it wouldn't be the end of the world - I have a notification on successful login so I'd be told if it ever happened and I would just kill the VM instantly. Right now it's exposed to the internet for simplicity sake.
Re: Brute.Fail: Watch brute force attacks fail in real time
#184Is hiding the last octet of the IP address really enough privacy?
Do these people deserve privacy?
Re: Brute.Fail: Watch brute force attacks fail in real time
#185Earlier quoted context omitted.
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: https://github.com/DigitalRuby/IPBan
Oh I didn't know this existed - will definitely set it up, thank you!
Re: Brute.Fail: Watch brute force attacks fail in real time
#186Earlier quoted context omitted.
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 s…
If you think a key is just a longer password, you don’t understand public key cryptography.
A man in the middle attack where you accept the server key can steal your password, but it can’t your key.
Re: Brute.Fail: Watch brute force attacks fail in real time
#187I 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?
That’s how I hide my password manager, but that’s HTTP and has Header fields to dispatch on in the reverse proxy.
Re: Brute.Fail: Watch brute force attacks fail in real time
#188Earlier quoted context omitted.
Because it doesn't solve any real problems if you have ssh password login disabled and filter out login failures from logs
With port knocking or a simple as having SSH on a non-standard port, the connection request stops before even opening the TCP connection. That's less load on the system, less logs, less writing to storage, etc. Less of what you don't want must surely be preferable.
…all for the cost of vastly increased complexity. You’re just micromanaging your pets there. If the load of failed login attempts or the log writes brings your servers down, you have a whole lot of other problems to take care of.
Re: Brute.Fail: Watch brute force attacks fail in real time
#189I 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…
maybe telnet over wireguard ? :)
That just sounds like SSH with extra steps
Re: Brute.Fail: Watch brute force attacks fail in real time
#190Earlier quoted context omitted.
Because it doesn't solve any real problems if you have ssh password login disabled and filter out login failures from logs
With port knocking or a simple as having SSH on a non-standard port, the connection request stops before even opening the TCP connection. That's less load on the system, less logs, less writing to storage, etc. Less of what you don't want must surely be preferable.
Are we talking about ssh on an ESP32 or a 2U server? You'd saturate my transit port before I noticed the load on my server or the logs that I filter by default.
btw TCP is cheap compared to public key crypto