The whole stealth thing (and "port knocking" along with it) is wildly overrated. If your security depends on people not knowing you're running SSH or OpenVPN, you have bigger problems.
If you want to get all cutesy, go hack SSH to add an extra round or two to OpenSSL's AES. That'll learn 'em.
I think the parent comment is referring to OpenVPN's HMAC packet authentication of the TLS control channel, the --tls-auth option. From the man page:
The rationale for this feature is as follows. TLS requires a multi-packet exchange before it is able to authenticate a peer. During this time before authentication, OpenVPN is allocating resources (memory and CPU) to this potential peer. The potential peer is also exposing many parts of OpenVPN and the OpenSSL library to the packets it is sending. Most successful network attacks today seek to either exploit bugs in programs (such as buffer overflow attacks) or force a program to consume so many resources that it becomes unusable. Of course the first line of defense is always to produce clean, well-audited code. OpenVPN has been written with buffer overflow attack prevention as a top priority. But as history has shown, many of the most widely used network applications have, from time to time, fallen to buffer overflow attacks.
So as a second line of defense, OpenVPN offers this special layer of authentication on top of the TLS control channel so that every packet on the control channel is authenticated by an HMAC signature and a unique ID for replay protection. This signature will also help protect against DoS (Denial of Service) attacks. An important rule of thumb in reducing vulnerability to DoS attacks is to minimize the amount of resources a potential, but as yet unauthenticated, client is able to consume.
tls-auth does this by signing every TLS control channel packet with an HMAC signature, including packets which are sent before the TLS level has had a chance to authenticate the peer. The result is that packets without the correct signature can be dropped immediately upon reception, before they have a chance to consume additional system resources such as by initiating a TLS handshake. --tls-auth can be strengthened by adding the --replay-persist option which will keep OpenVPN’s replay protection state in a file so that it is not lost across restarts.
and I just realized who I'm responding to... :) I'd be interested in knowing if the above isn't a strong/decent rationale.
there's probably a bug in some code on your system that's exploitable. maybe openvpn or ssh or its configuration (c.f., debian crypto bug).
under this model, anything that increases the time til (inevitable, under this threat model) success, works.
running ssh or openvpn on a different port or whatever to "hide" it, will help against mass scans for common exploits. it increases the work to find the problem. of course it won't really help against a concerted, targeted attack. but i'm pretty sure unskilled, mass attacks are more common than targeted attacks.
Still, if OpenVPN drops packets lacking the HMAC packet authentication without processing them further, then either
1) the guy would also need the HMAC key, or
2) the zero-day is in the code that looks at the HMAC signature.
It's not that I only count on this for security, but it's a matter of reducing the attack surface. Likewise, I don't have passwordless guest accounts on all my servers, since that would make the attack surface even greater.
if (1) then i certainly agree that none of this really matters (i apologise if that wasn't clear from my previous comment).
on the other hand, if his objective is (2), and not everyone is using some of this obfuscation, then this separates you from the crowd for a little while (but my model is that as time goes on, you are inevitably exploited).
i realise after your company was exploited it might make you feel like (1) is always the case but for many (2) is the salient threat.
Generally speaking, the people running around with OpenVPN and SSH zero day are looking to break into your machine. The people looking to break into any machine are either targeting Windows clientsides, or weeks-to-months-old web vulnerabilities.
People with SSH zero-day are not, by and large, looking to burn those vulnerabilities by spraying them into every busybody's honey pot logs.
> The people looking to break into any machine are either targeting Windows clientsides, or weeks-to-months-old web vulnerabilities.
Actually the people looking to break into your machine are targeting windows clientsides and weeks-to-months-old web vulnerabilities.
There's a cost involved in developing 0day, droppers, remote access trojans, maintaining breach and exfil teams etc. If these guys can get into the developer laptops with an email, a wink and a PDF then why waste the 0day? If you're putting all your effort into a custom SSH daemon without expending equivalent effort on your connection sources (especially when connecting to the Internet) then you're doing it wrong.
If you want to get all cutesy, go hack SSH to add an extra round or two to OpenSSL's AES. That'll learn 'em.