SSH and OpenVPN are both services requiring authentication. Depending on the configuration, you may authenticate using usernames, certificates, passwords, or one-time passcodes.

Successful authentication will result in an encrypted transport being negotiated. Why would one be more secure than the other?I'm sorry, but this is just plain wrong. UDP uses sockets. Scanning UDP is a trivial matter, especially if you're looking for a specific kind of service. Like IPsec-IKE. Or OpenVPN.Using two certificates provides no additional security, especially as they're stored on the same device, using the exact same security measures (or lack of such). It's like trying to solve the problem with people losing their keys by installing a second lock and giving everybody an additional key.

SSTP uses TLS certificates. L2TP/IPsec uses both server and client certificates. OpenVPN isn't doing anything new.

Yes, like a password. Except it's not a password you can remember, it's one you have to carry with you. Like a key. Except it's a key that anyone can make a copy of in a fraction of a second if they happen to gain access to it.Self-signed certificates are as secure as the issuing server. Using such certificates is not a recommended practice by any stretch of the imagination, unless you're willing to implement a proper Certification Authority, which is a LOT of work.That's an awful lot of hoops to jump through only to end up with a level of security that's identical to that of simple password authentication.

So if you misconfigure sshd, it will not provide the security you need. How is that a "very-fatal weakness?"

The exact same can be said of OpenVPN and any SSL/TLS-based service, as they too operate with a list of accepted encryption algorithms.

1 members found this post helpful.

There is an advantage at moving services (sshd?) to a non-standard port as ONE step to improve security. A worm can still scan the ports, but the service is not where they expect and when they find the services they must do additional probes to identify what service is on what port. Anyone not dedicated will move to an easier target.

Just do not consider that security! If someone IS dedicated, that alone will only slow them down: it will not stop them.

1 members found this post helpful.

Have you actually tried this? I have, and it just does not provide any tangible benefits.

I put an SSH service on a random high port. Brute force login attempts appeared in the logs later the same week.

I made a Windows Remote Desktop service available on port 13000, just to see what happened. It was quiet for almost two weeks, and then all of a sudden thousands of login attempts were logged every single hour.

Port scanners are 100% automated and quite often run via botnets. Using hundreds of thousands of zombies all over the world, they're capable of scanning ALL ports of literally the entire IPv4 address space in about a year.

I won't dispute any of the dissenting comments posted here – least of all those raised by a "senior member" – in the interest of civility and the conservation of forum bandwidth. However, I encourage each of the dissenters to "take a closer look" at exactly what I said. You can find clarification and affirmation of any technical point ... anywhere. And, if you "simply disagree," that is entirely your privilege and I have no quarrel with you.

@sundialsvc: I didn't mean to come off as condescending or anything like that, but if you feel that some of my points were incorrect, you absolutely should feel free to correct them.

My main "objections" (if you will) to your post was:

• the notion that UDP is not socket-based and/or isn't using port numbers, when in fact it absolutely is
• the statement that UDP (in general) cannot be scanned, which is not the case
• the statement that OpenVPN uses two certificates, which supposedly offers superior security to other VPNs, while in fact it uses standard client/server certificates (exactly like L2TP and SSTP; the former of the two requires certificates at both ends) and optionally a common key for HMAC generation if "tls-auth" is enabled, the latter of which offers some security-by-obscurity at best
• the idea that storing a key (erroneously referred to as a "certificate" by the both of us, sorry about that) on a laptop using password protection is somehow preferable from a security standpoint to authenticating using passwords in the first place

That is the core of my critique. If I'm wrong here, well, then I'm wrong and wouldn't mind being corrected.

1 members found this post helpful.

According to this article, DarkSide doesn't do it:
I have tried this. I put ssh on random high port several months ago. I haven't received any login attempts since.


I think the relevant quote here is "you are entitled to your own views, but you are not entitled to your own facts."

Iran-Based Threat Actor Exploits VPN Vulnerabilities

I think it is preferable; stealing the key and guessing the password is more difficult than just guessing the password alone. I suppose if you assume the client's machine is compromised then it makes no difference.

I'm following with interest the sshd authentication debate.

I don't see why

• putting sshd on a high port helps because an nmap scan can uncover it, no?
• Why layers of extra security are needed behind a VPN, unless the VPN is local.

I might be inclined to agree, except in this particular case we're talking about VPNs, which by definition are used by remote users.

Laptops, tablets and phones are lost, mislaid, or stolen all the time. A few years ago I read that every month, there's at least one instance of a minister in the UK government leaving their briefcase behind at the pub or in a taxi, a briefcase that nowadays tends to contain an electronic device.

Guessing a password to an online service takes time, and there are effective mitigation strategies one can put in place to slow down brute-force or dictionary attacks to such an extent that they become impractical. An attack on a password acting as an encryption key for a local file, however, faces no such limitations.Unless the entire device is encrypted, which would give you a level of security equivalent to using a password-based service in the first place, if the device is a PC/Mac (where you have an unlimited number of attempts to guess the password/passphrase).

Encrypted phones or tablets are slightly better, as you're approaching Smart Card-levels of security with the device being locked after X failed attempts. Unfortunately, they may have backdoors waiting to be discovered.

Enforcing the use of high-quality passphrases is by far the easiest way to elevate the level of security in a system, and is indeed considered a Best Practice today, replacing the previous recommendation of using so-called "complex" passwords and rotating them frequently.

