Slashdot Mirror
"Port Knocking" For Added Security
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."
I predict a flood of commenters whining about this being "security through obscurity."
Something tells me I'm going to be seeing a lot bigger firewall logs in the future, as this catches on.
But it does seem like a layer of obscurity to what should otherwise be a secure port. What if someone is sniffing your network? Unlike an encrypted password, they could easily replay this sequence and gain access to your "hidden" port.
The more you know, the less you understand.
This security is easily defeated if the connection can be sniffed to find the 'secret handshake'.
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 implimenting it.
Sniffing.
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!
There is an easy way around it. The problem is you will make yourself very obvious. Simply pick a time at which the server in question is in high use. Hammer the port. Eventually someone will knock on the door opening it for 10 seconds and you put your foot in the door before they do. The other way is if you can get a packet sniffer simply look at the packets that came before and determine the secret knock.
This is still an interesting idea and definitely has at least a few places in which it would be an effective authentication mechanism.
The GeekNights podcast is going strong. Listen!
Except it hides that the port is open at all, which is useful.
There's no reason you couldn't change the knock sequence after each knock in a cryptographically hard-to-guess way (like the SSH one-time passcode mode) or use a hash of the time of day (to the nearest minute) plus some known pass code, exactly like SecureID cards.
Preventing replay attacks is not difficult, and the port-knocking technique generally is a pretty cool hack.
"The "knocking ports" could also be configured that if there are random hits to the standard port without the proper knock, the system could lock down for 30 seconds and even ignore the proper knock so that if somebody's trying to brute force all the possible knocks, they'll never get feedback when they have the right one."
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.
G
As everyone else is saying, this is just security by obscurity. That doesn't mean that you shouldn't use it, because it probably would help a lot in keeping out script kiddies and casual hackers. But the flip side, as always, is that you're giving yourself and your users a false sense of security when you pretend that measures like this will actually prevent motivated hackers from getting past it.
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, to figure out the knock.
come on kids. Have we not learned our lessons? Even as a one time pad, this is lame
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.
Toronto-area transit rider? Rate your ride.
There is only one form of security for a publicly accessible interface: obscurity. What is a password? It is a piece of information that you know that someone else doesn't - it is obscurity. The key to your house is something you have that someone else doesn't. If they knew the obscure details of your key they could make one. What is a private key, a key for SSH, a kerberos function? They are all information you know which (hopefully) a potential attacker doesn't. This is obscurity.
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.)
Although people are right in saying that packet sniffing can easily defeat this, I think it still improves security.
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.
Homme petit d'homme petit, s'attend, n'avale
#1. DoS attacks - how is this different from any other DoS attack?
#2. Sniffing the port knocks - to do this, you would already have to have the upstream compromised or be on some shared network.
All security, in the end, is security through obscurity. Noobs are the ones claiming that obscurity won't work.
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.
Clerks, Mallrats, Dogma, and (obviously) Jay and Silent Bob Strike Back. For some reason Chasing Amy comes to mind to, but I forget what the relation is as I've never seen it.
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!
That depends on the NAT gateway, as per the original poster. If the NAT gateway is dropping all packets that aren't part of a) valid incoming connections or b) a port knocking scheme, a portscan would reveal some or all of the ports utilized in the port knocking scheme. Ports that are closed but part of the knocking scheme would return a connection refused, while all the other (filtered) ports would simply be dropped.
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.
Fully licensed blockchain psychiatrist
It isn't the port. It's the service listening on that port.
If the port is closed, then it is impossible to attack that service through that port.
This process closes those ports.
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...
PHEM - party like it's 1997-2003!
So what you're saying is...If Jim knocks and gets the open door...the door really only looks open to him. Everyone else sees it as closed (based on his IP address or something).
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?
Those are reasonably good descriptions, but you don't need port knocking for this. Just stuff the key in the SYN packet. Don't accept if it doesn't have the magic word. Same effect, no magic cookie, no open port. This only yields to latency analysis, which isn't reliable over anything but a local LAN.
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".
I've finally had it: until slashdot gets article moderation, I am not coming back.
God damn, if I hear one more of you go, "this is just security through obscurity!" I am going to puke. This is the same as cleartext passwords, which are pretty secure if (a) you know nobody is sniffing the network and (b) you know nobody is masquerading as the host you want to connect to. Of course those things aren't typically true, so this alone isn't very secure. But it does disguise your exchange which, contrary to what the security-through-obscurity folks are saying, does give you some small measure of security.
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.
Yes, all secrecy is obscurity in some sense, but there is an important distinction to be made between two types of obscurity. The fact that a port knocking scheme consisting of, say, 10 knocks is being used is one peice of information that someone would have to know in order to be allowed in. What the sequence of ports to knock on *actually is* is a second peice of information. These two peices of information are of very different types. What is the chance that the first peice of info can be guessed? Impossible to say. What is the chance of guessing the second? Simple. It's one over the number of ways of choosing 10 ports from the set of all ports. (NumPorts!/(NumPorts - 10)!) The security provided by the obscurity of the first peice of info is unquantifiable. This is what is typically call 'Security through Obscurity'. The security provided by the the actual password (or whatever you want to call it) is a calculable, knowable quantity. This is real, scientific Security, as opposed to just having a feeling that it is 'unlikely' that someone will guess you are using port knocking, or whatever.
Err, they were *in* Chasing Amy? Heck, the name "Chasing Amy" comes from a speech Silent Bob gave in the movie regarding some chick he always regretted never going after. A speech which is, incidentally, referenced later in J&SBSB... specifically, after their monkey got kidnapped by the Hollywood Animals people, Silent Bob attempted to tell Jay that their license plate said "Hollywood" on it. So, Bob started miming, and predictably, Jay simply would not clue in. Anyway, at one point Jay said something to the effect "you can tell that damn Amy story all the time, but you can't talk now?".
here is why. the first point of entry or attack for ANY attack HAS to be either a) a port scan to find running services, or b) a network sniff of your traffic to find traffic related to running services. The latter (b) is much more difficult than the former (a) due to having to 0wn an uplevel device in your traffic stream to sniff your traffic. Also, with the popularity of switched networks, sniffing is more and more difficult. Since B is much more difficult than A, A is the initial point of attack for most attackers. This method eliminates A as an initial point of attack, but ONLY FOR PRIVATE SERVICES like SSH. In the case of a paranoid techie (us) who wants NO services exposed, this is a nice way to hide our SSH sessions. However, in reality it is only marginally more secure than using a pub/priv keypair for SSH.
That depends on the NAT gateway
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.
A great many people think they are thinking when they are merely rearranging their prejudices. -- William James
It seems like a malicious user could keep you from connecting to your own machine by sending "malicious knock noise" to multiple ports. Meanwhile, your valid knocks would be disregarded as they are intermingled with malicious knocks. This may not seem like a big deal since the malicious user's connection could probably be stopped easily. But in a crisis it may cost you precious seconds or even minutes before you can eliminate the "malicious knock noise" and log into your system.
This seems mathematically equivalent to providing a service which listens (on some known port) for a password, embedded in plain text in a UDP datagram (UDP so that the attacker has no way to know whether the port is being listened to), then opens a prearranged port to the connecting IP address if the password is correct.
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.