Can someone point me in the right direction in the area of port knocking and setting it up correctly through a secure method such as an ssh tunnel and if it cannot be done via a tunnel that can you suggest the more appropriate way to do so?

Amazing what a little research can produce!

http://www.linuxplanet.com/linuxplan...orials/6458/1/

http://www.portknocking.org/

Hey thanks for posting your findings. I had never heard of port knocking until your post, it looks like a very cool trick to keeping your system secure.

Well, it doesn’t keep your system any more secure than a plaintext password (i.e., whoever can sniff your connection for a plaintext password can sniff your connection for your port knocking sequence).

A more accurate statement would be: it’s a cool trick to minimize detection by script kiddies.

Why give portknocking a bad rap?

First, it totally stops access to ports that people should not have access to, without needing to have blanket firewall rules (open this port to everyone, allow ONLY this IP, etc.). You can portknock from any machine and only that IP gets access without any pre-knowledge on the server of what IP it's going to be, while at the same time denying every other IP. It's great for remote-access work.

Second, portknocks are not just "1,2,3, I'm in" any more (haven't been for a long time). They can be encrypted, time-dependent, IP-dependent, non-replayable etc. and so just as secure as other methods. Tiny shell scripts are capable of performing even the most complicated portknocks remotely, so they add little extra burden to a remote admins toolkit.

Third, they instantaneously block log-spam for things like SSH servers (I highly recommend them over things like fail2ban because that only works AFTER someone has already tried to get in). You just block port 22 and only open it via portknocks when you or your SSH users are remote. That way access is only given to the SSH port for those who already know the portknock (note that the better portknocks are no longer replayable, so sniffing is pointless). This also buys you a little more safety and time in the event of an SSH compromise or vulnerability.

Similarly, the above benefits are for ALL protocols, not just SSH.

And, of course, even after sniffing your portknock, breaking it's encryption, opening the port, you're still no less secure than you were before.

From personal experience, deployment of even the simplest of portknocks on an Internet-connected server instantaneously blocks all SSH attempts and the associated log-spam. Attackers bounce off a standard, well-tested TCP stack rather than your Apache or SSH daemon.

Even if someone could theoretically sniff all traffic to my server, the better portknocks will stop even that from working. And at the end of the day you can add an extra layer of "real" security (not some snakeoil like you seem to think port-knocking is) for NOTHING, not introduce vulnerabilities (portknock daemons tend to use well-established packet monitors like pcap on the server machine and are so simple as to be trivially auditable - you can literally do it yourself with a script that scrapes logs or interacts with pcap and the iptables command) and not lose out on any existing functionality or security.

Additionally, I have a (simple) portknock on my home machine. It does the same job. So someone sniffs a complete handshake? They still have to get into the machine. And all port-openings are logged, so I'd quickly noticed and change or upgrade the portknock. Nobody even TRIES. Occasionally "stage 1" of a four-stage knock is triggered accidentally by a port-scan of my IP but nobody's ever got to stage 2 because you have to get the numbers dead right first time or you get reset for a minute or two.

Trivial deployments are nothing more than a tiny, defeatable shield that still serves a practical purpose, like MAC-Filtering on a WLAN. "Real" deployments are like layering an impenetrable, uncompromisable barrier OVER your SSH port, which determines who can even access the SSH port, let alone send data to the daemon.

To just dismiss portknocks probably means you haven't used them properly or read up on them a long time ago and haven't updated your information.

I have to agree with Ledow in that an extra layer of security it better that none and little extra piece of amour will at the least keep out the script kiddies and make it that much harder for a cracking attempt. I was wondering if it affect performance of any kind?

No.

The portknock server process just analyses certain, specific traffic via a packet capture interface with a filter - it doesn't even read every packet that comes through your network card, just the ones that *could* be part of your knock sequence.

Portknock failures either bounce off your TCP stack (so you don't even see them). On a successful portknock, the server daemon runs iptables (or the programmatic equivalent) once to open a port or close it. That's it. The rest of the time it is idle, and only woken up when a particular packet arrives on your network port.

This is part of what makes it secure in itself, it only gets to handle a very, very small percentage of your network traffic and it does one or maybe two very simple port changes on a succesful hit. The processing involved is absolutely minimal.

If you're really interested, I'd suggest the following:

http://www.aldabaknocking.com/ for "strong" portknocking
http://www.zeroflux.org/cgi-bin/cvstrac.cgi/knock/wiki for "weak" portknocking.

Either is totally fine for home based system because installing even a "weak" system doesn't REDUCE your computers security, it just doesn't increase it by as much as it could.

If you want REALLY simple, it's actually quite simple to turn on firewall logging on Linux and parse the log with a script that, when it meets logged packets of certain ports at certain intervals, just runs iptables to open a port. It's not hard to do at all. That's the beauty.

My main reason for port knocking was that I like to have some ports open for myself remotely but I don't need them all the time. The software behind them is secure and up-to-date but if I can put them behind a layer of security which has minimal impct but that prevents logspam, script-kiddies, password-brute-forcing attempts etc. than I will. I now carry Putty and a portknock utility (You can also use a simple Windows batch file to do the same job) with me and nobody but me gets to see the port, let alone the software.

Additional advantages are, say you were doing this on a private Apache port, and Apache has a compromise, you have a lot more time to fix it... the average port scanner does not detect, know about, or try to circumvent port knocks - everything just appears as normal TCP closed ports. But you can still access it externally as you have the key.

I am not sure where this sentiment is coming from. I never dismissed portknocking nor did I give it a bad rap. In fact, I myself use portknocking to hide a few ssh servers. I had even written a minimal port-knocking daemon awhile ago.

All I said was that the previously-linked to instructions for implementing port-knocking were as effective as adding an extra layer of authentication with a plaintext password (and I stand by this statement). Such security is very useful in the case of 0-days and such. Likewise, I would say that encrypted port-knocking is as effective as adding an extra layer of authentication with an encrypted key or passphrase.

In my previous post, I was addressing someone who had just learned about portknocking, and I wanted to be very clear that it should not be used alone as a security solution. Instead, it should be thought of as a layer of security on an existing protocol (e.g., with SSH, first use key-based authentication, then put in port-knocking).

Lets get ready to "ruuuuuuuummmmmmmmmmmmbbbbbbbllllllllleeeeeeeeeeeeeee"

That would be silly to think it is a complete solution. I'm new to this site not computers. Not quite sure how you interpreted my original comment as saying it was a complete solution.