Port Knocking in Action

tyldis writes "There was something called "port knocking" mentioned on Slashdot earlier, and now an implementation has sprung to life. Is this something worth pursuing?" The page is to an application called knockd which is a simple proof of concept with hard coded knock sequences. Really interesting stuff.

Comments

Knock Knock?

[qualico]

Who's there?

Just a bunch of hackers knocking with sequences they captured from sniffing.

Re:Knock Knock?

[timeOday]

Not unless they can get into a router on the path between you and someone valid who logged in, or the same ethernet segment.

Re:Knock Knock?

[Anonymous Coward]

Encrypted port knocking is pointless. Here's why: Port knocking only makes sense if the protected system reacts to the individual knocks as if there was no port knocking system. Only when the knock sequence has been completed it opens the port. This means that you can't do any handshaking. All communication is one-way until it's "too late". Consequentially, since there is no challenge which could require a different response, replay attacks are unavoidable unless you use one-time passwords and then there's no point in encrypting the passwords.

If you decide to send a challenge to the knocker, you could just as well use regular authentication over a TCP channel.

The point of port knocking is to hide the existence of a regular channel, not to protect it from someone who knows that it's there. Someone who can sniff your packets is by definition already past that layer of protection, so any attempt to complicate the knock-layer will only increase the chance of creating another vulnerable interface. Keep it simple or don't do it.

Re:Great for warez...

[caluml]

I fear the ISP might just watch for large amounts of data spewing out on tcp/20.

Another implementation

[frobisch]

is pasmal

Re:Multiple kocks

[aWalrus]

Well, the knocks do come from the same IP, so this thing just needs to be able to see that to filter different knock sequences, I guess.

Port Knocking implementations

[bwhaley]

Lots of info available via a google search...

A few implementations here.

I don't think will be very useful/valuable until clients (such as ssh) have it built in. I don't feel like going through the hassle each time I want to connect. Though it would keep comcast from discovering my ssh service...

About as secure as telnet(1) ie not.

[Dr. Zowie]

The problem here is that the ``password'' (the port knock sequence) is sent in plaintext. Anyone with a sniffer anywhere between you and the other machine can see what you're doing. If this ever catches on, any L337 |1dd13 with half a rootkit will be sniffing for anomalous port-requests, and you'll be just as hosed as if you logged on via telnetd.

portknocking.org

[trip23]

You'll find some more stuff on http://www.portknocking.org...

Re:Multiple kocks

[JPriest]

The nimrod that modded this as insightful need to go back and read TCP/IP for dummies. They knock from different IP addresses, and even in situations where 2 hosts are knocking from the same IP (behind NAT) you still have a different source port.

Re:authpf?

[debrain]

The usable alphabet for a suicide TCP packet header is, I do believe, in bits:
16: dest. port
16: src port
32: seq id
6: flags
16: window
16: urgent
40: options
That gives us an alphabet 2^142 ~= 5.6 * 10^42. Not to mention that a sequence of packets can be combined, extending the language. Indeed, its cardinality is a natural ordinal, so the same as any password, if not more, by virtue of passwords being limited by an input buffer.

Knocking need only finite state between packets, simply indicating a status of "last packet correct knock?"; successive knocking therein is in a cardinality greater than passwords. Knocking can happen over a period of months (as I have seen it), and be virtually undetectable for all but the most sophisticted (ie. expensive) means of detection.

In combination with a time-synchronized one-time pad, you can generate an unrepeatable, provably (in the mathematical sense) secure system of access or commands. For example, for the minute of 13:01 EST, there can be a specific TCP packet, or series of packets that unlocks the door or executes a command. At no other predictable time would this knock be useful. (Time synchronization here is an issue, but often this attack will be used on machines that do care about an atomic clock sync).

You can do the same thing with a password over SSH, but that's higher level, using more complex code, and inherently more likely to succumb to high-level assaults such as buffer overflows, as well as mathematical assaults on the encryption itself, both of which fundamentally compromise the system's security.

