Number of Unauthorized Access Attempts: Zero

Every web site has both a public-facing side and a back door, the latter being the way that site owners gain access to the underlying software in order to maintain it. The most common way to do this is with ssh ("secure shell"). But there is an immediate and obvious problem with this approach: when you attempt to connect, you see this:

So, all that anyone has to do in order to try to break into your system is to guess a user-id and a password that might work. (Starting, perhaps, with: "root / l3tm31nt01t." Which, by the way, is a combination that is very commonly used.) There are tools that will try to do this thousands of times. Your server logs fill up with "unauthorized access attempt" messages.

(Heaven help you if they make it through, because you won't know it ... until ...)

Your web site will also be very routinely "port scanned," looking for things that are unintentionally exposed to the public. For instance, your database server might be accepting connections from the outside. An "open TCP/IP port" will reveal the exploitable vulnerability.

But there is another way: a technique that is both "far more secure" and in some cases actually invisible. This is Virtual Private Networks (VPN), specifically OpenVPN.

VPNs operate as a "secure TCP/IP router," implemented in software. When you connect, various IP-addresses on the "other" side become accessible to your computer as though you were on a wired or wireless network with them. But in fact the traffic is being captured by the OpenVPN router and sent through a cryptographically-secure "tunnel." Importantly, the fact that this is being done is not apparent to any application on either side. And so, there is no possibility that traffic will pass between the two computers "in the clear."

Although VPNs can be secured by passwords ("pre-shared keys (PSKs)" in VPN parlance), this should never be done. Instead, the connections should be secured by digital certificates. OpenVPN uses exactly the same technology that is used to secure access to https: web-sites (including this one). Whereas a password contains very little so-called "entropy," thus making it "guessable," a digital certificate is truly random and one-of-a-kind.

Furthermore, since each certificate is unique, it can uniquely identify each user that is authorized to connect. (The certificates can be encrypted using a passphrase to prevent mis-use, say on mobile computers.) Certificates can be individually revoked to deny future access without affecting any of the other users.

The OpenVPN system provides an additional certificate-based feature called tls-auth which actually makes your OpenVPN network invisible to the outside world. Intruders cannot detect that the server exists, unless they are authorized to connect to it. There are no "open ports" to be scanned, and the server will silently drop any connection request that is made by someone who does not possess the necessary tls-auth certificate. So, not only can outsiders not connect to your VPN, they can't even try!

Like the Dwarvish door to the Mines of Moria in Lord of the Rings, it is a secret door.

ssh is commonly still used in such an environment to provide login capability to staff members, but the ssh tunnel is routed through the VPN and cannot be reached without it. Similarly, SQL servers and such will "listen" for incoming connections only through the VPN tunnel. Authorized users who have successfully connected to the VPN are able to do their work without further impediment, but there is no other way to get there. To the outside world, they don't even exist.

The "administrative portal" of the web site should also be safeguarded in this way: the URLs needed to reach this part of the site can only be accessed by a user who is using the VPN. (Ideally, this part of the site is being run by a separate web server [process] which is only "listening" to the VPN.)

Hence: "Number of Unauthorized Access Attempts: Zero." Your server logs are blissfully empty, and your computers aren't wasting time fighting off nuisance. Yet the resulting configuration is easy to use by authorized users – each one using, and thus identified by, a one-of-a-kind (and, not yet "revoked") certificate that has been issued only to him or her.