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.
There are actually about 5 other known port knocking implementations. And it's such an easy thing to do, I'm sure many others have written their own private implemenations.
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
I wonder though. If port knocking is to become popular, will it be able to work through all of the blocked ports resulting from the excessive worm attacks?
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....'
Why use port knocking. It is no more secure than plain-text passwords. Use authpf. authpf can be set as the shell so when a user logs in authpf just changes the firewall rules.
This is an interesting idea, but not very secure. If there was, for example, a need to "knock" a server to activate some sort of access control, then anyone can send the TCP/UPD packets (AFAIK) someone correct me if i'm wrong.
Looks interesting though, but inetd could do the same thing.
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.
Personally, I'd like to advocate this... but can't
/. would spit on at the slightest mention.
Look at meat examples like the simple peep-hole in the door.
Every front door (esp. apartments) have a peep-hole in the front door to see who's awaiting.
So on the face, it's a good thing.
So a simple pass/fail concept online is good.
But I see no gaurantees against spoofing.
This idea is one that relies upon trust.
Trust in DRM concepts, which I am sure most here on
I would venture to say that anything DRM related needs to be regulated (for privacy relations) where individual actions (pr0n surfing -- it is a puritanical reality here in the US) should be insured against monitoring.
So ignore this post, I stand in the face of reason, and under Ashcroft my reason can not withstand. In fact, these words in 10 years time would stand as unrefutable treason as speech in the aid of terrorists.
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
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.
This is a replay attack. So don't use a static (replayable) sequence of ports for the knock sequence. Instead, require a dynamic sequence that is a function of the current time.
Exactly, this whole idea is stupid. It's a password sent one character per packet instead of all in the same packet.
As I said the last time this idea appeared on slashdot, if you want to hide a port from someone but make is still accessible to people who know the "password", here is what you do.
1) stealth the port by default, so it accepts no TCP connections.
2) Have the port silently listen for UDP packets. UDP is fine, because no acknowledgement is sent to the sender, so they don't whether you recieved the packet and ignored it, or if it never got to you.
3)When you receive a UDP packet, see if it contains the correct password. If it does, than you start accepting TCP connections for that IP address only.
At this level, this is just as secure as port knocking (password=port sequence). However, it has an advantage that port knocking doesn't. You can encrypt the packet with the server's public key, so that only the server can get the password out of the packet. You can also require that the packet contain an IP address in addition to the password and then verify that the IP in the packet matches the IP the packet came from. This prevents people from intercepting and replaying the encrypted UDP packet.
My cablemodem and DSL are sitting a couple of inches away from each other. Suffice to say they are both in the same city in SW MI, right?
Shortest external route is usually 16 hops through Atlanta. A friend in Virginia can see both of my portals in fewer hops than either can see the other. (Heh, just ran it again, 22 hops, no Atlanta this time, but I did see Philly and Chicago in the list).
So regionally close transits don't necessarily stay in their own region.
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.
I think it's not hard to write a simple wrapper around any SSH, FTP,... client. A simple shell script using netcat should do it.
No GNU has been Hurd during the making of this comment.
It's much less of a problem when DSL providers have policies like this, at least in the US, because usually the ex-monopoly telcos rent their copper to multiple DSL Layer 2 providers (often including themselves), and the DSL providers usually provide connectivity to many ISPs. So even if, for example, SBC DSL ISP service has some stupid policy, SBC provides Layer 2 access to many ISPs including Sonic.net and Speakeasy, who have friendly clueful policies, and they rent copper to Covad, who provide Layer 2 access to many more ISPs (sometimes with fewer connectivity options, e.g. maybe only SDSL or IDSL and not line-shared ADSL.) Sometimes these alternatives cost more - I'm paying about US$57/month for Sonic.net ADSL with four static IP addresses, vs. some of the newer loss-leader $29 deals from other providers.
Most other countries don't seem to have policies against being a Real User on your broadband service, at least if you're not commercially reselling it. Theoretically, this means that all those non-Americans out there should be creating lots of cool and interesting things to do with their broadband services, but I haven't seen much other than Yet Another File-Sharing System variants or some of the Asian grocery-shopping-on-line things that get magazine articles written about them but aren't very useful outside their local areas.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Why not have a port-knockd run on one machine to open ports on another. Now the sniffers must connect the knocks and the real destination ... a presumably even more difficult task.
This isn't that new.. I've been using he perl portknocking daemon (after heavily modifying it to support iptables instead of ipchains and some more robust code such as pulling the password out of the code in plaintext.) for about a month now.. works really well. No substitute for being up to date with patches and a good secure root passwd but given I can now just firewall off ssh except when someone knocks to come in it's pretty good.
I haven't looked at the way this is implemented (in true Slashdot fashion), but here's what I would do:
From client:
Send a random number, say [1-10] of port knocks, toward random ports.
Send the true port knock sequence, this has to complete before a certain time has elapsed.
Send a random number of port knocks again.
Wait a second or two, then connect to the real port.
Now, the server side waits for the first correct port and hence ignores you random garbage. Once your first port comes through it waits for a short duration (3 sec?) for the second port knock. If that comes across OK it waits for the next etc.
A wrong port from the same IP or a timeout causes the entire knock attempt to fail and get logged.
Once the correct sequence is sent, there is a random delay of a few seconds before the real port (e.g. SSH) is opened so sniffers can't tell exactly when the sequence started and ended within the total port knocks sent.
Now you are logged in, and since you are connected via some form of encryption (again, SSH or whatever) you are free to change the port knock sequence. Perhaps even done automatically every successful login, with a logged failback to previous sequence if you get out of sync.
Unless you log in to the opened port within 30 secs it closes and you have to wait 90 secs to send the sequence again.
You could additionally add individual sequences for static IPs (or even DynDNS?) or even certain individual logins allowed to authenticate after that sequence was received. I expect netfilter modules to be written to handle all of this.
By the way, anyone who thinks an open SSH port is *safer* than port knocking + SSH is an idiot in my opinion. The first discussions here were full of such comments, they seem to have died off as people decided to RTFA?
Still, port knocking is not the best option for frequent connects by many users, and can be DOS'ed with IP spoofing or some kind of packet injection.
What is the sound of one hand clapping?
cat
If you're in the position to sniff packets, you can very likely also spoof packets to come from the ip address which sent the kock that you captured. You could use timestamps, rate-limiting, client selected random seeds, etc, but the second point still stands: If you know that there is a knocking system, you're already past that line of protection. There are real protocols with strong cryptography handling authentication just fine. Adding another complicated scheme on top of it just increases the risk of introducing exploitable bugs.