In short, time-synchronized knocking is safer, simpler, and smarter than passwords or encryption for a certain number of niche applications.

A different solution

[Pros_n_Cons]

there is another similar idea written by Brian Hatch author of Hacking Linux Exposed. Instead of 'knocking' ports which as I understand it can be vulnerable to brute force like attacks Hatch's solution uses dns queries to dynamicly open up ports through the firewall, using the dns query as a password. There is no 'service' listening but there is a sniffer waiting for a key string on port 53 that it will take action on. The best thing is it is OS agnostic since DNS query tools are already on all OS's no client software, or technical know-how is needed. And easily customizable if you're fluent in perl.
These kind of things are not ment for full access, only by allowing you access to the daemon which still has its own acl. When you travel sometimes you're not aware of what IP address your laptop will have so you set a dns query to your home machine which opens the SSH port for you. The whole point is to prevent random attacks from people scanning vulnerable daemons. The following are links to Brian Hatches explinations and code.

Part 1
Part 2
Part 2

port knocking with perl

[ubiquitin]

My friend Thom Harrison at the Omaha Linux Users Group has posted some scripts which do port knocking and have the following CPAN dependencies:

|use File::Tail;
|use Crypt::CBC;
|use Schedule::At;
|use Math::VecStat qw(sum);
|use POSIX qw(strftime);
|use Pod::Usage;

Re:Sniffing only works when on that network.

[MerlynEmrys67]

I remember when:

Seems my office was 2 miles down the road from my house - traceroute from my house in Portland, OR to my office went through both Seattle AND MAE-West (Bay Area, CA)

Many external countries only have external connections to the USA, not directly to each other (don't know how true this currently is - but several asian countries used to have to hit the W Coast, USA to get between each other)

try doorman.sourceforge.net

[F.Z.Bunny]

For portknocking, try doorman.sourceforge.net Got crypto.

Re:Port Knocking Needed

[kir]

Worms port knocking? That would be one very very very slow moving worm!

Remember. There are 65535 different ports available. So, given that you can repeat port numbers and one uses a 4 port "combination", you get this.

65535^4 = 18,445,618,199,572,250,625 different "combinations"

I'm not even sure how to read that, but I doubt a worm would try it. It might take it a while.

Order and Delivery Of Packets Is Not Guaranteed!

[Dr. Manhattan]

Packets are not guaranteed to arrive in the order that they were sent, or even to arrive at all. The longer or more complex the knock sequence, the more unreliable this system will be. Especially for a busy server.

There are less stealthy but more secure alternatives. I wrote one.

Parent is wrong

[Ernesto Alvarez]

Encrypted port knocking is pointless. Here's why: Port knocking only makes sense if the protected system reacts to the individual knocks as if there was no port knocking system. Only when the knock sequence has been completed it opens the port. This means that you can't do any handshaking. All communication is one-way until it's "too late".

The idea in the grandparent post wasn't a challenge-response in the traditional way. It was some authentication data along with the knocking.
The knock won't be encrypted, but it will have some data that is characteristic of the source (the source IP) that can't be spoofed (because of the password and the one way hash).

An example of this would be:

1.Real owner takes his IP (public info)
2.Real owner takes his secret password (known only to him)
3.Using IP and password he computes the hash and sends it in the knocking packets (let's say it's in the IP id)
4.The receiving system captures the knocking packets and takes IP source and the hash
5.It reads the secret password (from config file)
6.It calculates the hash with the source IP and password

If the hash sent and the hash calculated match, the system "accepts" that part of the port knocking. If not, discards the packet.

An intruder might only spoof the whole packet (including IP source) and might open the firewall only for that IP. If he tries to use the hash to open it for HIS ip, the calculated hash won't match the hash sent. He cannot calculate the hash he would need because he does not know the password, and the hash is one way.

In this protocol the target system does not need to respond with a challenge, it just discards packets that are "spoofed" (that have a non matching hash).

Re:one of many

[Anonymous Coward]

Why not just mod me up instead? I provide links!