151–160 of 186 posts
Earlier quoted context omitted.
And then what? /etc/ssh is still owned by root, another user can't see the hostkeys. So you'll get an error message if custom keys are used.
Remote user tries to log in. Cannot. Issues (or trojan prompts for) password. It's a game of percentages.
One thing I've found amusing is you can cut down SSH hacking attempts to almost zero (at the cost of compatibility with legacy systems) by using very progressive encryption. If you force use of ChaCha20/Poly1305, ED25519 and so forth in sshd_config, you'll see these attempts almost disappear. There's probably an observation to be made about just how overwhelmingly many of these attempts come from fairly old software…
My current take: nftables instead of iptables port-knocking non-standard port key+pass access/auth ip whitelist good logging ED25519 wherever possible!!!
I love the idea of Single-Packet Authorization with fwknop instead of port knocking: http://www.cipherdyne.org/fwknop/
Some notes from an InfoSec person. - Have a stand alone SSH server that is something like a R-Pi[type B] running an OS that gets patches regularly via unattended-upgrades and reboots itself at least once a week.[could also be a minimal VM like AlpineOS if you need Gbps+ line speed] - Have this R-Pi and your network gear plugged into a UPS that can withstand at least a couple of hours of power outage. - Use non-standa…
"Others have mentioned port-knocking which is a cool trick but not something that I typically use in an actual daily defense strategy because I'm not sure how much value it really adds." I don't know how much it adds, but it is non-zero. The knockd daemon is rock solid[1] and your ssh port traffic goes down to zero (other than your own use). Port knocking has no place in security by itself but I think it's a wonderfu…
Earlier quoted context omitted.
I think the person above was maybe being too imprecise with their language. Obviously it doesn't affect the frequency of portscans and the like, but whitelisting ports is a reasonable approach to further mitigating your risks.
Well, potentially. But then, there is no fundamental difference between a service rejecting unauthorized connections and a firewall rejecting unauthorized connections. If your service is already rejecting unauthorized connections, you don't gain anything by also rejecting the same connections at the firewall, and that is why "No open port = no hacking attempts" is ultimately nonsense: It doesn't change anything about…
Earlier quoted context omitted.
Well, potentially. But then, there is no fundamental difference between a service rejecting unauthorized connections and a firewall rejecting unauthorized connections. If your service is already rejecting unauthorized connections, you don't gain anything by also rejecting the same connections at the firewall, and that is why "No open port = no hacking attempts" is ultimately nonsense: It doesn't change anything about…
That's not how it works. If a vulnerability is found in the service, and you don't need external access, blocking it from the firewall/router essentially blocks the vulnerability. In your scenario, with a public facing service, you will get exploited by a 0 day.
Earlier quoted context omitted.
> No open port = no hacking attempts. That's just obviously nonsense? Closing the port does not change anything about the attempts. Nor about the success rate of the attempts, if you aren't being an idiot with insecure passwords.
Closing the port does not change anything about the attempts. Nor about the success rate of the attempts, if you aren't being an idiot with insecure passwords. How about "No open port = no concern about possibly vulnerable services running on open ports"? I actually worry less about passwords and more about overflows, protocol problems and parse errors these days.
My point isn't that blocking off ports at the firewall is always pointless, but that it's usually a trade-off, and keeping a vulnerable service running behind the firewall can still be a risk, and many "hacking attempts" are just irrelevant if you follow general best security practices, so it's pointless to do anything specifically to prevent them.
Fairly standard stuff, definitely interesting to see all the IoT credentials attempred. I'd recommend SSHGuard over fail2ban though, I seem to remember the version of fail2ban in the Debian repos completely choking on IPv6 and failing open which is obviously undesirable.
Actually, my biggest fear with fail2ban is it failing and locking me out of a remote server. If it indeed always fails open then there's no reason for me not to use it.
Though, I don't know how it could be guaranteed to always fail open.
Earlier quoted context omitted.
The failed attempts make it harder to monitor for other attacks because of the noise in log files, network traffic, etc. and if an attacker IP is blocked early they can't try more effective attacks.
Except actual attacks don't show up in logs anyway, so it's still pointless? The SSH daemon logs when it successfully rejects an access. A successfully rejected access is inconsequential to your security. If you are using secure passwords or pubkey authentication, it will never log a successful login by an attacker. What remains then is exploitation of the SSH server ... but the SSH server doesn't have a code path th…
One thing I've found amusing is you can cut down SSH hacking attempts to almost zero (at the cost of compatibility with legacy systems) by using very progressive encryption. If you force use of ChaCha20/Poly1305, ED25519 and so forth in sshd_config, you'll see these attempts almost disappear. There's probably an observation to be made about just how overwhelmingly many of these attempts come from fairly old software…
I can confirm from the same experience, however, that it prevents most hacking attempts from ever going to the authentication stage.