brutce force ssh login attempts

[eldo]

I believe this is how my systems are configured.
Currently my hardened server is a jail on FN, but I'm planning on migrating to a minimal physical device in the future.

 

[Ericloewe]

What's the difference between relying on SSH vs OVPN as entry point?

FreeNAS isn't meant to be hardened for this sort of stuff, whereas OpenVPN is. See above for a pure-SSH option.

That said, I'm not sure I completely trust a VPN solution on a consumer router. Merlin's firmware might be better, I haven't been following it closely lately, but you still need to keep up with updates and make sure Merlin keeps up, too.

 

[Ericloewe]

Currently my hardened server is a jail on FN

Well, that's significantly better. But wait, are you allowing password authentication? That's generally discouraged.

 

[eldo]

Gotcha.
My original intent was to the technologies themselves, not any FreeNAS specific implementation.

Yes, currently I'm allowing password auth, but I'm looking at moving to a key based auth in the near future.

I travel a lot for work, and more often than i'd have thought need to access something via ssh from a new host when I do not have a method of bringing an auth key with me.

It's strange, some places will take my electronics or require I leave them at the hotel, but let me make arbitrary tunnels through their networks.
Sometimes I cannot even get a usb drive on site.

Since I can't use any of that, and 2FA wouldn't work due to lack of electronics, I've been in a bind a few times.

 

[rvassar]

What's the difference between relying on SSH vs OVPN as entry point?

This may be a bit too far off topic for this thread, and if so, i'll move it to a new thread.

SSH will connect your client device to a remote device, and may allow a couple ports forwarded back or forth... That can lead to quite a bit of damage. OpenVPN will connect entire networks, routeable with full access and not bat an eye. Needless to say, configuration mistakes made with OpenVPN can be quite serious. I won't offer the opinion that one is worse than the other. Only you can answer that.

One of the nice things about OpenVPN is you can configure TLS-Auth. This requires you to generate a "ta.key" file, and becomes an extra key to loose. But it allows the OpenVPN server to discard these scanning & bot automation connections attempts long before they get a chance to bleed your resources. A packet comes in, it's deemed not signed by the ta.key file, and it's dropped on the floor.

More info here:

https://openvpn.net/community-resources/hardening-openvpn-security/

 

[eldo]

I was not aware about the ta.key file, that sounds interesting indeed.

I've been using ssh for a number of years, and am familiar with local, remote, and dynamic port forwarding.
Can you elaborate on what you mean by 'quite a bit of damage'?
I'm assuming you mean something other than what any rogue host could do with access to a freely available port.


I may not have worded my question correctly when I asked about entry points.
Earlier in the thread, I read Heracles' post to mean that a VPN was fundamentally a more secure method to establish an encrypted connection.
I was trying to ask specifically about that, as I'd always assumed that a VPN or SSH would be roughly equivalent given the same keylength.
Also, the comment about a single SSH flaw opening the can of worms.

I think I may have misunderstood the point, and that Heracles was pointing out the inherent risk of connecting directly to the FN server via port forward, DMZ, or direct placement on a publicly accessible IP.

 

[rvassar]

I've been using ssh for a number of years, and am familiar with local, remote, and dynamic port forwarding.
Can you elaborate on what you mean by 'quite a bit of damage'?
I'm assuming you mean something other than what any rogue host could do with access to a freely available port.

Well... Consider what happens when one of these dictionary attacks is successful. What then? Ssh provides access to the remote host, and perhaps a shell account. So the attacker then has privileges equivalent to that user. What happens if he can then escalate those privileges? Become root, and start an old school early 90's SLIP/PPP daemon, turn on kernel routing, and you have the functional equivalent of a VPN via ssh into that network.

This is why I strongly advocate a secure ssh "jump box". Something that has extra hardening steps, both locally on the box, but also appropriately filtered on the local network, etc... Layers of security... Reduce the attack surface.

 

[Heracles]

What's the difference between relying on SSH vs OVPN as entry point?

Well, there are many...

OpenVPN will do mutual authentication while SSH will not do it
OpenVPN being different, it will never have the same vulnerability as SSH. Should you chain 2 SSH daemon, a single vulnerability can take both of them down
OpenVPN will terminate at the firewall, allowing it to filter the content of the secured remote connection. If you SSH in the box, nothing will be able to filter the content.
OpenVPN will provide you with IP-level access while SSH will give you TCP-level access

And more...

 

[eldo]

Thanks for some further details rvassr and Heracles

Both great points.

While I do have a somewhat hardened jump box for SSH access, I had not given thought to privilege escalation and the terror that can bring.

The OpenVPN information was especially interesting.