Port Knocking in Action 430
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.
Comment removed (Score:3, Interesting)
Great for warez... (Score:5, Interesting)
Port Knocking Needed (Score:2, Interesting)
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?
how long till... (Score:5, Interesting)
'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....'
authpf? (Score:5, Interesting)
knock-knock (Score:3, Interesting)
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.
Interesting (Score:5, Interesting)
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.
The Power of Simplicity (Score:0, Interesting)
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.
Time based defenses (Score:5, Interesting)
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
Re:authpf? (Score:3, Interesting)
I'm not sure that authpf corresponds to port-knocking's subject-matter.
You can make port-knocking more "secure" than encryption; you can use a time-synchronized one-time pad to construct and vary the ports, flags, TCP options, sequence, etc., to come up with a system both unique and impossible to duplicate, absent the one-time pad.
As one-time pads are provably secure, you can create a system that bars or ignores all communication except the effectively random knock that unlocks the door.
Re:Port Knocking implementations (Score:5, Interesting)
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.
Re:Knock Knock? (Score:2, Interesting)
Re:About as secure as telnet(1) ie not. (Score:5, Interesting)
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.
Re:Sniffing only works when on that network. (Score:1, Interesting)
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.
Re:Time based defenses (Score:2, Interesting)
You are correct that if you have a static knock sequence, that's not that good. However, if you have ever-changing sequences that combines time windows with other external factors, then unless you knew the sequence beforehand (since it changes everytime), you would have no way to guess what it was besides running a brute force attack, which is outside the scope of this sort of defense, since it brings into account lots of other issues liked using spoofed packets to DOS IDS/IPS etc.
Re:Knock Knock? (Score:5, Interesting)
Re:Great for warez... (Score:2, Interesting)
If, on the other hand, what you want is extra security - well, that's what strong encryption is for. Port knocking is more on the level of ROT13.
Used to be done in phone systems (Score:5, Interesting)
More secure than people think (Score:5, Interesting)
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.
Re:Great for warez... (Score:2, Interesting)
Re:one of many (Score:3, Interesting)
I suppose that having passwords on user accounts is silly, too, because some rogue program could log keystrokes and post them to the web.
Re:Great for warez... (Score:4, Interesting)
Re:Port Knocking implementations (Score:3, Interesting)
Anti-Server Broadband Monopolies (Score:4, Interesting)
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.
Port Knocking and Sniffing (Score:1, Interesting)
Hrmm (Score:1, Interesting)
Re:Knock Knock? - How to secure IMHO. (Score:3, Interesting)
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.
Re:Parent is wrong (Score:1, Interesting)
Re:Used to be done in phone systems (Score:3, Interesting)
I work with a former phone engineer who told me about a night in the exchange - the place was very quiet, and then at 8.00pm, all the switches started going, building into a massive crechendo of sound, the entire exchange turning into a deafening cacaphony of selectors...well, selecting. He said it was spooky. He shortly afterwards discovered the event that prompted all this activity was the dramatic end of an episode of a primetime TV soap.
One of the things that surprised me was all the tones were generated by essentially a big electric motor driven thing (I think Light Straw has some samples of the tones along with an engineer testing the thing). I'm just old enough to remember the last Strowger exchanges (our local exchange went digital in 1989 IIRC) and I sort of regret not badgering a BT engineer into letting me in the building and watch this thing go. Perhaps I'm just a bit too geeky, but I love electromechanical stuff.
Digital phone exchanges seem so...dead...by comparison.
The Grumman Cheetah is a neat plane, the Association of Manx Pilots have one which I've got a few hours in. Probably the best nosedragger single in my budget