"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."
Invasive Security (Score:2, Interesting)
whats more, connection attempts are easy to sniff, you might as well be using telnet...THIS THING IS BEGGING FOR A "REPLAY ATTACK".
My idea (Score:5, Interesting)
Worse? (Score:4, Interesting)
Re:not bad (Score:5, Interesting)
And? It is still more secure. By using "port knocking" they HAVE to sniff out your network traffic and find the port combo. Without "port knocking" they just need to run nmap and see what ports they can try to attack.
One-time port knocking? (Score:3, Interesting)
Equivalent to a password (Score:4, Interesting)
Ideally, the implementation will only consider connection attempts originating from the same IP address.
Re:Oh, really. (Score:2, Interesting)
Yeah, just like passwords are "security through obscurity."
This is essentially another level of passwords, but sounds useful for hiding those services that could have vulnerabilities *cough* OpenSSH *cough*.
Will this technique itself have possible vulnerabilities?
Re:not bad (Score:5, Interesting)
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.
Yeah, this is no substitute for properly securing the original service, but it's an extra layer that means there's even more that needs to be captured for a successful hack...
NOT security through obscurity (Score:5, Interesting)
Also, this is only a defense against port-scanning. Even if someone did manage to break the knocking sequence, they would still have to use some kind of exploit against the machine on the port they discovered.
Re:not bad (Score:5, Interesting)
Hmm, lots of people have pointed this out, but it's easy to set up a system of one-time passwords... provided it's done in a cryptographically secure way, there's little point in sniffing for combinations.
Of course, you can still sniff to see what ports are actually in use...
Possible problems (Score:5, Interesting)
Great for SSH (Score:3, Interesting)
OpenSSH is a great peice of sodtware - but it's so huge that I can't help but think that their could be flaws in it (like the one of 6 months ago)
I would love to layer another peice of security infront of OpenSSH and this seems like a great idea.
Reverse-knock (Score:5, Interesting)
Re:Well, there go the logfiles (Score:2, Interesting)
Why would this be any more secure than listening on a single port for the "unique knock sequence?" Any good admin knows the most secure system is one that is listening on as few ports as possible.
Implementations? (Score:3, Interesting)
Of course, this won't take off unless there's also knocking support built into the clients (like ssh).
Re:One-time port knocking? (Score:2, Interesting)
rotate the knock (Score:2, Interesting)
hmm... (Score:5, Interesting)
This definitely is security through obscurity and perhaps would work in the same way as a car alarm. There's lots more systems out there that are easier to break into, and if someone does try, just hope that they get fed up and moves on to the next one.
If you've gone this far, why not do something like they do on radio. Open up severable ports at the same time and multiplex your signal over several of them while sending noise over the ununsed ports randomly switching between ports using a syncronized random selector.
go a step further (Score:5, Interesting)
IE, secureID says sequence is "1234 1441 1114 5123", you knock on the first three, and 5123 is the ssh port activated for you only.
Re:Well, there go the logfiles (Score:5, Interesting)
Re:Well, there go the logfiles (Score:5, Interesting)
Different knock patterns at the NAT open you to different internal hosts. Quite interesting possibilities there.
Re:Well, there go the logfiles (Score:5, Interesting)
1. Many ports getting a sequence is much more like noise than one port getting it -> much harder to identify an attempt of intrusion.
2. If you have a backdoor, as mentioned in the article, how will you know it has not been accessed? It was not listening, it gets activated, does its duty, deactivates. If it is a good backdoor it is invisible to that system (only visible though an additional layer).
So it is a better way of getting a connection, but not a solve-all for the intruder, and I doubt the intruder cares about any waste of your resources.
Knock Knock Honey Pot (Score:5, Interesting)
A Question about packet sniffing (Score:3, Interesting)
Wouldn't he have had to hack a computer closer to his target in order to be successful?
Wouldn't the best option be to have some type of SecurID based password in order to access the port? Unless there is a bug or hole in the software isn't a randomly changing password that requires a pin about as good as it gets?
And as they say, Security through obscurity isn't.
I thought of this 2 years ago (Score:4, Interesting)
In my version of "port knocking", everything was going to be controled via ICMP echo packets.. aka "ping".
A single Ping packet can contain arbitrary data of an arbitrary length less than 64k. Through a config file, the system admin could define ping sequences using time, data, and/or packet size, along with a specified script to execute on each successful reception of the ping sequence.
Then, remotely, people who know the ping sequences could use almost any available ping utility on any machine to open remote ports, etc.
The concept of executing a script, rather than opening or closing ports, allows for more flexibility. Not only can the admin open and close ports via scripts, but could do other useful things.
Re:not bad (Score:3, Interesting)
No, if you were "super paranoid" you'd have two identical one-time pads, one residing on the computer to be accessed, one in the hands of a single person trying to connect.
Every minute, the computer would consult its copy of the pad to determine what that minute's secret knock sequence would be.
The person connecting would look up in his copy of the pad that minute's sequence. You'd need to synchronize both participants' clocks, of course.
Less secure would be generating a new combination -- using some continuous function -- every minute.
Less secure than the pad, but more secure than a continuous function, would be a cellular automaton -- life Conway's Game of Life -- where any particular minute's knock sequence could only determined by first determining the previous minute's sequence.
Of course, to prevent the rules from being extrapolated by anyone analyzing your traffic, you'd have to agree on a new function or automaton to use for the next connection before ending the current connection. To guard against interruption of the connection, agreeing on the next connection's function would be the first thing you'd do after making a connection, and to guard against that being interrupted you'd need some fallback combinations -- which brings us back to the one-time pad.
Re:Well, there go the logfiles (Score:2, Interesting)
But you're missing the point that this doesn't require any extra ports being open. The listener waits for the correct series of attempted connections to closed ports, and then transiently opens an otherwise closed port. Thus the approach lets you leave a port open temporarily when you would otherwise have to leave it open all the time, so it should add safety by your known good administration practices.
Re:Possible problems (Score:3, Interesting)
Re:Equivalent to a password (Score:5, Interesting)
This seems much better than a password, I would think (Though I certainly would still use a password as well).
As an analogy, if you want to get into a house, and find a locked door, you have a few options... You can try one of those M x N position key blanks, which will take a very very long time (exhaustive search). You can try to pick it (exploit a weakness in the password algorithm). You can try to get ahold of a copy of the real key (packet sniffing, "shoulder surfing", etc). But you have no doubt that somewhere, a key exists that will open that door.
Now compare that to a solid block of concrete, roughly the size of a house. What does it do? Do helicopters land on it? Does it cover something, or hold something down? Does it have something sealed inside it? You'd never suspect that that, if you utter the magic phrase "Sim sala bim bamba sala do saladim", a door will appear in the side of this large concrete block, allowing those with a key to gain entrance.
The main difference involves knowing whether or not a way in exists. With just a passworded port, an attacker knows that enough effort will pay off. Adding in port knocking, that attacker doesn't know whether or not their hard work can ever gain them entrance, since a port might well not exist.
Now, in my opinion, the more interesting question here involves how to hide this from one's ISP (ie, make it snoop-proof).
freq. hopping analogy- (Score:5, Interesting)
Two radios synchronize, based on a key, and both change frequency every so many milliseconds. If you don't know the key, you can't send or receive to either of them.
I would like to see this extended to a port-hopping system for all ports and services. Sure -- it will burn some clock cycles, but I like the approach.
- Sam
http://www.iamsam.com
Re:not bad (Score:5, Interesting)
Re "brute forcing"... the number of possible knocks is (ports used for knocking) ** (ports in knock sequence). Yes, that's exponentiation.
In fact, I'd suggest making the knock sequence much longer then in the article; ten might be good. Then, if you allocate 100 ports to the knocked and randomly select a 10 port sequence for the knocking, you get 100 ** 10 possible knocks, or 100,000,000,000,000,000,000 (100 sextillion) possible knocks.
With just a few more ports in the sequence and just a modest investment in ports, you can make brute forcing impossible.
(And if you mix up the ports so they aren't sequential and the attacker has to guess THOSE ports, it goes to approx. (2**16)**(number of knock), so for a 10-port sequence on potentially all TCP ports it's 1,461,501,637,330,902,918,203,684,832,716,283,019
(I love posting big numbers on Slashdot.)
You need to worry about sniffers way more then brute forcers. (And as this is another layer of security, hopefully on top of an already fairly secure protocol like SSH, it's a good thing; now the 'man in the middle' has to have advanced knowlege to even know there's something to get into the middle of!)
Re:not bad (Score:2, Interesting)
I think the idea is that an attacker would install a hidden sshd on your system, and you wouldn't know. You wouldn't even see an open port. You wouldn't see concentrations of connections to one "closed" port, but sporatic attempts at a few seemingly random ports. The attacker would use this as a backdoor into your system. I think you got the wrong impression that this would be a keen tool for system administrators for some reason. I didn't RTFA, but jeez.. at least read the summary.
Re:not bad (Score:4, Interesting)
In a way it does. It firsts asks for a username, and then a password. If one of them is incorrect, you don't get access. But SSH doesn't tell you which one was incorrect.
Port knocking is very similar (but not exactly the same). You need to have both keys (port combination) and login info in order to get access.
The difference is, without the port combinations, you can't tell if the service is up, or your port combination is wrong.
not so shady... (Score:5, Interesting)
iptables -N ${SSH_TABLE}
iptables -Z ${SSH_TABLE}
iptables -A ${SSH_TABLE} -m state --state NEW -m limit --limit 2/minute --limit-
burst 2 -j DROP
iptables -A ${SSH_TABLE} -m state --state NEW -m limit --limit 7/hour --limit-bu
rst 7 -j DROP
iptables -A ${SSH_TABLE} -m state --state NEW -m limit --limit 10/day --limit-bu
rst 10 -j ACCEPT
iptables -A ${SSH_TABLE} -j DROP
well, I thought it was cool...
Re:Security through obscurity (Score:3, Interesting)
Re:Well, there go the logfiles (Score:5, Interesting)
Not a new idea (Score:2, Interesting)
Re:Obscurity IS Security (Score:3, Interesting)
In the context of the theoretical shifting door in the wall, part of what makes it secure is that outsiders don't know how the door works; they only know that it moves away when an unauthorized person tries to open it.
However, people who oppose "security through obscurity", especially when in conjunction with blind open source advocacy, would argue that giving would-be intruders the blueprints of the door system would somehow deter them and make the system more secure.
Re:Well, there go the logfiles (Score:3, Interesting)
Think "in addition to" and not "instead of". No reason why you couldn't do both. In fact, you could rotate your port knocks to be different everytime you connect. That way, if someone does try to fake their way in, you could detect it and react.
Re:Well, there go the logfiles (Score:5, Interesting)
Re:Obscurity IS Security (Score:3, Interesting)
I think that's the point the grandparent is making. The key to this is that folks around here aren't real clear on the difference between "obscurity" and "secrets". One is touted as being worthless by itself, the other is accepted as the cornerstone of electronic security in general (I posit that the cornerstone of physical security is violence).
the phrase "security through obscurity" means obscurity of system design.
This is an excellent point, and deserves to be modded up because *way* too many people both here and elsewhere miss this fundamental concept. In my opinion any method that makes accessible hosts look the same as unaccessible hosts to a port scan is a great idea, no matter what folks here choose to call it.
Dan
It's _not_ just another password... (Score:5, Interesting)
Re:Obscurity IS Security (Score:1, Interesting)
Re:Possible problems (Score:1, Interesting)
Lets say you had to knock on port 333, 555, then 444. And you did this with two applications at once. The firewall should see it like this if your knocking application is programed properly.
TCP SRCIP PORT 1024 DESTIP PORT 333
TCP SRCIP PORT 1024 DESTIP PORT 555
TCP SRCIP PORT 1026 DESTIP PORT 333
TCP SRCIP PORT 1024 DESTIP PORT 444
(the first connection has authenticated now)
TCP SRCIP PORT 1026 DESTIP PORT 555
TCP SRCIP PORT 1026 DESTIP PORT 444
(the second connection has authenticated now)
It looks like if it was programmed correctly port knocking would work fine.
Re:VPNs already solved this problem... (Score:3, Interesting)
Congratulations. You've just extended your "secure" corporate network beyond the physical walls of the office, and into the house of one of your employees. Are you sure that the machine they're using as a VPN client hasn't been rooted? VPNs have their uses, but they're far from solving this problem, and in many ways weaken your overall security. The correct solution is to change the authorisation criteria from things you know (password, "secret handshake") to things you know plus something else, for example, things you have. We do this with one time passwords sent to a user's mobile phone. Once that's been entered, they're prompted for their normal password. Thus even if the box has been rooted, and has keystroke and network sniffers galore, it doesn't matter. So long as the black hats don't have my trusted employee's mobile phone, they're not going to get in (and furthermore, the unexpected passwords being sent to the phone act as an early warning system to let us know someone's trying to break in). Of course, no security measures are perfect, and theoretically, with root access, they could hijack an existing ssh connection once it's been opened, but it's non-trivial, and we've raised the bar considerably.
Simpler Implementation (Score:3, Interesting)
"open port Y for ip Z using key K"
if the port opening policy accepts this command then it is opened otherwise it is not. Better yet 'REAL' crypto could be used to protect the ports. Fore example...
"open port Y for ip Z @ TIMESTAMP" Encrypted by K.
This simpler implementation (more likely to be correct) will provide equivalent security.
Still vulnerable to packet sniffing (Score:3, Interesting)
Of course, there really is no way to block a skilled hacker who is intent on breaking into a specific network/box by any means necessary.
Re:Reverse-knock (Score:3, Interesting)
Your legit users (' software, anyway) usually knows how to connect to the real port first time.
Re:Well, there go the logfiles (Score:3, Interesting)
An additional step here would be to have both machines (server, client) seeded with the same randomly-generated number and then, utilizing the same algorithm, generate a random port sequence for knocking. This sequence would be valid for 10 to 30 seconds, at which point the sequence for proper knocking is re-generated.
I'm guessing this would need to be tied to Time of Day, necessitating accurate time; so either an external GPS device or an NTP connection would be required.
This is just some off-the-cuff speculation, so don't flame me for the holes.
All the time the same arguments (Score:5, Interesting)
Since some still don't understand its use, i'll be speaking metaphorical:
Assume you need to have a special key to open a certain otherwise secure door. OpenSSH might be that door and your passphrase and your certificate are the key.
An attacker can still forge the key or attack the lock with a different approach, picking etc. - comparable to "social engineering" to get the password, brute forcing or exploits.
And that port knocking sequence now effectively hides the lock, leaving an attacker without a first approach to pick or break the lock. It just adds another layer of security. You just don't know where to start your attack. You can't use exploits, you can't try brute force - nothing, heck you don't even know what type of daemon your target is.
A clean stainless steel door with a covert RFID-detector one square inch in size, hidden somewhere, sure as hell beats the same door with a clearly visible lock. You still need to pick the lock, but you can't poke your lockpicking tools into solid steel and you can't crack something you cannot discern.
--- Still one addition to say: having a machine connected to the internet with no ports open makes you a prime suspect for the port knocking scheme.
A good stealth scheme may be implemented, so a potential attacker (excuse for this metaphor again) does not even see the door (or the building, for that matter).
I did this about 5 years ago (Score:5, Interesting)
I did this about 5 years ago. But my method was a bit different. Instead of using port numbers to contain the information (and that's all it really is, is just information), I sent a single UDP packet, with a source port of 53 (so it looks like a DNS answer), formatted like a DNS answer, that contained the information in the DNS answer data. Then it opened the SSH filter for that IP address to come in (I did it for 5 minutes, not 10 seconds). It still had to fully authenticate via SSH, so even if someone sniffed my DNS packet and tried to fake it, they could at most have a locked door to jiggle the handle on. Next time I do this, it will be to generate an MD5 checksum from the client IP and a secret salt, and send that as an IPv6 address in the packet. Then it can't even be faked from some other IP address.
Counter Proposal: Port Traps (Score:5, Interesting)
What if I turn this whole thing around and install fake services on a number of ports?
For example, whenever you make a connection to a port between 1025 and 2048 on my system, you're greeted with "OpenSSH ...", and prompted to authenticate. But only behind one among those 1024 ports is the real SSH. On any other port, the fake service takes the username and password you've entered, wait a few seconds (just idling around), and tell you "Authentication failed". If you try too often to connect to faked services, you're put on the black list to avoid DOS, of course.
Why not use a listening socket on UDP+encryption? (Score:4, Interesting)
It really is nothing more than a password to get access to the front gate... When somebody eavesdrops (sniffing), they will know the passwords, thus get access to the gate. They can sucessfully detect the knocking sequence because it is followed by a successfull ssh connection (duh!).
The password is this 'secret sequence' in this 'port knocking'. Why not just use a daemon that listens on a UDP socket for a packet with an encrypted password in its payload? The payload could even be an RSA-signed and/or encrypted request (that includes a timestamp). That would be unscannable too, because UDP is connectionless, and be a lot more secure because of the real encryption/protection of the request data (the server can verify the identity of the sender of the request from the RSA signature, and can deny the request if one was made earlier with the same time stamp, twarting even sniffing of the UDP packet).
Except for not having the ssh daemon 'connected' to the internet at all times and thus evading many port-scanning worms/scripts, this port knocking is nothing more than just some security through obscurity: At best it will delay the attacker somewhat, but probably not at all while giving the user a false sense of being secured.
Re:Well, there go the logfiles (Score:5, Interesting)
This can be done dynamically as a form of load balancing which is a neat hack. Expire the specific forward rule after 30s or something. Means similar requests cluster - less DB traffic.
But, combine this with knocking and you've got the next step. Secret services on a 'stealthed' IP, where you can request which quake server (for instance) by knocking in a different way.
Port scanning isn't what it once was. Especially once you factor in time-sensitive keys (easily doable - both machines need a net connect to reach each other, ntp is then trivial) and ID-sensitive keys (so my key isn't like yours, even at the same time). Even if you managed to snoop on a 'knock' you couldn't repeat it.
Re:Well, there go the logfiles (Score:3, Interesting)
Another method I would like is some sort of handshake authentication where the firewall would reconigze who you were after logging in and would open ports up appropriately depending on your private key. I think MS proxy server does this with NTLM authentication but I am not too sure. There is IPSEC but this does not work over the internet or many campus wide networks if your at a unviversity.
A unix equilivant would be nice with Kerbos, LPAD or Samba support.
Having a dual firewall this way is rudant but it would work since I use my nat/router more as a hub then just a firewall.
Reminds me of xringd (Score:2, Interesting)
Different kinds of "listening", different places. (Score:3, Interesting)
It doesn't actually use significant resources unless it's getting pounded with lots of packets, and you can limit this by only listening on a few ports, blocklisting IP addresses that knock on the wrong ports, and limiting the rate that you actually respond to requests from a given IP address. On the other hand, you have to be careful not to let the attacker spoof a bunch of _bad_ requests, causing you to blocklist a real site. Depending on how much eavesdropping capability the attacker has, this may be easy or hard.
The security advantage of this method over a single-port method with a password is that there are applications that you run which may have bugs in them, such as your SSH server or SNMP monitors, which you're not going to rewrite, and it lets you block access to them except from authorized users. It's a defense-in-depth strategy, possibly good (though it looks clumsy to me.) It can cut down on lots of the script kiddies.
Also, this doesn't have to be in your main server. This is the kind of application you could build into your firewall box, so it reduces the number of ports that can pass through the firewall, except when somebody knocked successfully, and the firewall doesn't allow passthough on the knocking ports. Of course, you could accomplish almost the same thing wiht better security by accepting SSL requests to an application on the firewall...
Re: Reverse-knock (Score:2, Interesting)
Not at all, and it's not a half-bad idea, but it's also not what the other poster was saying. He was talking about temporarily shutting down a service, which I interpret differently than firewalling a single IP out.
What I used is really just a variant of your idea, just taken to paranoid extremes. Instead of blocking just port 80, I blocked all of them. Instead of temporarily, it was essentially permanent, except that I was too lazy to work up a "save the updated rules automatically" script, so when I rebooted, those IPs could play again. Since that system had an average uptime of months, those IPs were effectively banned for quite some time.
encoding for noise rejection (Score:5, Interesting)
It adds security to any existing methods (passwords, etc.).
It can be implemented behind a firewall that doesn't even respond on any port probes, so an attacker can't even tell if the firewall was just unplugged.
If the firewall stays closed, the protocol can't be used by an exploited machine, unless a method for exploiting the firewall is also known.
Or the method can be implemented in user space of a machine behind a completely closed firewall, just by pre-arranging for the logging of firewall port probes, and the forwarding of appropriately filtered contents of the firewall logs into user space.
They key sequence can also be made long enough to make it just as hard to crack as a long pgp private key, e.g. nobody except (3 letter agency) and distributed.net will even bother to try.
The sequence key can be from a one-time pad, meaning that even if the protocol is completely revealed to a local sniffer, they'll just end up with a useless password.
And lastly, it's possible to additionally encode the key sequence with a modulation wrapper and enough redundancy to withstand a given signal to noise ratio and mis-sequencing rate, which means one could even make the sequence key usable in the face of probing or an outright DoS attack against the protocol up to a certain attack bandwidth and knowledge of which ports might be in the sequence.
Where's my coding textbook and patent attorney...
Re:Open a whole range of ports (Score:4, Interesting)
Sorry, wrong. There are several messages in this thread that mention REJECT (response to packet) instead of DROP (total silence). With this scheme in place, you need not listen on *any* ports, and you need not respond in any way. You can have a totally silent box, even with 10 or 20 services "listening". Nothing gets through until your iptables/ipchains software allows the traffic through.
Admittedly, if you're running a public site, you're mixing two kinds of solution --- publicly available vs secured, but analogous statements can be made here - you can't tell a public site using port knocking for some special services from a public site that doesn't support same.
This is like a void fn() in C (no return status). You knock on the 5, 10, or 25 ports in the right sequence to "send your message". You get nothing back. You then try to open the port that is your ultimate destination - if it's open, you're fine, if it's not, you have issues. This isn't a full-duplex kind of protocol, folks. I love it :-)
Thus, it is impossible to distinguish a totally silent box (listening on no ports, dropping all packets) that has implemented port knocking from a box that is merely totally silent.
As a two-laptop user who attaches to corporate LANs and public high-speed networks in hotels, I just love the idea of having all packets dropped until someone sends "shave & a haircut!" - then letting them in for a bit.
It would certainly be better than my current approach - using ethernet addresses (maclist in Shorewall! :-) to allow ftp and http etc to my linux box.
one way around it (Score:1, Interesting)
Seem quite vulnerable.. but neat for crypto!? (Score:3, Interesting)
On the other hand this does seem to be an interesting way to one-way send information to the server. I was thinking of playing solitaire using Bruce Schneier's algorithm [schneier.com] using a port for each card of a deck.
IANA cypherpunk, but there seem to be a number of ways to treat the set of all closed ports as a numerical space that would be interesting for encrypted communications.
For example you could convert a one-time pad, a private key, or a set of communication channels into a list of port numbers. For a short message at least, you could send with pretty good security (although the list of ports, if not their hash values, would be known to the outside world).
To me this knocking stuff sounds like it only *reduces* security and provides lots of interesting clues to men in the middle. The intriguing part seems to be that you can send a good deal of information through a large number of half-connections in parallel, but this may have already been tried by other people. Of course if the message is simple enough that a single ping to a single prearranged port number is enough to convey it, then you would seem to have a pretty strong system though its existence would certainly be uncovered sooner or later. But if this became popular I suppose the advantage would be in being able to assign certain ports to prearranged values, both for encryption purposes and also to reduce the amount of data you actually need to send.