Slashdot Log In
Port Knocking in Action
Posted by
CmdrTaco
on Wed Apr 14, 2004 04:54 PM
from the crazy-security-through-obscurity dept.
from the crazy-security-through-obscurity dept.
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.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
How do you transcribe... (Score:5, Funny)
Re:How do you transcribe... (Score:5, Funny)
Parent
Re:How do you transcribe... (Score:5, Funny)
Parent
Knock Knock (Score:4, Funny)
Port to MIDI interface (Score:4, Funny)
I want to get "shave and a haircut" ported over to the new protocol.
Great for warez... (Score:5, Interesting)
Re:Great for warez... (Score:5, Informative)
Parent
Re:Great for warez... (Score:4, Interesting)
Parent
Knock Knock? (Score:4, Informative)
Just a bunch of hackers knocking with sequences they captured from sniffing.
Sniffing only works when on that network. (Score:5, Insightful)
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.
Parent
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)
Parent
Re:Knock Knock? (Score:5, Insightful)
Take the source IP, add a password, take a one way hash. Include this hash in the knocking packets.
Now, if you've sniffed the packets, then you won't know the password. So, you can spoof the source IP, in which case the port will be opened _for that IP only_, or you can send the knocking packets from you IP, in which case, you need that password, or you've just advertised yourself as a hacking attempt.
In order to prevent a single password for everyone situation, it's not hard to include a user ID in the packets.
Does need the application or firewall to allow connections to and from specific IP's only - but I really can't see that being an issue.
Problem solved.
Parent
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.
Parent
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).
Parent
Re:Knock Knock? (Score:5, Interesting)
Parent
Re:Knock Knock? (Score:5, Informative)
Parent
old (Score:5, Funny)
pfft, XP has had this for ages....
ISP Port-Scanning (Score:5, Insightful)
This will allow your computer to appear not to be running services expect to the person who knows the magic knock.
Fyodor must be busy... (Score:5, Insightful)
Knock Knock (Score:5, Funny)
Packet.
Packet who?
Packet up bitch, you've been hacked.
how long till... (Score:5, Interesting)
'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....'
authpf? (Score:5, Interesting)
Re:authpf? (Score:5, Insightful)
A perfect example of what it could allow to be done is on knockd's homepage.
Basically, ssh would not be an open port, you'd have to knock (connect to) the right sequence of ports, which would trigger a rule that could allow only the IP that made the successful knock, access to the ssh port.
Then when your done you would have another sequence of ports you'd have to "knock" in order to remove the rule allowing access.
Parent
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.
Parent
Another implementation (Score:5, Informative)
Nice start (Score:5, Insightful)
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.
Interesting (Score:5, Interesting)
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.
Why is this more secure... (Score:5, Insightful)
portknocking.org (Score:5, Informative)
Time based defenses (Score:5, Interesting)
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
So how do you 'start' this? (Score:4, Funny)
>/etc/rc.d/rc3.d/s95Knock UP
?
So there I was (Score:4, Funny)
It's broken, and the real solution is simple (Score:5, Insightful)
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.
Responses to assertions that this is insecure (Score:5, Insightful)
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.
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;
More secure than people think (Score:5, Interesting)
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.
i've noticed a lot of posts (Score:4, Insightful)
Order and Delivery Of Packets Is Not Guaranteed! (Score:5, Informative)
There are less stealthy but more secure alternatives. I wrote one [homeunix.org].
Re:Multiple kocks (Score:4, Informative)
Parent
Re:one of many (Score:4, Funny)
Parent
Re:one of many (Score:5, Informative)
Parent
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...
Parent
Re:Port Knocking implementations (Score:5, Interesting)
I've spoken with several reps at Comcast over the past year. They don't really care what servers you run. (I've been told this explicitly as well as tacitly) In fact, when I first contacted tech support, the guy had no idea what SSH, Telnet (ssh is like an encrypted telnet, right?) or even what a port was.
I've been running an ssh server for about 8 months uninterrupted, now. The general rule of thumb seems to be - If you don't cause trouble for anyone else, Comcast won't cause trouble for you. So, in that interest, I impose reasonable caps on my own throughput and connection counts, and I've had no problems at all.
Parent
Used to be done in phone systems (Score:5, Interesting)
Parent
Re:one of many (Score:5, Insightful)
Well, yes. That's the point: to enable access to a secured system. It's often a necessary evil. The issue is that most people implement these deliberate holes by leaving certain ports open to simple direct access. They're easy to find, and not all that difficult to exploit. Adding a layer of obscurity and another layer of security on those holes - in effect putting a concealed combination lock on them - would be a more secure way of doing that.
Parent
It's all about layers of security (Score:4, Insightful)
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?
Parent
Re:About as secure as telnet(1) ie not. (Score:5, Interesting)
As I said the last time this idea appeared on slashdot, if you want to hide a port from someone but make is still accessible to people who know the "password", here is what you do.
1) stealth the port by default, so it accepts no TCP connections.
2) Have the port silently listen for UDP packets. UDP is fine, because no acknowledgement is sent to the sender, so they don't whether you recieved the packet and ignored it, or if it never got to you.
3)When you receive a UDP packet, see if it contains the correct password. If it does, than you start accepting TCP connections for that IP address only.
At this level, this is just as secure as port knocking (password=port sequence). However, it has an advantage that port knocking doesn't. You can encrypt the packet with the server's public key, so that only the server can get the password out of the packet. You can also require that the packet contain an IP address in addition to the password and then verify that the IP in the packet matches the IP the packet came from. This prevents people from intercepting and replaying the encrypted UDP packet.
Parent
Re:Secrets are not security (Score:4, Insightful)
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.
Parent
Re:Secrets are not security (Score:4, Insightful)
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
Parent