On 10/14/2013 07:49 AM, Martin Vaeth wrote: > Michael Orlitzky <mich...@orlitzky.com> wrote: >> Port knocking is cute, but imparts no extra security. > > It does, for instance if you use it to protect sshd and > sshd turns out to be vulnerable; remember e.g. the > security disaster with Debian. > >> A better, secure way to achieve the same goal is with OpenVPN. > > Using yet another service with possible holes to protect a sshd? > In this case, I would like port knocking at least for this OpenVPN. >
The sensitive parts of OpenVPN are audited regularly, and it uses "SSL" -- public key auth to exchange a symmetric key, both of which use tried-and-true algorithms/code. Port knocking on the other hand is just security through obscurity, and is visible over the wire (or over the air, most likely, if you're on a laptop). Obscurity does provide some benefit, but it gets dismissed because we tend to ignore the constant factor when talking about these things. A problem is "solved" if it's easy to exponentially increase the amount of work an attacker has to do. For an analogy, a somewhat-related issue is that of salting passwords. Typically one stores the salt in the database in clear text, and this tends to freak people out. Doesn't that make it easier for an attacker to brute force your passwords? Well, yes, but the salt isn't meant to stop a brute force attack. It's meant to stop rainbow table attacks. The way you stop brute force attacks is to use an algorithm with a variable number of rounds that can slow itself down (see: bcrypt). Hiding the salt would just be security through obscurity. You always assume that the attacker knows the details of your algorithm, including the constants. So while hiding the salt would make it a tiny bit harder to brute force, we ignore it in favor of the thing that makes it exponentially harder (variable rounds). Similarly, putting port knocking in front of OpenVPN is like putting a padlock on the bank vault. If someone is going to break OpenVPN, port knocking ain't gonna stop them. > It is exactly the kind of attacks for which one usually uses iptables. > You are right, iptables is just one extra step of security, so the > worst thing which can happen is that this step is useless. > However, if you are willing to risk this only because of your own > lazyness in scripting then why do you setup iptables in the first place? > All of my iptables scripts, even the big ones, run in under a second and get executed 2 or 3 times a year. There's some saying about a baby and bath water. It's not laziness I'm advocating, just simplicity. Simple, understandable code is more likely to be correct than clever code. And in this case, incorrect iptables code is more of a threat than the tiny race condition.
