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.
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.
Along the same lines, it would be useful to us non-warez folk that run servers at home that are for personal use, but have broadband that disallows servers in the AUP.
I'm betting that nmap binary is about to get much bigger...
<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>
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.
passwords and port knocking are two different things.
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.
Than a single coded UDP packet?
So using port knocking to open up ssh to you can login is no more secure than plain-text passwords? DAMNIT.
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.
Meh, throw some cryptography into the mix.
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.
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)
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.
http://alternatives.rzero.com/
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.
In practice though, once the system becomes
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.
MP3 Search Engine
Yea but if you have ssh open with this it is just another layer of security. It is hard to truly secure a box with no openings and this is just one more thing that will trip people up. If you implement this and somebody tries to brute force your password or something it would certainly take longer (if they are not locked out because so many tries first). In todays world it is just one more tool that can be added to the computer security arsenal. Hell it would not even be a bad back door to your own box. Imagine a remote box and you upgrade ssh...but it fails. You simply portknock and have some odd port with telnet open up. You just saved yourself some money and time of having somebody go and fix the server from the console.
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?
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.
Most people do't get why port nucking is a good thing. You use it so that when you want to keep your openssh from being find and hack you can. I want to be able to connect to my sshd and not worry about it being hacked with some buffer overflow. This is only useful anytime you want add an extra layer of security to your services well unless your a hacker then it can be good for backdoors. Once I setup a "Door" I no longer needed to wade through long logs off poeple trying to log into my box. This makes my life easier, smaller logs files to look through. It even once stop a freind of mine from logging into my home computer with the password he shoulder sniffed thanks to my handy "doorbell" perl script, of course he could have just used the doorpell post script. It is a great secruity tool, it is hover not the ultimate security tool, which is of course concert and lots of it.
Next idea.
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
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
The point for me would be to punch a hole in a draconian acceptable use policy. Many broadband providers to not permit you to run servers, and frequently they will run portscans to find violators. With this technique, they could portscan away, and I'd still be able to access files on my home machine from outside. Pesky broadband monopolies.
"I'm not impatient. I just hate waiting." - My Dad
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....
a) ...increase scans exponentially. ...excuse for DDoS: "Sorry, thought I knew the knock... so I tried every possible combination."
b)
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?
Programs are often more secure when they have fewer features of any kind. Pick something simple and do it well.
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
So your theory is that programs are MORE secure when they have LESS security features
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.)
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?
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Obviously network byte order (big endian) would be most sensible.
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.