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…
What SSH Hacking Attempts Look Like
161–170 of 186 posts
Re: What SSH Hacking Attempts Look Like
#162Earlier quoted context omitted.
why nftables rather than iptables?
Im also curious about this, they use the same netfilter backend
Is that true? I thought nftables was still behind on supported features compared to iptables and nftables runs on a VM.
Anyway, nftables should be nicer to administer. More pf-like.
Re: What SSH Hacking Attempts Look Like
#163Re: What SSH Hacking Attempts Look Like
#164Earlier quoted context omitted.
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…
/etc/sshrc executes before a successful ssh login, you can use that to be notified before an attacker has any access to log files
... so? How does that contradict what I wrote?
Re: What SSH Hacking Attempts Look Like
#165Fairly 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.
I feel like fail2ban failing open is a good thing. If it fails closed you can't SSH into the server. If it fails open it's just as though you aren't using fail2ban. 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.
> I feel like fail2ban failing open is a good thing. If it fails closed you can't SSH into the server. If it fails open it's just as though you aren't using fail2ban.
But it fails open whilst you think there's a layer of protection there.
> Actually, my biggest fear with fail2ban is it failing and locking me out of a remote server
Most of these tools will let you whitelist an address - and presumably there's usually a way back in via a serial console/IPMI-KVM interface?
Re: What SSH Hacking Attempts Look Like
#166Earlier quoted context omitted.
I feel like fail2ban failing open is a good thing. If it fails closed you can't SSH into the server. If it fails open it's just as though you aren't using fail2ban. 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.
> I feel like fail2ban failing open is a good thing. If it fails closed you can't SSH into the server. If it fails open it's just as though you aren't using fail2ban. But it fails open whilst you think there's a layer of protection there. > Actually, my biggest fear with fail2ban is it failing and locking me out of a remote server Most of these tools will let you whitelist an address - and presumably there's usually…
>But it fails open whilst you think there's a layer of protection there.
That's pretty easy to test for.
>will let you whitelist an address
I don't have a static IP address.
>usually a way back in via a serial console/IPMI-KVM interface?
I haven't been able to do this at my provider when password login is disabled. Maybe I just don't know the way.
Re: What SSH Hacking Attempts Look Like
#167Earlier quoted context omitted.
Set up a non standard port. This will stop over night.
It has stopped now (I simply removed port 22 from the whitelist except for connections originating with my home ISP, which is a local ISP where abuse reports actually work)
Have you tried port knocking as a way of temporarily whitelisting the right IPs?
Re: What SSH Hacking Attempts Look Like
#168I wrote a little utility to keep ssh ports off unless a totp packet is sent to a UDP port. I haven't worked on it much since the initial proof of concept. There are several things that could be done to improve it (open only for the address that sent the packet, symmetric key for safer secret distribution, etc). Shared key would involve encrypting time and only open if the decrypted time matches current.
The totp packet is a full hash of time + shared code so brute force is completely infeasible.
It's currently in python, it would be much better in something like go with daemon monitoring. It is very simple, and it practically eliminates attempts. If it became widely known there would probably be attempts on the udp port. An additional improvement would be randomize the listening port based on the time+hash:
Re: What SSH Hacking Attempts Look Like
#169I wrote a little utility to keep ssh ports off unless a totp packet is sent to a UDP port. I haven't worked on it much since the initial proof of concept. There are several things that could be done to improve it (open only for the address that sent the packet, symmetric key for safer secret distribution, etc). Shared key would involve encrypting time and only open if the decrypted time matches current. The totp pack…
In case you were unaware and didn't just want to write your own, fwknop is an off the shelf tool to do the same.
Re: What SSH Hacking Attempts Look Like
#170I wrote a little utility to keep ssh ports off unless a totp packet is sent to a UDP port. I haven't worked on it much since the initial proof of concept. There are several things that could be done to improve it (open only for the address that sent the packet, symmetric key for safer secret distribution, etc). Shared key would involve encrypting time and only open if the decrypted time matches current. The totp pack…
In case you were unaware and didn't just want to write your own, fwknop is an off the shelf tool to do the same. http://www.cipherdyne.org/fwknop/
I appreciate the reference.
I looked at that before starting and reference it in the blog post (but should probably include a direct link to the software rather than the original concept post and article that include links).
The similarities are they both use a single packet and they are both an improvement on port knocking.
This is a simpler solution (pairing UDP with TOTP). No TCP connection is required. Making it ip address specific would prevent replay attacks (although even without address specific the replay would only be valid for ~30s).
Another benefit is that a port scan will reveal no ports open (because it is a one-way UDP based protocol).
fwknop is definitely a polished solution where this is just a proof of concept for the TOTP/UDP as a shared key knock.
Thank you for the feedback!
EDIT: I updated the post to include a direct link to fwknop rather than just links to the posts/articles about it.