Slashdot Mirror
Port Knocking in Action
tyldis writes "There was something called "port knocking" mentioned on Slashdot earlier, and now an implementation has sprung to life. Is this something worth pursuing?" The page is to an application called knockd which is a simple proof of concept with
hard coded knock sequences. Really interesting stuff.
"shave and a haircut" into port numbers?
"Prefiero morir de pie que vivir siempre arrodillado!"
I can see this being used quite extensively in the warez arena. It'd be pretty easy to give out the "key" to clients who are allowed access, while any ISP scanning for FTP servers, for example, would find nothing open.
dmiessler.com -- grep understanding knowledge
pfft, XP has had this for ages....
This might be useful when ISPs routinely port-scan their subscribers to discover if their running services in violation of their TOS.
This will allow your computer to appear not to be running services expect to the person who knows the magic knock.
I'm betting that nmap binary is about to get much bigger...
Who's there?
Packet.
Packet who?
Packet up bitch, you've been hacked.
till we see virus/worms that install port knocked backdoors.
'virus x appears to open up 200 ports for no real reason, but it also has some remote desktop code in there too opened on a firewalled port....'
is pasmal
This sort of clandestine type of communication has been known about in the security community for a long time - pretty much since the ARPA days. Some backdoors used specific sequences of TCP flags, with no practical TCP use other than opening a backdoor, but permitting anonymous communication or command broadcasting.
With access to a TCP stack and a link-layer sniffer, you can send and receive, respectively, commands to ghosts in working machines, transparent proxies or "harmony" devices. It is good to see this sort of thing coming to light, since it is extraordinarily powerful and not very well known.
An example of these probing commands are Xmas, Fin, and Null scans for Fyodor's nmap; note that other TCP flags (TCP options, in particular) can harbour substantially more information than the flags alone.
Unfortunately, in the modern age of macro viruses, it is hardly necessary to be skilled or even aware of such devices to write a devastatingly powerful virus.
passwords and port knocking are two different things.
A perfect example of what it could allow to be done is on knockd's homepage.
Basically, ssh would not be an open port, you'd have to knock (connect to) the right sequence of ports, which would trigger a rule that could allow only the IP that made the successful knock, access to the ssh port.
Then when your done you would have another sequence of ports you'd have to "knock" in order to remove the rule allowing access.
You'll find some more stuff on http://www.portknocking.org...
I remember talking about port knocking and its inherent sniffing vulnerability previously.
;) I'm currently implementing a c++ networking class for a project with port-knocking built in, and it uses the timestamp method. (Of course, they all have to compute the timestamp for one zone, GMT or wherever)
Basically, if someone can sniff the sequence of packets, they can get your static knock sequence.
However, if you base it on their IP perhaps, or add in a timestamp (ie, on this date, at this time, you must do this sequence) then it would make port knocking a much more effective method of deceiving attackers.
You could also do something where knock sequence would be a form of one time password. So you would have a list of valid knocks that could only be used in order. Each person could be given a "block" of these one time passes, or the sequences could be generated on the fly as other current implementations of one time keys are.
There are lots of great possibilities, if only I were smart enough to think of them
"Sed Quis Custodiet Ipsos Custodes?" -Juvenal
Meh, throw some cryptography into the mix.
Take the source IP, add a password, take a one way hash. Include this hash in the knocking packets.
Now, if you've sniffed the packets, then you won't know the password. So, you can spoof the source IP, in which case the port will be opened _for that IP only_, or you can send the knocking packets from you IP, in which case, you need that password, or you've just advertised yourself as a hacking attempt.
In order to prevent a single password for everyone situation, it's not hard to include a user ID in the packets.
Does need the application or firewall to allow connections to and from specific IP's only - but I really can't see that being an issue.
Problem solved.
Off the main topic, but regarding comcast ...
I've spoken with several reps at Comcast over the past year. They don't really care what servers you run. (I've been told this explicitly as well as tacitly) In fact, when I first contacted tech support, the guy had no idea what SSH, Telnet (ssh is like an encrypted telnet, right?) or even what a port was.
I've been running an ssh server for about 8 months uninterrupted, now. The general rule of thumb seems to be - If you don't cause trouble for anyone else, Comcast won't cause trouble for you. So, in that interest, I impose reasonable caps on my own throughput and connection counts, and I've had no problems at all.
Sniffing the sequence allows a replay attack.
The correct implementation is to listen in promiscuous mode for any packet containing a small, known header, then inspect the rest of the packet for a gpg-signed request to open a port or service, or alternately initiate a connection. Only the possessor of the private key can make a request (attacker's attempts fail the signature check), a man in the middle cannot decrypt the contents, and replay attacks are defeated by the timestamp.
-1, Security by Obscurity.
A number of people have commented that because the port knocking sequence is transmitted without any form of encryption, port knocking is insecure. I disagree, on the basis that port knocking is not an access control measure, but rather a deterrent measure.
If you intend for port knocking to stop determined, targeted attacks, then yes, you are sadly mistaken. However, port knocking is effective in making your host less attractive to be hacked.
I think that an limited analogy is the removable stereo faceplate. Car stereos are a hot target for car thieves. A car thief sweeping a parking lot will not spend time on cars where he does not see the whole stereo (faceplate included).
By hiding the faceplate, you make yourself less likely to be a victim, even if you just leave the faceplate in your glovebox. If the thief saw where you hid your faceplate, then yes, he could pop it back in and have your stereo in the 30 seconds it takes him to yank it out. But he would have to be watching you. This would be akin to packet sniffing.
Likewise, someone scanning for a host is looking for evidence of a particular (vulnerable) service. If he doesn't see that service on your PC, he just moves along.
It gets better than that. Just imagine a honeypot connection for people who don't port knock. That way there is a better measure of security through obscurity since non-port knockers believe that they're actually getting through the systems' defense layers.
Well at least I used to build them in. It was so simple many others must have done the same thing. Take a 10-step relay, put a 1 minute reset timer on it, and wire each of the first few steps to a pulse gen anded with one of the incoming lines' ring detect. If the right sequence of incoming calls happened, it connected a separate incoming WATS line to a WATS outgoing line. Viola! Free calls from anywhere to anywhere, and nobody would ever notice if you were careful to only select "unlimited" outgoing WATS lines. We're talking something like 35 years ago here...
Most of the arguments here against port knocking are along the lines of "but someone could just do a replay attack" or "this is vulnerable to spoofing" or whatever. These things are true about a naive implmentation of port knocking that uses a static knock, but it's not hard to come up with variants on the port knocking idea that offer much better security than that. For instance:
The secret key of course has to be kept secret, and the underlying crypto must be good enough that if the attacker sees the challenge and the knock sequence used to reply, the key itself cannot be deduced.
This would completely protect from replay attacks, as knocks are not reused. Spoofing could potentially be used to DOS someone by interfering with their knock sequence, but not to gain unauthorized access oneself.
Sure, at first glance port knocking may seem to be of limited usefulness, but if you combine the idea with a little cryptographic thinking, the possibilities start to become a lot more exciting.
The idea in the grandparent post wasn't a challenge-response in the traditional way. It was some authentication data along with the knocking.
The knock won't be encrypted, but it will have some data that is characteristic of the source (the source IP) that can't be spoofed (because of the password and the one way hash).
An example of this would be:
1.Real owner takes his IP (public info)
2.Real owner takes his secret password (known only to him)
3.Using IP and password he computes the hash and sends it in the knocking packets (let's say it's in the IP id)
4.The receiving system captures the knocking packets and takes IP source and the hash
5.It reads the secret password (from config file)
6.It calculates the hash with the source IP and password
If the hash sent and the hash calculated match, the system "accepts" that part of the port knocking. If not, discards the packet.
An intruder might only spoof the whole packet (including IP source) and might open the firewall only for that IP. If he tries to use the hash to open it for HIS ip, the calculated hash won't match the hash sent. He cannot calculate the hash he would need because he does not know the password, and the hash is one way.
In this protocol the target system does not need to respond with a challenge, it just discards packets that are "spoofed" (that have a non matching hash).
GPG 0x1B479C78
Why not just mod me up instead? I provide links!