"Port Knocking" For Added Security 950
Jeff writes "The process of Port Knocking is a way to allow only people who know the "secret knock" access to a certain port on a system. For example, if I wanted to connect via SSH to a server, I could build a backdoor on the server that does not directly listen on port 22 (or any port for that matter) until it detects connection attempts to closed ports 1026,1027,1029,1034,1026,1044 and 1035 in that sequence within 5 seconds, then listens on port 22 for a connection within 10 seconds.
The web site explains it in some detail, and there is even an experimental perl implementation of it that is available for download. I can't think of any easy ways you could get around a system using this security method - let alone even know that a system is implementing it.
Another article on port knocking is here."
Oh, really. (Score:1, Insightful)
Well, there go the logfiles (Score:4, Insightful)
not bad (Score:5, Insightful)
Sniffing (Score:2, Insightful)
Easy enough... (Score:5, Insightful)
Sniffing.
Before you complain about "Obscurity" (Score:5, Insightful)
An analogy would be a military base with a ten-foot-thick steel blast door. This is like having a door that teleports around at random, which can only be frozen in one spot by speaking some magic word. Even if you know the word, you still don't have the key to the door. But if you do have the key, you still can't get in without the magic word because the door keeps teleporting around.
Obscurity is great, if it is part of a layered security policy which is ultimately based on strong cryptography. This is a really cool idea!
I see an easy way (Score:4, Insightful)
This is still an interesting idea and definitely has at least a few places in which it would be an effective authentication mechanism.
Re:Password (Score:5, Insightful)
Except it hides that the port is open at all, which is useful.
Re:Well, there go the logfiles (Score:3, Insightful)
Re: Replays (Score:1, Insightful)
Preventing replay attacks is not difficult, and the port-knocking technique generally is a pretty cool hack.
Not good (Score:5, Insightful)
That would just create a new variant to DOS attacks. Instead of taking you offline, they just persistantly knock on random ports, thereby disabling your ability to communicate with trusted sources.
Security through obscurity (Score:5, Insightful)
The most obvious way to break into a system like this is to compromise a nearby machine first and install a packet sniffer. Once you can see the traffic to the host running this port knocking system, it would be easy to discover the pattern. In fact, port knocking is less secure than a lot of other nonstandard authentication mechanisms because you could figure out the secret simply by looking at packet headers (since they contain the port numbers).
The other problem I see with this system is that it requires users to either memorize the secret knock, or use a program that automatically knocks for them. Since most people have a hard time even remembering all of their usernames and passwords, you'd see a lot of people writing down the knock, sending it via email, or writing scripts to knock for them. Dozens of opportunities to a hacker, especially one skilled in social engineering [amazon.com], to figure out the knock.
Not the point (Score:5, Insightful)
You are very much missing the point. Yes, security through obscurity is terrible when it is the only security method you use. However, it can be used to augment a better security system. Even if somebody figured out the secret knock, they would still have to get past your sshd. And if an sshd exploit was found, your secret knock might give you enough time to patch the system before it could be exploited. More security is always a good thing.
Disbelief in security through obscurity doesn't mean you have to paint a bull's eye on your head and dare people to attack you.
Re:Well, there go the logfiles (Score:2, Insightful)
i submit it could actually be less secure...
yikes!
Obscurity IS Security (Score:5, Insightful)
If you have a security system for a public interface (the front door to your house, a computer port, etc...) that does not rely on obscurity you have a system better than any theoretical system anyone has ever thought of. (Biometrics don't count - they are just another piece of information that you have that someone else probably doesn't. That's obscurity.)
Re:not bad (Score:1, Insightful)
It's like saying that if sshd asked consecutively for two passwords before granting access, that would be more secure.
It's simple:
a) for every admin, the time he can dedicate to security is finite
b) every minute the admin cares about "port knockin" lowers the time he can spend for something else
c) because of the weakness of this "protocol" (non-encyptable, easyly spoofable source IPs), it doesn't save any time somewhere else. E.g. you can't relax any other real security measure because you now use "port knocking"
It follows that the first effect of using "port knocking" is that there's less time for the other security measures, therefore potentially weaking them.
I like this idea (Score:2, Insightful)
It leaves the impression that the machine has no ports open, so script kiddies will leave you alone. Also, an attacker can't just exploit a server bug to crack the system without also being in a suitable location to packet sniff the knock combination to get the port open in the first place.
Re:Obscurity IS Security (Score:1, Insightful)
To further the point, the best security is complete obscurity. If no one knows you have a server no can hack it. Or, if no one knows that you stashed your treasure in the woods no one can steal it. Unfortunatly complete obscurity is impossible for most things. Having an IP address removes the possibiltity for your server to have complete obscurity.
Which brings up another point. The more obscure some thing is the less effect it can have on the world at large. Interesting.
Re:Security through obscurity (Score:3, Insightful)
The vast majority of s'kiddies will just scan 22, see there's nothing there, and move on to the next host. There will _always_ be far easier targets for them to attack. Why waste their time trying to guess my knock?
Re:Obscurity IS Security (Score:5, Insightful)
Most security is based on secrets of one kind or another---that doesn't make it "obscurity."
Re:Well, there go the logfiles (Score:3, Insightful)
I Disagree. If someone sniffs the knocks, they still have to authenticate to whatever application gets opened up. So, for a sniffer, this may not be very effective (at the worst case, it's no different than what you had before). But for a hacker across the net who wants to get at ssh, this effectively locks them out.
Re:Well, there go the logfiles (Score:5, Insightful)
And yes, one the most annoying things about sitting behind a NAT is only being able to forward a port to a single host at a time. This would be great if "port knocking" could solve this, though in a very Rube Goldberg fashion.
Neither. (Score:5, Insightful)
#2. Sniffing the port knocks - to do this, you would already have to have the upstream compromised or be on some shared network.
"Security through obscurity" bashing is for noobs (Score:1, Insightful)
In the end, what is the goal of security - to protect the data being stored or presented. Now, protection against a DoS maybe won't fall into this category, since that is just basic load balancing and testing. Everything else, though, requires enforcing the principle of least access.
to enforce that principle, you have to limit the availability of accounts that are privileged to do things you don't want done. Now, that is handled through password, multiple factor authentication, encryption etc. But all of those are predicated on the attacker not knowing what precise string is the equivalent of the old "Open Sesame".
Patching? Chrooting? Hardening? all of those boil down to an attempt to make the attacker who wants to haxor something enter in through the appropriate channels (VPN to the backend and SSH in, open the door and sit at a keyboard, etc) and, o enter through those channels, he must know something that is not available (password, numebr being displayed on a SecurID token, key shape, etc).
Security is all about preserving obscurity. Nothing more, nothing less.
Re:Well, there go the logfiles (Score:3, Insightful)
Also can you imagine trouble shooting problems on this.
oh I see the problem, your connection wasn't able to send a knock from your network on port 8019, but it was on 1223,6789,9865 oh but not 7024, oh crap you have another ap on 7024 and when you send requests, it gets bad request errors in the error logs, well lets switch that to 2345. Or other problems to be seen, also now hackers won't just port scan me, they'll port scan me a trillion times, trying to find the right combination to open my ports.
Beautiful
Re:not bad (Score:3, Insightful)
I will have servers in datacenters spread around the US and possibly overseas. His solution wont work for me. So cost/benefit/risk compromises come in to play, which is where extra layers comes in.
Re:Silent Bob (Score:2, Insightful)
How can you mention Clerks and not the others? Clerks was my least favorite! It had no plot, just that whiney bitch the whole time.
I'm not even supposed to be here today
SHUT UP BITCH!
Re:not bad (Score:3, Insightful)
Re:Security through obscurity (Score:2, Insightful)
1) ...compromise a nearby machine first and install a packet sniffer...
Use a one-time pad system, as mentioned above.
2) ...you'd see a lot of people writing down the knock...
If you'd read the Linux Journal article [linuxjournal.com], they address that by saying the program that executes the knock needs to be very secure. Say, like the USB key they mention.
This isn't a great system for continued, heavy use as this guy [slashdot.org] pointed out, but it could be used for emergency purposes. For example, if you had to remotely administer a server. You have an emergency USB key that you plug in your local machine, knock, then gain remote access with the opened port (using whatever authentication you would have if the port was simply open).
I think, at very least, the concept needs to be thoroughly debated and vetted. (Maybe that's what we're doing here, or maybe we're just wanking ;)
PrisonerCX
Re:Oh, really. (Score:1, Insightful)
Re:Open a whole range of ports (Score:5, Insightful)
Granted, most anyone implementing this sort of security setup on their firewall would most likely think about this and either a) open an entire range of ports, only some of which would be used for port knocking (as a previous poster mentioned) or b) simply close everything at the NAT gateway and not drop any packets, thereby not revealing any detail regarding a port knocking scheme.
I'm sure there are several other ways to deal with this at a NAT gateway, but they just aren't coming to mind at the moment.
Re:Obscurity IS Security (Score:5, Insightful)
So this just makes part of the protocol secret, and one of our assumptions about security protocols is that the protocols are known.
Yes, it's an interesting and reasonably clever little hack (it is not, however, new), it does tend to hide some information (e.g. that the ports are even open) but if you're going to make the port look closed, anyhow, why not just listen on that port for something that would cause the service to "wake up"? I guess they thought it seemed a bit more clever the other way, who knows?
Services listen on ports. (Score:5, Insightful)
If the port is closed, then it is impossible to attack that service through that port.
This process closes those ports.
Re:not bad (Score:5, Insightful)
Open ports per se are not insecure!
The whole point behind port knocking is the wrong impression that "open" ports are more insecure than "closed" ports. This is totally bogus.
It's about the applications behind the open ports, and it's not more complicated to write code which listens to a specific port and drops the connection if it doesn't recieve some secret number as the only payload of the first packet, than it is to write the kernel tcp/ip stack.
That brings me to another mantra
Kernel code is not intrinsically more secure than application level code!.
There are many examples for buggy and overflowing tcp/ip stacks (ping-o-death comes to mind if you're somewhat older).
Order, delivery of packets is not guaranteed (Score:4, Insightful)
This system is going to be unreliable. No way around it. A single dropped packet and you have to try all over again. If you're really paranoid, like some have proposed, and disable the "knock monitor" temporarily if someone tries to connect unsuccessfully, it will also be horribly slow.
If you use it on a LAN, maybe the net will be reliable enough, but then you have to worry about sniffers...
can you allow ports to be open to only some? (Score:1, Insightful)
Is it based on IP address? What if he's coming through a NAT at a college campus, lets say. Can I get at the open door if I'm on the campus too after he knocks?
Re:Well, there go the logfiles (Score:5, Insightful)
Re:not bad (Score:3, Insightful)
Re:Equivalent to a password (Score:3, Insightful)
The only advantage of portknocking is that it's a hack that's doable in userspace without a modified net stack (you may be able to fashion raw packets, but good luck reading them). But enabling the userspace hack would mean poking so many holes in your firewall that you'd degrade the security of the system that you're trying to lock down with this hack.
I'd file it under "another cute perl hack".
Stop complainin about "security through obscurity" (Score:5, Insightful)
This is just a way of encoding some bit transfer in the IP protocol instead of in the beginning of whatever protocol you're using after the connection. You could also use it to send cryptographic credentials which could be as secure as any other protocol (plus some extra security by obscurity). The only problem with that is that you need a way to send back information via TCP (because most good authentication protocols are two-way), but I think you need that anyway in order to serialize your knocks.
Semantics! Obscurity and Security are different. (Score:1, Insightful)
Re:not bad (Score:1, Insightful)
Re:not bad (Score:2, Insightful)
Bingo!
With a knocking daemon a port scanner is going to see an IP address with no machine on the other end because no response is sent to its connection attempts. It's a great way to conceal the location of a server from broad port-scanning that you currently see on the internet.
Re:Well, there go the logfiles (Score:5, Insightful)
And what stops them from brute-forcing regular password protected access on a known port?
1) You don't know how many ports are in the knock sequence
2) You don't know that the range is
3) You don't know what port will open when you get it right
Similar to a password, only instead of base 94 (a-z,A-Z,0-9`~-_=+\][|}{';":/.,?>million trillion trillion trials to crack. Then you have to do one more scan to figure out which port actually opened after each trial and hope no other service opened a port for some unrelated reason.
I'm thinking it's a tad more secure than password authentication alone... and you can always throw password auth in after the client connects, so you can throw in a few false-positives (bogus logins) to keep them busy.
And a five second window to transmit the sequence is pretty generous. If you wanted to harden it even more against brute forcing, you could require a full 5 second wait and accept all connection attempts from a particular host. That would limit an attacker to 20 attempts per minute max. So it'll take the better part of 32 billion trillion years to crack it.
At that point, you can consider the end of the universe as "The ultimate connection timeout"
=Smidge=
Re:not bad (Score:5, Insightful)
No it isn't. A closed port does not accept any data, therefore you cannot attack the application "behind it". A port that is open is only as secure as the application listening on that port, which AT BEST is as secure as a closed port, assuming the listening service is absolutely perfect, and has no flaws whatsoever.
There does seem to be some confusion as to what it means for a port to be "closed", judging from most of the posts I've seen so far. You can close a port, but send "connection denied" replies to anyone trying to connect. This makes the port itself safe, but tells the attacker that there is in fact a machine there on the network (which could be a reason for an attacker to continue to probe and/or attack you in other ways). You can also close the port by not responding to anything directed at it at all. If *all* of your ports are like this, an attacker won't even know if your machine is turned on or off, or if there's even a machine there at all. In a way, you've become invisible. Ideally, that's what you want. Port knocking is simply a way to allow your machine to be invisible while still being able to initiate connections to it from arbitrary IPs.
Re:Silent Bob (Score:3, Insightful)
Re:Security through obscurity (Score:3, Insightful)
If any admin ever feels secure, they have other problems. Any admin worth their salt is always paranoid.
The whole point of it is to make things a little more obfustacated. If a cracker already knows you're running a service they are interested in exploiting, you are already at risk anyhow. If somebody with some real skills was taking a shot at compromising your network, then this will not stop them, but it is a little smarter than inviting every script kiddie with a port scanner and their dog to smash at your SSH port.
It is a reasonable addition to a balanced security breakfast.
it IS more secure... (Score:1, Insightful)
Re:Open a whole range of ports (Score:5, Insightful)
No, the gateway or direct host has ALL PORTS CLOSED, however it does log port requests. If the log shows the knocking sequence, then and only then, will it open a port.
Re:Well, there go the logfiles (Score:4, Insightful)
It should give you less irritation as an admin, when portscans reveal that every port on your computer is closed, and they go find another target, wondering why you bothered buying a firewall if you seemingly haven't configured it to accept connections.
A recent nanog (was it nanog?) flamewar mentioned that people ran their servers on non-standard ports and they considered it really secure. Why? Because the viruses only scan one port, and choosing a different one gives you a lot of time to take stock when a vulnerability/virus pair is announced.
It's obscurity (as a first layer of defence), but it means that an "nmap * -p 22" won't find your server, and anyone running the full scan of 64K ports over the internet is making themselves a lot more visible, and a lot slower.
Re:Well, there go the logfiles (Score:3, Insightful)
But if it is implemented in some soft-/hardware combination, then those timing issues are much smaller. But then why not just use a big-ass public key-pair.
Re:Obscurity IS Security (Score:3, Insightful)
Foisting crappy code on the public and hoping that nobody breaks it is a very Darwinian head-in-the-sand approach. I can see your point that "we're against obscurity" provides a justification for that approach.
It puts the cart before the horse and shouldn't raise anyone's confidence in the code. Proving that one could do so, however, should raise confidence in the code.
Locked out of your own machine? (Score:3, Insightful)
Re:not bad (Score:4, Insightful)
And this number is only relevant if the attempted cracker knows your knock sequence is exactly 10 ports long. Add or subtract a couple steps from the sequence, and the number of possibilities increases factorially.
Re:Well, there go the logfiles (Score:3, Insightful)
I understand your point, but if I understand port-knocking correctly, it will allow you to effectively cloak the existence of a service entirely. Even if you use a 1-time pad authentication scheme, Mr. Evil Cracker can still connect to your server and see that a service is running. Perhaps it is a commonly used service, and a known exploit exists that bypasses the authentication mechanism. Unlikely, I know, but with port-knocking, connection attempts to your server are simply dropped on the floor, until the correct sequence of connection attempts is received.
Unless Mr. Evil Cracker is sitting somewhere in the middle to sniff a valid connect attempt, he will never even know the service exists.
Re:Oh, really. (Score:4, Insightful)
You can then hide any service that is not to be known from the public (SMTP, POP, SSH, TELNET, whatever...) thus removing the probability that any exploit for these may be exploited: The hacker on the other end doesn't even know the service is running!
Re:Obscurity IS Security (Score:3, Insightful)
That's the whole point of public and private keys. Statistical impossibility of dechiphering the private key--not obscurity--is its goal.
Re:I see an easy way (Score:1, Insightful)
Problem is, servers with any sense of security would quickly firewall you for SYN flooding them.
mathematically equivalent security (Score:1, Insightful)
Some have argued that the proposed scheme is better because it doesn't involve listening on a port, but that's just silly--it means you're listening on all ports, and that the service that does the listening resides in the kernel rather than being a daemon bound to a port. The security of the proposed scheme is neither better nor worse than the one I have listed above, but the one I've listed above is simpler.
In both cases, one-time-passwords could be used to circumvent sniffing replay attacks.
Frankly, both of these are too complicated; I'd rather see ssh audited to heck and back. But there is something to be said for not telling the attacker that a service is listening.
Re:not bad (Score:1, Insightful)
Don't kid yourself--under port-knocking, every port becomes open, and there's a kernel process listening "behind it" which may or may not have exploitable bugs. Maybe knocking in some weird order could trigger a buffer overflow which grants a root shell or something. You haven't improved the situation at all beyond listening for udp datagrams with plaintext passwords on some udp socket (which gives no indication that it's listening) and opening ports in response to that.
Re:not bad (Score:3, Insightful)
You do not allow SSH connectivity for remote administration even from a few identified hosts (even to only a single host in a dmz with non-port forwarding connectivity in to the rest of the network)? Why? Do you also not allow email in to your network? Do you not allow your users to browse the web (particularly with IE)?
If you're not doing the other things I mentioned, then you're niave. If you are... ummmm...