If two-factor authentication is required, or if encryption keys need to be secured, Smart Cards are the way to go. There's a reason laptops for the enterprise market usually come with a built-in Smart Card reader.

Yes, the only way it can help is to make your logs quieter. In practice, it seems that fewer attackers bother to scan higher ports. Perhaps your higher ports are more likely to be scanned if some other lower ports are open? That might explain the discrepancy between Ser Olmy's experience and mine.

VPN software isn't perfect, it may have exploitable vulnerabilities like any other software. If your outer VPN layer is compromised, you will be glad to have additional inner layers. For larger installations, you can imagine there might be many users allowed into the VPN, but not all of them should have same level of access to the resources inside.

Yeah, that's the "client's machine is compromised" case.

That's interesting. May I ask if this is a service at a company, or one running on a computer with a dynamic IP address?

Because I just realized that in every case where I've tried this, the system in question has belonged to a company using IP addresses that were either allocated directly from a RIR, or in ranges that an ISP used exclusively for business clients.

Edit:That may very well be the case. You rarely see a VPN concentrator without a web-based login page, and most firewalls do indeed protect multiple services, some of which have to reside on well-known ports.

There is talk now of governments making ransom payments illegal. There's a recent report by the international Ransomware Task Force on the subject. The BBC has an article on it too with the pros and cons of a ban. https://www.bbc.co.uk/news/technology-57173096.

The Jesuit education I was forced into makes you think like a sneak.

It seems the best thing to do with the lower conventional ports (20,22,etc) is to open them but route them to /dev/null, or /bin/false.

Some 'pay no ransomware' pact might have happened already in Europe. Our politicians are most adamant that we are paying no ransom, but there's no talk of backups being restored. It strikes me there must be at least some informal EU agreement. Some patient information is already being offered online on the dark web. If you find stuff, btw, the Irish government wants to know. Nearly any hospital beginning with 'Saint,' 'St.' or having 'University Hospital' (UH) at the end of the name is Irish.

I think that may actually lead to overall improved security across the board.

The arguments against this in the BBC article centers around the idea that some may have to choose between paying an illegal ransom in secret, or going bankrupt. That's like saying that a company whose negligence with regards to fire safety caused their warehouse to burn down, is left with the "difficult choice" between committing insurance fraud and going out of business.

Ransomware attacks succeed because InfoSec isn't taken seriously enough. Proper security measures must be implemented in all organizations (which would include cloud service agreements that place the financial responsibilities for OpSec failures squarely on the service provider), and a disaster recovery plan must exist in case all other measures fail.

If one chooses not to implement such measures in order to save money, well, then one should have to accept the risks and consequences associated with that choice. Make those consequences sufficiently grave, and most will choose not to take the risk in the first place.

@Ser Olmy, To reply to most of your points:

• UDP does not use ports, which are used by TCP/IP to conduct sequenced, two-way communications. An intruder can tell when a TCP/IP port is being listened to, but it cannot detect whether a UDP datagram will be replied-to.
• The "tls-auth" facility is very valuable because it acts upon the initial connection-request packet, immediately and efficiently determining whether it deserves a reply. The server does not engage in a login handshake unless the supplicant demonstrates possession of this "identification badge." It doesn't reply at all – thus concealing its presence. It requires a trivial amount of computation to make this decision.
• A digital certificate has a great deal more so-called entropy than any password could have – thousands of random bits. Furthermore, it can be [self-]signed, which is how OpenVPN determines whether a certificate should be accepted. You can't sign it correctly if you don't have that highly-secret key.
• Most importantly of all, unlike a "shared secret" password, each certificate is unique, therefore individually identifiable and individually revocable. When one employee leaves the company or one laptop gets stolen, access can be selectively revoked without affecting anyone else.
• On a laptop, say, you can encrypt the certificate with a password so that it can't be used by anyone who doesn't know the magic word. But that password is associated only with the task of decrypting that certificate so that it can be used by the bearer.

Therefore: put a cryptographically-protected OpenVPN as your front line drawbridge, then put sshd as the portcullis, sitting only on the inner network and firewalled away(!) from the outside world. (I also strongly prefer to use certificates at this layer.) You can't even reach it unless you've crossed the (hidden ...) drawbridge.

As I said, "authorized users confidently approach the smooth rock wall and disappear into it, finding the secret drawbridge and passing right over, thus reaching "ssh" and also quickly passing through that. Unauthorized access attempts are left wandering in the dark, searching for a drawbridge they cannot find, with nothing to tell them that such a thing even exists.

UDP uses ports, exactly like TCP, SCTP, and DCCP. Please read the RFC link.

What it does not use, is sequence numbers and transmission windows, as it is connectionless.UDP ports can be probed, as a non-listening port will return an ICMP message (according to the standard). No reply means filtering or an unresponsive service, and the latter can then be probed using the classic TTL trick.

OpenVPN using "tls-auth" (a misleading term if I ever saw one) behaves exactly like a filtered port. It explicitly does NOT behave like a non-listening port. And the TTL-expired-in-transit trick will work just fine, unless the service is running on the firewall itself (which is not likely in a corporate environment).Those bits are not entropy. Asymmetric encryption keys are in no way random, and symmetric keys (which hopefully are) do not have thousands of bits. And the latter are not found in certificates.

Symmetric keys are typically 128 bits in length, which is more than enough. A 30 character passphrase is roughly the equivalent to a 130-160 bit key.I think you should seriously consider reading up on cryptographic certificates.

1 members found this post helpful.