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."
The idea was that you didn't want to disclose that you were running a Freenet node unless the person connecting to you already knew your node's public key.
So when someone wants to establish a connection to you, they must send some encrypted data providing they know your public key. Your node can receive this data and only respond if it is correct. Furthermore, you could let your Freenet node sit on port 25, for example, and forward invalid connection attempts to a mail server on a different port.
Through this mechanism, your Freenet node could quite effectively hide behind another server, only making itself known to those already part of the Freenet network.
IIRC this wasn't actually implemented in Freenet, but it is the intention to add it at some point. Still, it is amazing how many ideas were pioneered by Freenet years ago and are only showing up in the wider public conciousness now.
The shady side of hackerdom has been using this very technique to hide their backdoors from port scanning admins. Or, uh, so I've heard...
Also, its not used for the only password. It is added security. Only people who can intercept packets for the host can replay the sequence. This prevents whole sale port scanning being productive.
Im not here now... Im out KILLING pepperoni
Somebody do the math, but it doesn't look to be that secure. Brute-forcing this would not take long.
Assuming a 5 'letter' password, you have (2^16 - 1024)^5 possible passwords, which is 1.1 X 10^24. Assuming both the server and the attacker are on fat pipes and the server is implemented in a dumb way so that it doesn't recognize brute-force attempts, you could pull off perhaps 100 attempts per second. So it would take you about 10^22 seconds, or 350 trillion years.
In security, I think this technique is comparable to a reasonably strong plaintext password. It can be sniffed, but it can't really be brute-forced.
Today's show was brought to you by Google Calculator.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
Any heavily accessed server would have to keep track of source IP. If the knock is abandoned by accessing the wrong port nobody would be allowed to enter as a new knock would start before the previous was finished.
And if you track the source IP it is trivial to only allow connections from that IP to the server.
How many people are going to say sniff and repeat the sequence. You still have to get through the service after it opens. The whole point is that they don't know what is going on in the first place. And rotating keys are a good idea anyway. I like this idea for running some kind of server behind your ISP that normally doesn't allow such things. When I had excite@home I would regularly get firewall logs that said "authorizedscan.home.com" portscanning me.
the 'hammer' will have a different IP than the authorized 'knocker'
every day http://en.wikipedia.org/wiki/Special:Random
Unless the port was only open to the source that successfully knocked.
And the packet sniffer wouldn't be required at all if the port was just open to everyone all the time.
Hence, weather or not it is secure, is all a matter of opinion. Personally, I think if you can't run SSH out in the open, you shouldn't run it thru an obscurity filter.
We have no SSH configured on our outside network. Not with OTP, not from only allowed IP's. Not from only a specific port. Not with KnownHosts only. Not with known RSA keys only.
You want on, you've gotta be in the building. It'd be nice to fix problems while remote, but it's just not an option because of the security problems it presents. I live within a mile of the building, specifically so not having remote access isn't a big deal. I can go from sleeping in bed, to in the building in less then 10 minutes. It's a pain for small problems. However, it's small issue in comparison to dealing with a full blown network breakin due to SSH.
On occasion, I believe we have had someone local build an SSH tunnel that we can VPN thru onto our network. However, someone who already had access had to initiate the connection by hand with the correct IP. That's only allowed if we voice authenticate from you.
Kirby
Any good admin knows the most secure system is one that is listening on as few ports as possible.
Is zero secure enough for you? The ports used for knocking are not open. The knock is the connect attempt which is recorded as an event on the server. The client gets nothing, not a NAK not a reset, nothing.
Let's say the correct squence is ports 2000, 2002, 2004. You could add a check that says if there is a knock on port 2001 or 2003 then this guy is locked out for a while.
on debian-security a couple of months back.
Anyway, one of the biggest problems is failure rate. If that "secret knock" fails unless you correctly use the appropriate sequence of knocks, then anyone malicious can implement a trivial denial-of-service attack just by constantly hitting random ports, preventing any knock completion.
Alternatively, if you ignore non-knockable ports, or ports that aren't part of the knock, then you've dramatically whittled down the strength of your virtual password, and made it that much easier to brute-force.
Perhaps this would deter some of the lowest levels of sk|21p7 |<1dd13z from getting in, but that would be true only for about two weeks, whereupon new toyz are released that automate these attacks, and you've given the black hats one more weapon (DoS through spoofed noise packets) in the meantime.
I guess if you really, really wanted to do this, you could have a single accessible port that would listen for access, and then receive an encrypted key that determines which other port your server opens for a possible connection. But basically all you're doing then is adding on another layer of password protection, whose effect will be circumvented when somebody finally decides it's annoying to have to login twice or enter multiple passwords, and sets them both to the same thing, on auto-login, then leaves his laptop sitting around for three minutes. And you've still not fixed the sniffing problem. There are bigger security soft spots to be addressed than trivially hiding access to your ssh port.
Freedom isn't free; its price is the well-being of others.
This method is already used by the proof-of-concept linux backdoor cd00r, written in 2000.
The summary says that the ports to knock on are closed. Portscanning shouldn't reveal which ones are available to be knocked on.
University - a box of academia nuts.
Most switches have, uhh.... "features" that allow an experienced attacker to trick them into broadcasting traffic to multiple ports.
Essentially, with a little judicious arp spoofing and a flood or two, the switch can be confused into just "making sure" the packets get to the right destination by broadcasting like a hub when it would normally be switching.
The party of stupid and the party of evil get together and do something both stupid and evil, then call it bipartisan.
Everyone has focused on the "does it make you more secure" arguments about this method. I'd be more interested in how it can be implemented properly since no TCP connection is being established using the knocks. I'd assume either a TCP SYN is being sent to the TCP ports, or the protocol uses UDP.
.9^10, or 35% chance of my sequence getting to its destination intact. 5% packet loss would up my chances to about 60%. Increasing amounts of knocks decreases my chances of the sequence arriving intact.
The problem is of course that since no connection is being established, there's no guaranteed delivery of packets, and no guaranteed delivery of packets in the order they were sent. This could be very problematic across network connections that drop packets, and provide you no feedback as to why you can't open your connection. If only 10 % of my packets get dropped, and I require 10 "knocks", I only have
Is there a clever way to solve this problem, or is the reliability of it tied to a low amount of packet loss on a network?
AccountKiller
Host 'a' (the server, 192.168.0.1) requires the correct knocking combination to allow access. Host 'b' (random knocker, 192.168.0.2) knocks on random ports attempting to cause a DoS. Host 'a' detects the wrong ports being knocked on and does not grant access from host b Host 'c' (geniune client, 192.168.0.3) knocks on the correct ports, host 'a' allows access from host c (192.168.0.3/32). Host 'b' can continue knocking on random ports, but at the same time, host 'a' does not grant access from the misbehaving host b, but it doesn't have to revoke access from host c either.
.1, I'm .2 and you're .3, I just keep knocking ports at random spoofing my ip to say that I'm .3 You can't IP block me, and my knocks look just like your knocks. This keeps screwing up your login and you can never open the connection.
So how does this cause a DoS?
The ports being knocked are closed. This means that the server can never veify the the knocks coming from 192.168.0.3 are really coming from there, or if they're coming from 192.168.0.2.
If the server is
Life is too short to proofread.
It is a common misconception that an attacker can't tell a system which doesn't send reject packets from a system which is disconnected/off. This is not true. The difference lies in the reply from the next hop router. An existing system will not cause a response from the router, but you will get a "Destination unreachable" ICMP packet from said router if the target system is offline. This is because the router times out the target system's ARP entry and then, when the router needs to reach it, can't find the target if it is actually offline. A connected system cannot not answer arp requests (or it doesn't get its packets), so the router always knows where to send the packets and doesn't return "destination unreachable".
Kris Gleason implemented a similar scheme in his gettyps code back in the 90s (it still available and in most distributions). For the "knock" one would dial into a modem (or any serial port) and let it ring a specified number of times. If the right number of rings was received before disconnect, gettyps would allow the next call to connect.
Michael.
Linux : Mac
When a process is listening for new connections, it doesn't block existing connections from carrying on sending and receving data
When a port is 'connected', it means that a process has an established connection to another host.
Therefore, no, just because a port is not listening/open, doesn't prevent an existing connection from sending and receiving data.
If that was the case, then the first person to telnet/ssh to your box would tie up that port and a second connection would be blocked until the first had freed up the port, however that is not what happens at all.
All they're saying is that when the portknocking daemon detected the correct knock sequence on closed ports, it starts a process to LISTEN for new connections, ideally from just the host that did the knocking, for a limited period of time (10 seconds). Once a TCP connection is established with the listening host, that host no longer needs to listen, and that's why it stops after 10 seconds.
http://www.portknocking.org/view/about/obscurity
It does a much better job of explaining this than anything yet posted here.