Slashdot Mirror
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.
Who's there?
Just a bunch of hackers knocking with sequences they captured from sniffing.
I fear the ISP might just watch for large amounts of data spewing out on tcp/20.
Get your own free personal location tracker
In QBASIC:
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
2093, 1568, 1568, 880, 988, 1568, the frequency of the pitch of the notes.
is pasmal
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.
Overcaffeinated. Angry geeks.
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...
"I either want less corruption, or more chance
to participate in it." -- Ashleigh Brilliant
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.
You'll find some more stuff on http://www.portknocking.org...
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.
That would be a benefit. Those using port-knocking for extra security are misguided, though.
The meme police, They live inside of my head
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.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
Can you tell I don't post to blogs much? Port Knocking
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.
> This is an interesting idea, but not very secure. If there was,
> 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?
www.portknocking.org
Note the encryption/hash of the ports, source IP, and port to be opened.
www.portknocking.org/view/documentation
There is a Perl reference implementation. (GPL'd, of course)
"I am in no way affiliated with this group."
I may be wrong, but I was under the impression that all knocked ports were closed and a cron job watched logs, and then opened a port if it noticed the correct knock. This is great for linux, were things are logged, but does windows have a loging facility of this kind? If not, the ports must be open for a program to know if someone has tried to connnect, which defeats the point. With most trojans being on windows, it seems that this isn't a viable feature to add.
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.
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
-- "of course thats just my opinion, I could be wrong." --Dennis Miller
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;
http://tinyurl.com/4ny52
As I understand it, the ports do not have to be open. You can listen on the link-level and monitor incoming packets even if the port is closed.
At least, this is how the implementation this article mentions does it (or advertises it does). I've yet to thumb through the code.
Because UDP is usually bandwidth filtered as it's the easiest protocol to flood a connection.
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.
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)
I have mod points and I am not afraid to use them
For portknocking, try doorman.sourceforge.net Got crypto.
--- There is no bun but Bun, and Fuzzy is His prophet! Bunbun akbar! ---
This is only implementing basic static knock sequences, but it could (and likely will) be further developed to support cryptographic knocks that are embedded with other data, such as which port to open.
The guy at portknocking.org has a good example of how to do this.
check it out
"This port need not be open -- since knockd listens at the link-layer level, it sees all traffic even if it's destined for a closed port." This is from the page of the implementation this article is about.
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.
You are quite correct, ports are not used at the link level, however once the packet is received by the adapter it is processed by a software stack.
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.
If VISTA is the answer, you didn't understand the question
Incorrect.
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?
I would expect such blatant racism on Fark, but on Slashdot? Mods please ban this asshole.
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.
3cx.org - A truly bad website.
There are less stealthy but more secure alternatives. I wrote one.
PHEM - party like it's 1997-2003!
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).
GPG 0x1B479C78
I think that ISPs could simply then start looking for seemingly random port probes by machine A on machine B, followed by machine B spewing gobs of data to machine A on a random port. That's the trick, make your protocol too good and it'll stand out because it's too random. If you ever actually talk to anyone who works at ISPs though, they generally just flag those customers with unbelievable upload/download ratios and then have a human look at their logs to see if they're violating the TOS (running a server, hosting warez, whatever).
Why not just mod me up instead? I provide links!