"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."
security through obscurity again? (Score:0, Informative)
Silent Bob (Score:5, Informative)
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.
Old Idea, Different Use (Score:5, Informative)
Re:not bad (Score:3, Informative)
But I don't think the intent is to prevent people sofisticated enough to actually sniff packets from being able to enter the network, but simply stop script kiddies and worms that are rather mindless in their attacks. I am not aware of any worms that would be able to sniff packets and actually interpret what is happening.
Re:Invasive Security (Score:4, Informative)
Re:Brute Force (Score:5, Informative)
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.
Re:not bad (Score:3, Informative)
Re:I see an easy way (Score:3, Informative)
And if you track the source IP it is trivial to only allow connections from that IP to the server.
Christ people! (Score:5, Informative)
easy way to secure (Score:4, Informative)
Re:I see an easy way (Score:3, Informative)
And the packet sniffer wouldn't be required at all if the port was just open to everyone all the time.
Re:Oh, really. (Score:2, Informative)
Re:Oh, really. (Score:3, Informative)
Plus, thing about it this way:
* someone notices an SSH connection
* someone portscans, notices port 22 is closed
* someone thinks, "hm, there was that
* someone waits around for you to re-connect, and watches what closed ports you connect to
See? that easy.
Re:not bad (Score:5, Informative)
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
Re:Well, there go the logfiles (Score:5, Informative)
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.
Re:Well, there go the logfiles (Score:2, Informative)
Re:Slashdotted? (Score:1, Informative)
Negative knocking (Score:4, Informative)
This was discussed extensively... (Score:4, Informative)
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.
Already used by backdoor (Score:3, Informative)
Re:Promiscuous mode (Score:3, Informative)
Not if your network is using a wired switch to connect the hosts. By definition, you should only see broadcast and unicast to your IP, not the whole network. This could be more of an issue if you are using a shared network link 10base2 or 802.11.
Re:Open a whole range of ports (Score:5, Informative)
Re:replay? (Score:2, Informative)
Re:Well, there go the logfiles (Score:1, Informative)
Yes, it does. And thats the point. You're still expending resources monitoring the port, and (presuming it does catch on) you're still responding. You're just not responding in the RFC-approved way.
For now, you'd be gaining some added keyspace to your theorhetical access path, while at the same time introducing a lot of complexity (thus potential compromise points).
At best, you get some added protection from the diversity. At worst, it's just another false sense of security through obscurity blanket.
I'll pass, thanks.
Re:Well, there go the logfiles (Score:2, Informative)
Sadly, most people who probably think port knocking is great security probably have yet to learn how to use DSA keys.
Personally, I keep a DSA key on a keychain USB device and only allow one IP access to my sshd. This is adequate to satisfy my level of paranoia.
Re:Promiscuous mode (Score:5, Informative)
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.
Re:One-time port knocking? (Score:3, Informative)
TCP/IP problems with this method. (Score:5, Informative)
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?
Re:replay? (Score:3, Informative)
Quite a bit better, since it is easy to scan 65k ports serially to see which ones are listening, but much harder to scan a jillion combination of port sequences to see which ones are listening.
Re:Not good (Score:1, Informative)
Not true.
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.
So how does this cause a DoS?
The server doesn't have to grant access from 0.0.0.0/0 when a single host knocks correctly, or did I misread the article?
Re:Not good (Score:5, Informative)
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
Re:Promiscuous mode (Score:2, Informative)
Switched networks are definitely not safe from sniffing, it just makes more "noise" to do so.
Re:not bad (Score:4, Informative)
gettyps (Score:4, Informative)
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. [michael-forman.com]
Re:Well, there go the logfiles (Score:2, Informative)
You're not quite right here - all knocking in the correct sequence does is make the specified port AVAILABLE - nowhere was it stated that port would 'just start working'. In the example given, using ssh, a correct ssh login/password pair would ALSO need to be provided - so to correct your metephor, the door is still locked - it's just not camoflauged anymore - now everybody can see the door is there - though they still need a key.
To correcct my own metaphor - the door, furthermore, according to the example, would only be visible for, say, 10 seconds - at which point it's cloaking device turns on again, waiting to present the keyhole to the first correct secret knock.
Re:TCP/IP problems with this method. (Score:2, Informative)
Re:Well, there go the logfiles (Score:2, Informative)
Also, how could I be right or wrong, I asked a question. Also you didn't answer if it had a way of allowing that port to be open for just the IP using it, otherwise the port would have to appear open, because it is open.
A) RTFA - the port doesn't just always close after 10 seconds - it listens for a connection for 10 seconds. It none is made (ie, successful login), the port closes up all hidden again.
B) You claim, back to back, that (1) you didn't ask a question, and (2) I didn't answer your question. Which is it? It can't be both.
I'll answer - of course you can specify only the IP that knocked correctly can get in. With linux, your imagination is about the only limit. Are you sure you're in the right place?
And, again, just because a port is 'open', doesn't mean anyone can just waltz in - that depends entirely on the service running BEHIND the port - in the case of SSH, yes, the port will let you 'get in', but without entering the correct username and password, it kicks you right back out.
Re:Well, there go the logfiles (Score:5, Informative)
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.
Re:Well, there go the logfiles (Score:2, Informative)
The idea that a port wouldn't respond until the proper knock had been received might be a good one. But there's no reason to overload the port setting in the TCP header to do this. Include the knock values in the payload of the packets that are sent prior to the server sending back an ACK. It'd be just as secure as this setup (i.e. still vulnerable to sniffing.)
security through obscurity? no sorry (Score:5, Informative)
http://www.portknocking.org/view/about/obscurity [portknocking.org]
It does a much better job of explaining this than anything yet posted here.
Re:Promiscuous mode (Score:1, Informative)
Yes, and many managed switches allow you to lock the mac addresses for that port. Very handy to prevent mac address/arp spoofing.