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 though about this along time ago as a way of hiding a trojan. Of course I didnt patent it so no money for me : /
Im not here now... Im out KILLING pepperoni
Right now, script kiddies have their computers automatically try to access other peoples' computers, looking for ones without firewalls, etc.. If this happens, wouldn't you expect them to just send out random knocks in the hopes of getting something? If that happens, you will be more secure personally, but the increased traffic may cause more problems that it solves.
G
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.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
Think of it this way... it's an extra password combined with bonus security-by-obscurity of not having a visible password prompt.
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...
It should be noted that this is NOT (necessarily) an example of security through obscurity. One could treat the port-knocking sequence as a "key". Long enough keys could make port-scanning impossible for anyone who doesn't know the key. Real mathematical cryptography is based on a similar principle.
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.
-3Suns
~~~~
The Revolution will be Slashdotted
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...
What if multiple attempts from the same IP are made to access the port at the same time? Wouldn't the knocks get all mixed up?
Mad Software: Rantings on Developing So
Has anyone implemented a system where a service would be stopped if the ports next to it were scanned? i.e. if 1024, 1025, 1026, 1027 were scanned, a service running on 1028 would stop.
Improperly done, the knock sentry could become a security/QOS issue in itself.
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.
Implement it in combination with a onetime type password arrangement. You look up what the series of knocks is supposed to be on your secureID card (or whatever), then knock in the combination it tells you to use. Tie it in with the server you want to get into, and the port you actually connect to for ssh can be different every time.
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.
Casca
It doesn't have to be listening on the 'knock' ports, it can be dropping the packets and either logging the drop or setting a flag via some daemon. There are a million ways to tell if someone attempted to access a closed port without having to open the port. All of this, by my calculation, makes port knocking indeed more secure.
Speak for yourself.
Actually, an interesting potential of this is to have you "knock" at the NAT gateway. Proper knocking opens up a given service and knock ports to an internal system.
Different knock patterns at the NAT open you to different internal hosts. Quite interesting possibilities there.
That is the point.
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.
--
FreeNET user? Comfortable with the adverse selection?
One interesting way to use this would be to forward incorrect knocks to a honeypot instead of the legitamite service. Then the attacker could never determine if he had indeed knocked successfully and would waste time running around in a fake system giving you valuable data about there intrusion methods and freeing up the actual service for legit users.
This is equivalent to to putting a password on access to the port.
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).
This looks similar to how frequency-hopping is used on secure radios.
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
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.
, 655,932,542,976 possible knocks, a.k.a. "way the hell more then can be brute-forced".
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!)
i've been running SSH on a nonstandard port with this in the way:
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...
Keep your packets off my GNU/Girlfriend!
does it only open the port for that one IP somehow, using also advanced IP filtering, cause otherwise this is dumb, it would be like unlocking your door for the first customer to knock right, but having to leave it open the whole time the customer is shopping.
Anonymous Cowards - Oh God, How I hate you
That doesn't seem right. If the order of the knocks is important, how do you get around that there's never a guarantee in what order network packets arrive? If no packets are sent back at all, how do you know when to send the next knock or even if the knock made it to the server?
I see a lot of comments saying "Well, why not just have two passwords?". It seems that people didn't read the article (the first link is /.ed, the second is not). The whole point is that with this, until you knock, the machine appears as a closed machine. No ports open. All ports will simply drop packets on the floor, meaning that a hacker scanning your subnet will not bother with that machine. The machine essentially appears invisible until knocked. Even with the most secure system, the hacker can still see that you're running, say, sshd, Apache, CUPS, and a few other services. And if a buffer overflow was announced 5 minutes ago for, say, sshd, they know that they can attempt to exploit the machine, since they see port 22 open. If you are using Port Knocking, you can have a vulnerable sshd, and it's a hell of a lot less likely to get exploited since the cracker has no way of knowing that you're running sshd...
There is no sig, there is only Zuul.
This is security by obscurity, but it is useful. Don't repeat this mantra just because "the experts" say so.
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. 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.
now we need to go OSS in diesel cars
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.
You can also open up inbound ports from specific external IP addresses only, and do many at once. So ten inbound connections can reach ten different internal webservers, and at the next request, reach the same one again.
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.
This is a great idea.
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...
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.
Redundancy is good; triple redundancy is twice as good! - Me.