Port Knocking in Action 430
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.
Knock Knock? (Score:4, Informative)
Just a bunch of hackers knocking with sequences they captured from sniffing.
Re:Great for warez... (Score:5, Informative)
Re:How do you transcribe... (Score:3, Informative)
s$ = "shave and a haircut"
FOR i = 1 TO LEN(s$) STEP 2
IF i LEN(s$) THEN
PRINT ASC(MID$(s$, i, 1)) * 256 + ASC(MID$(s$, i + 1, 1))
ELSE
PRINT ASC(MID$(s$, i, 1))
END IF
NEXT
Output:
29544, 24950, 25888, 24942, 25632, 24864, 26721, 26994, 25461, 29544, 24950, 25888, 24942, 25632, 24864, 26721, 26994, 25461, 29544, 24950, 25888, 24942, 25632, 24864, 26721, 26994, 25461, 116
Re:How do you transcribe... (Score:2, Informative)
Another implementation (Score:5, Informative)
Re:Multiple kocks (Score:4, Informative)
Port Knocking implementations (Score:5, Informative)
A few implementations [portknocking.org] 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. (Score:3, Informative)
portknocking.org (Score:5, Informative)
no (Score:1, Informative)
No, the knock-sequence itself is no more secure than a plaintext password. So using it for access to ssh is no more secure than simply using ssh alone.
Re:Knock Knock? (Score:5, Informative)
Re:no (Score:1, Informative)
Re:ISP Port-Scanning (Score:2, Informative)
Re:Multiple kocks (Score:3, Informative)
Sorry Wrong URL (Score:2, Informative)
Slightly Better Crypto (Score:1, Informative)
Generate a knock sequence that includes (a) some random data and (b) the same random data, but encrypted by a key that only you have.
Have knockd decrypt the encrypted part and make sure it's the same as the random data.
Have knockd keep track of what random data has been used, to prevent replay attacks.
Highly unlikely you'll generate the same random data twice. But an eavesdropper cannot replay your key, and cannot generate random knock sequences either.
You could also set up error-correction in case somebody blocks one of the ports you're using for knocking.
Re:knock-knock (Score:1, Informative)
> for example, a need to "knock" a server to activate some sort
>of access control, then anyone can send the TCP/UPD packets
>(AFAIK) someone correct me if i'm wrong.
It's another layer of protection and is easy to implement. E.g. port scans wouldn't show up the port. Once you've knocked there is still the next level of authentication to get through (SSH key exchange, password etc.)
>Looks interesting though, but inetd could do the same thing.
inetd acts at the application layer. knockd is down at the link layer ( according the the man page, surely at the TCP level so it can get port numbers?). Regardless, inetd does a different job.
Mods, if you don't understand something, how about not modding it up?
Implementation which is sniff resistant (Score:2, Informative)
Note the encryption/hash of the ports, source IP, and port to be opened.
www.portknocking.org/view/documentation [portknocking.org]
There is a Perl reference implementation. (GPL'd, of course)
"I am in no way affiliated with this group."
Re:how long till... (Score:2, Informative)
Re:authpf? (Score:5, Informative)
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.
Re:Knock Knock? (Score:4, Informative)
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.
A different solution (Score:5, Informative)
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 [hackinglinuxexposed.com]
Part 2 [hackinglinuxexposed.com]
Part 2 [hackinglinuxexposed.com]
port knocking with perl (Score:5, Informative)
|use File::Tail;
|use Crypt::CBC;
|use Schedule::At;
|use Math::VecStat qw(sum);
|use POSIX qw(strftime);
|use Pod::Usage;
Re:how long till... (Score:3, Informative)
At least, this is how the implementation this article mentions does it (or advertises it does). I've yet to thumb through the code.
Re:Why is this more secure... (Score:3, Informative)
Ethernet has a exponential-wait scheme to prevent cloging of pipes, and TCP uses a authorized sent only packet. No data is send until prior ones are OK'ed.
Re:Sniffing only works when on that network. (Score:4, Informative)
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 (Score:3, Informative)
crypto and dynamic knocks (Score:1, Informative)
The guy at portknocking.org has a good example of how to do this.
check it out [portknocking.org]
Re:how long till... (Score:3, Informative)
Also, the first sentence from portknocking.org: "Port knocking is a method of establishing a connection to a networked computer that has no open ports." A little further down on the page: "This is a form of IP over closed ports."
Also, you may wish to read the FAQ: http://www.portknocking.org/view/faq [portknocking.org].
Re:how long till... (Score:3, Informative)
There are several products that implement similar concepts. Take a look at bridging firewalls. Neither interface on the bridge has an IP address but can still inspect packets and take action as required.
Re:Great for warez... (Score:3, Informative)
You connect first to the server, it then queries your machine on 113 to see if you are who you say you are and let you in(or not).
How is a server supposed to know to ident you if the ftp port isn't open first?
Re:Port Knocking Needed (Score:4, Informative)
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! (Score:5, Informative)
There are less stealthy but more secure alternatives. I wrote one [homeunix.org].
Parent is wrong (Score:5, Informative)
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:Great for warez... (Score:3, Informative)
Re:one of many (Score:5, Informative)