said by Name Game :

You did not add a security layer..you just look for one to protect a port I keep closed.

said by Daniel :

I think you missed the point; we're talking about people who 1) have a need to run the daemon, and 2) require connections from a dynamic range of source addresses.

So how do you propose to allow only certain people to come to your gate (they still have to login), while presenting a completely firewalled appearance to the rest of the world?

If this isn't "real" security, what do you propose as an alternative? And don't mention anything involving SSH itself, because that's already being done. BEYOND SSH itself.

said by Name Game :

The alternatives are not available for discussion in this forum.

So how do you propose to allow only certain people to come to your gate (they still have to login), while presenting a completely firewalled appearance to the rest of the world?

said by nwrickert :

I think you have made the point very well. This is all about appearances, rather than about real security.

You misunderstand; I do think it offers real security.

said by nwrickert :

I do understand that you think it provides real security.

I am thinking about this in terms of the servers I manage. Suppose I set up portknocking for SSH.

Option 1: I publish the sequence of magic port knocks. There goes any added security down the drain.

Option 2: I build a client that knows the sequence of magic port knocks. That's tantamount to publishing, so see option 1.

Option 3: I have to manually weave my way through this maze every time I need to use SSH. There goes my security. I have made it too inconvenient to push security updates to each of the servers. So I don't update them. The security risk of this is greater than the imagined risk of a possible zero-day ssh exploit showing up. Also, I probably stop monitoring my servers from home, because I have made it too inconvenient to login to them. The loss of monitoring is another increased security risk.

said by nwrickert :

Option 1: I publish the sequence of magic port knocks. There goes any added security down the drain.

said by nwrickert :

Option 2: I build a client that knows the sequence of magic port knocks. That's tantamount to publishing, so see option 1.

said by nwrickert :

Option 3: I have to manually weave my way through this maze every time I need to use SSH. There goes my security. I have made it too inconvenient to push security updates to each of the servers. So I don't update them. The security risk of this is greater than the imagined risk of a possible zero-day ssh exploit showing up. Also, I probably stop monitoring my servers from home, because I have made it too inconvenient to login to them. The loss of monitoring is another increased security risk.

said by nwrickert :

And that of course is part of the "KEY" Daniel can not understand..unattended access..additional third party apps installed insdie to make it all happen..and you trust the code to work as advertised...Then you force the rest of your security to allow it to happen.

said by nwrickert :

Option 1: I publish the sequence of magic port knocks. There goes any added security down the drain.

Option 2: I build a client that knows the sequence of magic port knocks. That's tantamount to publishing, so see option 1.

1. How do you think this small group of guys in charge of doing the SSH scans (maybe one or two guys) are going to somehow magically procure the cryptographic knock sequence that's on the laptops of your engineers?

said by nwrickert :

They already have a copy of the SSH client that does this, because they have trojanized one or more of those laptops and installed a keylogger.

I see, so any security layer that can be defeated by having full root access via trojaned system fails to be called a security layer?

Your argument says that police shouldn't wear bullet proof vests because someone was rumored to have an anti-tank weapon in town.

It can also be defeated if the engineer becomes insane and starts posting the username, password, and knocking sequence hundreds of hacker IRC channels.

When you add a layer (whether security or obscurity), you have to consider the possibility that people will set up ways of bypassing it, with the result that your security might actually be worse.

If you have 5 layers of protection, and you add an additional layer on top of it, how many do you have?

said by nwrickert :

Well, okay. If you have to accuse those who disagree of being unable to count, then I'll take that as evidence that you don't have much in the way of good arguments.

The French added an extra layer of security, to ensure that they could not be invaded by Germany. That extra layer was known as the Maginot line. As history demonstrates, it isn't as simple as just counting layers.

The fact that you're comparing portknocking with a line of uni-directional, non-mobile gun turrets (while the enemy has airborne troops) is illustrative of the fact that I've been wasting my time. But just for the sake of argument I'll show you why that's a horrible analogy.

said by nwrickert :

You are aiming your "guns" at direct attacks from the network, when the major risk is from clever use of social engineering techniques.

said by EGeezer :

Based on what I've read here, it appears that portknocking can be a useful part of an SSH implementation. While there were several general non-technical analogies presented, none seemed to address the methods a hacker might use to discover and obtain the port knocking sequence in a public network.

I was hoping to see an answer to the scenario I referenced in my earlier post, but that appears not to be forthcoming. Perhaps there is no practical way.

One question, though - how would one build an IP table for the IP authorization if the clients are road warriors using DHCP? Seems that option would not be useful in that case.

... I was thinking more along the lines of a port being accessible by everyone whenever a single user entered the correct port sequence for access. Obviously I forgot that iptables can allow access to ports on a per IP address after a port knocking sequence. Hence, my previous questions do not apply. So it's possible to have thousands of users access a service remotely, but no indication to others that a remote service is listening on a certain port.

Based on what I've read here, it appears that portknocking can be a useful part of an SSH implementation.

Moreover, it would work behind a NAT router, where I would only have to forward that one udp port instead of all of the ports that would be needed for port knocking.

said by Daniel :

Holy God. You mean you've been arguing all this time against it and you don't even know how it works?

Portknocking only opens ONE (1) port, e.g. 22 for SSH.

So, yeah...it's just one port, man. Does this change anything for you?

whose rules can be dynamically modified.

Does this help?

However, most inexpensive broadband routers are not suitable. So this is mostly a geek technique, particularly for those enthralled by the gee-whiz nature of the methodology.

So if a security layer doesn't work on "inexpensive broadband routers" then it's essentially a toy technology?

said by nwrickert :

However, most inexpensive broadband routers are not suitable. So this is mostly a geek technique, particularly for those enthralled by the gee-whiz nature of the methodology.

said by nwrickert :

But why port knocking?

Couldn't you achieve the same thing with a udp listener that can open the firewall for a particular connection in response to an encrypted and digitally signed udp packet? It seems to me that this would be more effective and simpler to implement. Moreover, it would work behind a NAT router, where I would only have to forward that one udp port instead of all of the ports that would be needed for port knocking.

said by Sebastien Jeanquier :

"In broad terms, port knocking is a method for transmitting information across closed ports, with the aim of authenticating users before allowing them, and only them, to access a protected service.."

said by Sebastien Jeanquier :

The knock daemon has the ability to read knocks out of the firewall log, or directly off of the wire using libpcap. Due to the way that this implementation deals directly with the bit-representation of the knocked ports, it would be quite difficult to compromise the daemon itself with maliciously crafted packets.

If we're trying to address the problem of millions of people having access to your SSH daemon, the way to counter that is with a network-based control.

Millions of people do have access to my SSH daemon. So far that hasn't been a problem.