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.
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.
Re:Great for warez... (Score:2, Insightful)
Fyodor must be busy... (Score:5, Insightful)
Re:Great for warez... (Score:3, Insightful)
<tongue in cheek>
If you had an ISP that was port scanning for open FTP servers on port 20, why not just move your port to another port with well known use for home users, like 135?
</tongue in cheek>
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.
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.
Why is this more secure... (Score:5, Insightful)
Re:authpf? (Score:1, Insightful)
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.
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.
Security (Score:3, Insightful)
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.
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.
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.
Re:one of many (Score:3, Insightful)
automated it no longer is the user that sets
it up but some - untrusted - application like
say the next cool file sharing program. Next
a bug is discovered and *bang* millions of
previously firewalled machines are suddenly
wide open.
Re:About as secure as telnet(1) ie not. (Score:3, Insightful)
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?
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.
Re:Knock Knock? (Score:1, Insightful)
Dumb idea (Score:2, Insightful)
Next idea.
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.
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
Use of port knocking... (Score:2, Insightful)
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.
Re:one of many (Score:3, Insightful)
Services (Score:2, Insightful)
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.
i've noticed a lot of posts (Score:4, Insightful)
Port Knocking, or How I Learnt to... (Score:1, Insightful)
b)
Even better for IPS? (Score:2, Insightful)
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?
Re:one of many (Score:2, Insightful)
Re:It's broken, and the real solution is simple (Score:4, Insightful)
Re:Why is this more secure... (Score:3, Insightful)
A similar procedure could also be used to dynamically route ports (sort of like portmap) through a NAT firewall to specific hosts on the inside, thus moving the software requirement off of the server itself and onto the firewall. The client side can be just a small userland app to unlock the port, then the normal program can initiate the port connection (ssh, eMule, kMail, or whatever)
Authpf *IS* another layer (Score:3, Insightful)
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.
Re:one of many (Score:2, Insightful)
Actually, programs are MORE secure when they have LESS features. period. Security features are still features. If implemented incorrectly they can weaken security instead of enhance it. Complexity increases the probability of vulnerability.
I suppose that having passwords on user accounts is silly, too, because some rogue program could log keystrokes and post them to the web.
In some situations, that is exactly correct. It depends very much on the application. In some very high security situations, passwords are considered too weak to rely on. In those cases "something you have" and "something you are" are often used as two factor (strong) authentication.
And yes, I am an information security professional. (but not a lawyer.)
Re:Interesting (Score:3, Insightful)
How can you consider this any more secure than a password prompt? It's simple old obsecurity. There are less combinations of TCP/IP flags than there are letter/number combinations, so a flag-based system is easier to brute-force, not harder.
Once your worm has been decrypted, everyone will know what TCP flags need to be set, and anybody can connect. It's not like you're going to fool anybody here.
And let's not forget about all the firewalls out there that might decide to drop your packet because of the flags. I know mine will drop any initial packet that doesn't have Syn (and only Syn), so you'd be out of luck.
Please fill me in, how would this make "a devastatingly powerful virus", or even a reasonably secure authentication method?
Re:How do you transcribe... (Score:3, Insightful)
Am I the only one who's noticed that these perl implementations all contain a bug which the original QBASIC one didn't - if there's an odd number of characters the last one is ignored, whereas it should really be counted somehow.
Although the QBASIC implementation put it in the least significant byte; I'd be tempted to put it into the most significant byte, effectively padding the end of the string with an extra zero.