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.
There are actually about 5 other known port knocking implementations. And it's such an easy thing to do, I'm sure many others have written their own private implemenations.
"shave and a haircut" into port numbers?
"Prefiero morir de pie que vivir siempre arrodillado!"
You can keep on knockin' but ya can't come in
So how do we map musical notes to port numbers?
I want to get "shave and a haircut" ported over to the new protocol.
"Trademarks are the heraldry of the new feudalism."
I can see this being used quite extensively in the warez arena. It'd be pretty easy to give out the "key" to clients who are allowed access, while any ISP scanning for FTP servers, for example, would find nothing open.
dmiessler.com -- grep understanding knowledge
Who's there?
Just a bunch of hackers knocking with sequences they captured from sniffing.
I wonder though. If port knocking is to become popular, will it be able to work through all of the blocked ports resulting from the excessive worm attacks?
pfft, XP has had this for ages....
This might be useful when ISPs routinely port-scan their subscribers to discover if their running services in violation of their TOS.
This will allow your computer to appear not to be running services expect to the person who knows the magic knock.
I'm betting that nmap binary is about to get much bigger...
The port knocking idea is pretty old.. at least for months now all kinds of people are knocking my 135 1433 3127 and a bunch of others to DEATH, like hundreds a day, trying to get in..
Oops, that's Microsoft port knocking.. never mind, sorry, I guess it is new to Unix..
Who's there?
Packet.
Packet who?
Packet up bitch, you've been hacked.
till we see virus/worms that install port knocked backdoors.
'virus x appears to open up 200 ports for no real reason, but it also has some remote desktop code in there too opened on a firewalled port....'
Why use port knocking. It is no more secure than plain-text passwords. Use authpf. authpf can be set as the shell so when a user logs in authpf just changes the firewall rules.
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.
Looks interesting though, but inetd could do the same thing.
is pasmal
That's a nice start.
It would be nice to be able to use one-time pad to generate the port sequence. By changing constantly, it would be almost impossible for passive listeners to snif the port sequence.
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.
This sort of clandestine type of communication has been known about in the security community for a long time - pretty much since the ARPA days. Some backdoors used specific sequences of TCP flags, with no practical TCP use other than opening a backdoor, but permitting anonymous communication or command broadcasting.
With access to a TCP stack and a link-layer sniffer, you can send and receive, respectively, commands to ghosts in working machines, transparent proxies or "harmony" devices. It is good to see this sort of thing coming to light, since it is extraordinarily powerful and not very well known.
An example of these probing commands are Xmas, Fin, and Null scans for Fyodor's nmap; note that other TCP flags (TCP options, in particular) can harbour substantially more information than the flags alone.
Unfortunately, in the modern age of macro viruses, it is hardly necessary to be skilled or even aware of such devices to write a devastatingly powerful virus.
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.
Than a single coded UDP packet?
You'll find some more stuff on http://www.portknocking.org...
I remember talking about port knocking and its inherent sniffing vulnerability previously.
;) I'm currently implementing a c++ networking class for a project with port-knocking built in, and it uses the timestamp method. (Of course, they all have to compute the timestamp for one zone, GMT or wherever)
Basically, if someone can sniff the sequence of packets, they can get your static knock sequence.
However, if you base it on their IP perhaps, or add in a timestamp (ie, on this date, at this time, you must do this sequence) then it would make port knocking a much more effective method of deceiving attackers.
You could also do something where knock sequence would be a form of one time password. So you would have a list of valid knocks that could only be used in order. Each person could be given a "block" of these one time passes, or the sequences could be generated on the fly as other current implementations of one time keys are.
There are lots of great possibilities, if only I were smart enough to think of them
"Sed Quis Custodiet Ipsos Custodes?" -Juvenal
You can only sniff packets on a network you are attached to.
What that means in real life is that someone would have to be connected somewhere along the route from your machine to the server you're knocking on.
I am in Seattle, I can knock on my server from another location in Seattle. Someone in Canada will not be able to capture any of my packets.
Port knocking allows me to run a service on the Internet and not worry about just anyone from anywhere connecting to it.
If I understand it correctly, this could be very secure. Imagine trying to guess the combination of a combination lock where each port number represents a possible number of the combination, and the combination is of unknown length (e.g., a combination 3, 5, 45, or 105 numerals long, etc.). Moreover, it might be possible to have the system bar further attempts from a given IP address after two or three failed attempts during a given period of time.
Only Women Bleed (Sex, Sharia remix)
Do you type:
>/etc/rc.d/rc3.d/s95Knock UP
?
I'd just scp'd a new file to my ISP, ssh'd in to edit index.html, checked email, and then when I refreshed the page in http, suddenly I has root access!
try { do() || do_not(); } catch (JediException err) { yoda(err); }
I knock, knock, knocked on that Gibson's door!
Game Overdrive - Gaming News
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
Sniffing the sequence allows a replay attack.
The correct implementation is to listen in promiscuous mode for any packet containing a small, known header, then inspect the rest of the packet for a gpg-signed request to open a port or service, or alternately initiate a connection. Only the possessor of the private key can make a request (attacker's attempts fail the signature check), a man in the middle cannot decrypt the contents, and replay attacks are defeated by the timestamp.
-1, Security by Obscurity.
If you are using portknocking as your only defense, then you are as smart as dirt and deserve what's coming to you.
I think it fits in great as a layer of defense.
Is there an easier way to weed out the attempts from all of those script kiddies and worms to get into certain services on your network?
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."
Well, then there is no such thing as security.
Your 10000000 bit PKI key is just a secret. If you are relying on not giving that secret out to handle your security, then you don't have any. Its just a secret, I guess I am better off not using encryption
The arrangement of pins in my doorknob is a secret. I guess I am better off not locking my doors.
The password to log into my workstation is just a secret. I should just leave it open.
The more "secrets" you have in any given situation, the better secured you are.
Random portscans where they get all your secrets wrong : could be random noise.
Random portscans where they get 2/3 of your secrets right : You have probably identified an active intrusion attempt. Also you have identified a possible leak in your secrets. Time to change the passwords.
A number of people have commented that because the port knocking sequence is transmitted without any form of encryption, port knocking is insecure. I disagree, on the basis that port knocking is not an access control measure, but rather a deterrent measure.
If you intend for port knocking to stop determined, targeted attacks, then yes, you are sadly mistaken. However, port knocking is effective in making your host less attractive to be hacked.
I think that an limited analogy is the removable stereo faceplate. Car stereos are a hot target for car thieves. A car thief sweeping a parking lot will not spend time on cars where he does not see the whole stereo (faceplate included).
By hiding the faceplate, you make yourself less likely to be a victim, even if you just leave the faceplate in your glovebox. If the thief saw where you hid your faceplate, then yes, he could pop it back in and have your stereo in the 30 seconds it takes him to yank it out. But he would have to be watching you. This would be akin to packet sniffing.
Likewise, someone scanning for a host is looking for evidence of a particular (vulnerable) service. If he doesn't see that service on your PC, he just moves along.
It looks as if you don't grasp the concept here. No one requires the knocking sequence to be static. Only the knockd as a proof-of-concept implementation uses a static sequence to keep the program simple and point out what Knocking adds to the normal server concepts. Authentifying yourself against a server with a nonstatic sequence is not a new concept in this context, so it was not focussed on during knockd's implementation.
:)
No one will stop you to implement an adv_knockd which requires the knocking sequence to be the current time in GMT, signed with your private key. Then your adv_knockd checks your signature with your public key and verifies the timestamp.
This makes your adv_knockd invulnerable against replay attacks, if you declare an sequence already sent to be invalid for the next hour (you have to allow for a grace period in the timestamp, because of network delays and asynchronous clocks, so a replay of an already sent sequence within a few seconds would still come through).
The knockd is explicitly called a proof-of-concept. Using it directly as part of your security policy is strongly disencouraged
Secrets are not security. Give me your pin code.
"It's too bad that stupidity isn't painful." - Anton LaVey
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
Well at least I used to build them in. It was so simple many others must have done the same thing. Take a 10-step relay, put a 1 minute reset timer on it, and wire each of the first few steps to a pulse gen anded with one of the incoming lines' ring detect. If the right sequence of incoming calls happened, it connected a separate incoming WATS line to a WATS outgoing line. Viola! Free calls from anywhere to anywhere, and nobody would ever notice if you were careful to only select "unlimited" outgoing WATS lines. We're talking something like 35 years ago here...
The use of port knocking should be as a deception device, not necessarily as an active defense.
You are hiding the fact that you have something to hide, ala steganography. Once that something is found (the knock sequence), it is open to attack just like anything else.
Stego + encryption is the way to go. Not necessarily for this application (port knocking), but it could have some great security uses.
So with port knocking, you still want that encrypted channel to be required (SSH, etc.) on the port that you successfully knock to.
"Sed Quis Custodiet Ipsos Custodes?" -Juvenal
Most of the arguments here against port knocking are along the lines of "but someone could just do a replay attack" or "this is vulnerable to spoofing" or whatever. These things are true about a naive implmentation of port knocking that uses a static knock, but it's not hard to come up with variants on the port knocking idea that offer much better security than that. For instance:
The secret key of course has to be kept secret, and the underlying crypto must be good enough that if the attacker sees the challenge and the knock sequence used to reply, the key itself cannot be deduced.
This would completely protect from replay attacks, as knocks are not reused. Spoofing could potentially be used to DOS someone by interfering with their knock sequence, but not to gain unauthorized access oneself.
Sure, at first glance port knocking may seem to be of limited usefulness, but if you combine the idea with a little cryptographic thinking, the possibilities start to become a lot more exciting.
One of the cool things with this is that you could set it so that it actually starts SSH or the FTP daemon or whatever as well as open up the firewall on the appropriate port and shut it down again after.
Saves mem usage as well as being that teensy bit more secure!
Also in answer to post further up - WinXP's firewall can log dropped packets to a text file.
bagging secret methods of keeping things secure. well i'm sorry kids but ultimately keeping something secret is necassary for a secure system. what is NOT secure is keeping that secret in an accessable mode. good passwords are the most effective way of having a secret way into a system, since your brain isn't plugged into a computer it's only accessable to the correct person. port knocking sounds intresting, but it's like having a secret knock to let you in a physical door, anyone listening will know that secret knock.
If you mod me down, I will become more powerful than you can imagine....
For portknocking, try doorman.sourceforge.net Got crypto.
--- There is no bun but Bun, and Fuzzy is His prophet! Bunbun akbar! ---
Actually, as the CPU clock speeds up, port-
knocking may prove to be an ideal way to keep
the black-hats out of your network. Imagine
applications that don't maintain explicit
open ports, but only open up a port with the
right "shave-and-a-haircut" knock-knock. If
generic port scans can't find any holes, how
do the script-kiddies break in?
It's much less of a problem when DSL providers have policies like this, at least in the US, because usually the ex-monopoly telcos rent their copper to multiple DSL Layer 2 providers (often including themselves), and the DSL providers usually provide connectivity to many ISPs. So even if, for example, SBC DSL ISP service has some stupid policy, SBC provides Layer 2 access to many ISPs including Sonic.net and Speakeasy, who have friendly clueful policies, and they rent copper to Covad, who provide Layer 2 access to many more ISPs (sometimes with fewer connectivity options, e.g. maybe only SDSL or IDSL and not line-shared ADSL.) Sometimes these alternatives cost more - I'm paying about US$57/month for Sonic.net ADSL with four static IP addresses, vs. some of the newer loss-leader $29 deals from other providers.
Most other countries don't seem to have policies against being a Real User on your broadband service, at least if you're not commercially reselling it. Theoretically, this means that all those non-Americans out there should be creating lots of cool and interesting things to do with their broadband services, but I haven't seen much other than Yet Another File-Sharing System variants or some of the Asian grocery-shopping-on-line things that get magazine articles written about them but aren't very useful outside their local areas.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
There are some tradeoffs - knocking systems are usually lightweight, while authpf is probably more thorough, especially about making sure the firewall hole gets closed when you leave. Different knocking systems have different bugs in them, and OpenBSD+SSH+AuthPF has the risks of more people attacking it, but the knocking systems have random authors while Authpf and its environment have to be blessed by Theo, so you've got some level of assurance about QA and future fixes. Also, knocking systems need various clients to knock with, and may be susceptible to firewall damage in between, while SSH is pretty widespread and firewalls generally let you make outgoing SSH connections.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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 haven't looked at the way this is implemented (in true Slashdot fashion), but here's what I would do:
From client:
Send a random number, say [1-10] of port knocks, toward random ports.
Send the true port knock sequence, this has to complete before a certain time has elapsed.
Send a random number of port knocks again.
Wait a second or two, then connect to the real port.
Now, the server side waits for the first correct port and hence ignores you random garbage. Once your first port comes through it waits for a short duration (3 sec?) for the second port knock. If that comes across OK it waits for the next etc.
A wrong port from the same IP or a timeout causes the entire knock attempt to fail and get logged.
Once the correct sequence is sent, there is a random delay of a few seconds before the real port (e.g. SSH) is opened so sniffers can't tell exactly when the sequence started and ended within the total port knocks sent.
Now you are logged in, and since you are connected via some form of encryption (again, SSH or whatever) you are free to change the port knock sequence. Perhaps even done automatically every successful login, with a logged failback to previous sequence if you get out of sync.
Unless you log in to the opened port within 30 secs it closes and you have to wait 90 secs to send the sequence again.
You could additionally add individual sequences for static IPs (or even DynDNS?) or even certain individual logins allowed to authenticate after that sequence was received. I expect netfilter modules to be written to handle all of this.
By the way, anyone who thinks an open SSH port is *safer* than port knocking + SSH is an idiot in my opinion. The first discussions here were full of such comments, they seem to have died off as people decided to RTFA?
Still, port knocking is not the best option for frequent connects by many users, and can be DOS'ed with IP spoofing or some kind of packet injection.
What is the sound of one hand clapping?
cat
Compare this to real life. You have a stack of porn magazines locked in a drawer. The security is the lock, preventing your mother from ever getting access to the porn. That's fine. But surely you would feel much better if your mother didn't even know there was porn in the drawer! That's obscurity. It doesn't make the lock any more secure, but it is useful.