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)
Re:one of many (Score:4, Funny)
Re:one of many (Score:5, Informative)
Port Knocking implementations (Score:5, Informative)
A few implementations [portknocking.org] here.
I don't think will be very useful/valuable until clients (such as ssh) have it built in. I don't feel like going through the hassle each time I want to connect. Though it would keep comcast from discovering my ssh service...
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:Port Knocking implementations (Score:3, Interesting)
Re:one of many (Score:3, Funny)
your carefully constructed secure zone.
I'm going to stay a mile away from anything that
brings on board a 'knocker'...
I'd hate to get knocked up.
Re:one of many (Score:5, Insightful)
Well, yes. That's the point: to enable access to a secured system. It's often a necessary evil. The issue is that most people implement these deliberate holes by leaving certain ports open to simple direct access. They're easy to find, and not all that difficult to exploit. Adding a layer of obscurity and another layer of security on those holes - in effect putting a concealed combination lock on them - would be a more secure way of doing that.
Re:one of many (Score:3, Insightful)
automated it no longer is the user that sets
it up but some - untrusted - application like
say the next cool file sharing program. Next
a bug is discovered and *bang* millions of
previously firewalled machines are suddenly
wide open.
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:one of many (Score:3, Insightful)
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.
Re:one of many (Score:3, Funny)
Used to be done in phone systems (Score:5, 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 tu
How do you transcribe... (Score:5, Funny)
Re:How do you transcribe... (Score:5, Funny)
Re:How do you transcribe... (Score:3, Funny)
Four, of course!
Re:How do you transcribe... (Score:2)
"shave and a haircut" into port numbers?
don't think it'd be useful because you could specify no more than four ports (or maybe just one of four ports). just two bits, you know. [google.com]
Re:How do you transcribe... (Score:3, Informative)
s$ = "shave and a haircut"
FOR i = 1 TO LEN(s$) STEP 2
IF i LEN(s$) THEN
PRINT ASC(MID$(s$, i, 1)) * 256 + ASC(MID$(s$, i + 1, 1))
ELSE
PRINT ASC(MID$(s$, i, 1))
END IF
NEXT
Output:
29544, 24950, 25888, 24942, 25632, 24864, 26721, 26994, 25461, 29544, 24950, 25888, 24942, 25632, 24864, 26721, 26994, 25461, 29544, 24950, 25888, 24942, 25632, 24864, 26721, 26994, 25461, 116
Re:How do you transcribe... (Score:5, Funny)
Re:How do you transcribe... (Score:3, Insightful)
Am I the only one who's noticed that these perl implementations all contain a bug which the original QBASIC one didn't - if there's an odd number of characters the last one is ignored, whereas it should really be counted somehow.
Although the QBASIC implementation put it in the least significant byte; I'd be tempted to put it into the most significant byte, effectively padding the end of the string with an extra zero.
Re:How do you transcribe... (Score:2, Informative)
Knock Knock (Score:4, Funny)
Re:Knock Knock (Score:2, Funny)
Port to MIDI interface (Score:4, Funny)
I want to get "shave and a haircut" ported over to the new protocol.
Re:Port to MIDI interface (Score:2)
Or if you're really bored you can transcribe each note into hex via an old commodore 64 with DMC music composition software or the excellent JCH composer. Convert that hex back to regular digits and those are your ports.
Great for warez... (Score:5, Interesting)
Re:Great for warez... (Score:2, Insightful)
Re:Great for warez... (Score:5, Informative)
Re:Great for warez... (Score:4, Interesting)
Re:Great for warez... (Score:3, Funny)
Re:Great for warez... (Score:3, Informative)
Re:Great for warez... (Score:3, Insightful)
<tongue in cheek>
If you had an ISP that was port scanning for open FTP servers on port 20, why not just move your port to another port with well known use for home users, like 135?
</tongue in cheek>
Re:Great for warez... (Score:2)
Re:Great for warez... (Score:3, Funny)
Shhhh.... Don't mention the trojans.
Re:Great for warez... (Score:3, Informative)
You connect first to the server, it then queries your machine on 113 to see if you are who you say you are and let you in(or not).
How is a server supposed to know to ident you if the ftp port isn't open first?
Knock Knock? (Score:4, Informative)
Just a bunch of hackers knocking with sequences they captured from sniffing.
Sniffing only works when on that network. (Score:5, Insightful)
What that means in real life is that someone would have to be connected somewhere along the route from your machine to the server you're knocking on.
I am in Seattle, I can knock on my server from another location in Seattle. Someone in Canada will not be able to capture any of my packets.
Port knocking allows me to run a service on the Internet and not worry about just anyone from anywhere connecting to it.
Re:Sniffing only works when on that network. (Score:4, Informative)
Seems my office was 2 miles down the road from my house - traceroute from my house in Portland, OR to my office went through both Seattle AND MAE-West (Bay Area, CA)
Many external countries only have external connections to the USA, not directly to each other (don't know how true this currently is - but several asian countries used to have to hit the W Coast, USA to get between each other)
Re:Knock Knock? (Score:5, Insightful)
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.
Re:Knock Knock? (Score:4, Informative)
If you decide to send a challenge to the knocker, you could just as well use regular authentication over a TCP channel.
The point of port knocking is to hide the existence of a regular channel, not to protect it from someone who knows that it's there. Someone who can sniff your packets is by definition already past that layer of protection, so any attempt to complicate the knock-layer will only increase the chance of creating another vulnerable interface. Keep it simple or don't do it.
Parent is wrong (Score:5, Informative)
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).
Re:Knock Knock? (Score:5, 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
Re:Knock Knock? (Score:5, Informative)
Re:Knock Knock? (Score:2, 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?
Re:Port Knocking Needed (Score:4, Informative)
Worms port knocking? That would be one very very very slow moving worm!
Remember. There are 65535 different ports available. So, given that you can repeat port numbers and one uses a 4 port "combination", you get this.
65535^4 = 18,445,618,199,572,250,625 different "combinations"
I'm not even sure how to read that, but I doubt a worm would try it. It might take it a while.
old (Score:5, Funny)
pfft, XP has had this for ages....
ISP Port-Scanning (Score:5, Insightful)
This will allow your computer to appear not to be running services expect to the person who knows the magic knock.
Re:ISP Port-Scanning (Score:2, Informative)
Fyodor must be busy... (Score:5, Insightful)
Port knocking not exactly a new idea.. (Score:3, Funny)
Oops, that's Microsoft port knocking.. never mind, sorry, I guess it is new to Unix..
Knock Knock (Score:5, Funny)
Packet.
Packet who?
Packet up bitch, you've been hacked.
If this box is rock'n... (Score:2, Funny)
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....'
Re:how long till... (Score:3, Informative)
At least, this is how the implementation this article mentions does it (or advertises it does). I've yet to thumb through the code.
Re:how long till... (Score:3, Informative)
Also, the first sentence from portknocking.org: "Port knocking is a method of establishing a connection to a networked computer that has no open ports." A little further down on the page: "This is a form of IP over closed ports."
Also, you may wish to read the FAQ: http://www.portknocking.org/view/faq [portknocking.org].
Re:how long till... (Score:3, Informative)
There are several products that implement similar concepts. Take a look at bridging firewalls. Neither interface on the bridge has an IP address but can still inspect packets and take action as required.
authpf? (Score:5, Interesting)
Re:authpf? (Score:5, Insightful)
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.
Re:authpf? (Score:2)
Re:authpf? (Score:3)
Authpf *IS* another layer (Score:3, Insightful)
There are some tradeoffs - knocking systems are usually lightweight, while authpf is probably more thorough, especially about making sure
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.
Re:authpf? (Score:5, Informative)
16: dest. port
16: src port
32: seq id
6: flags
16: window
16: urgent
40: options
That gives us an alphabet 2^142 ~= 5.6 * 10^42. Not to mention that a sequence of packets can be combined, extending the language. Indeed, its cardinality is a natural ordinal, so the same as any password, if not more, by virtue of passwords being limited by an input buffer.
Knocking need only finite state between packets, simply indicating a status of "last packet correct knock?"; successive knocking therein is in a cardinality greater than passwords. Knocking can happen over a period of months (as I have seen it), and be virtually undetectable for all but the most sophisticted (ie. expensive) means of detection.
In combination with a time-synchronized one-time pad, you can generate an unrepeatable, provably (in the mathematical sense) secure system of access or commands. For example, for the minute of 13:01 EST, there can be a specific TCP packet, or series of packets that unlocks the door or executes a command. At no other predictable time would this knock be useful. (Time synchronization here is an issue, but often this attack will be used on machines that do care about an atomic clock sync).
You can do the same thing with a password over SSH, but that's higher level, using more complex code, and inherently more likely to succumb to high-level assaults such as buffer overflows, as well as mathematical assaults on the encryption itself, both of which fundamentally compromise the system's security.
In short, time-synchronized knocking is safer, simpler, and smarter than passwords or encryption for a certain number of niche applications.
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.
Security (Score:3, Insightful)
If I understand it correctly, this could be very secure. Imagine trying to guess the combination of a combination lock where each port number represents a possible number of the combination, and the combination is of unknown length (e.g., a combination 3, 5, 45, or 105 numerals
Another implementation (Score:5, Informative)
Nice start (Score:5, Insightful)
It would be nice to be able to use one-time pad to generate the port sequence. By changing constantly, it would be almost impossible for passive listeners to snif the port sequence.
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.
Re:Interesting (Score:3, Insightful)
How can you consider this any more secure than a password prompt? It's simple old obsecurity. There are less combinations of TCP/IP flags than there are letter/number combinations, so a flag-based system is easier to brute-force, not harder.
Once your worm has been decrypted, everyone will know what TCP flags need to be set, and anybody can connect. It's not like you're going to fool anybody here.
About as secure as telnet(1) ie not. (Score:3, Informative)
Re:About as secure as telnet(1) ie not. (Score:2)
Re:About as secure as telnet(1) ie not. (Score:3, Insightful)
It's all about layers of security (Score:4, Insightful)
I think it fits in great as a layer of defense.
Is there an easier way to weed out the attempts from all of those script kiddies and worms to get into certain services on your network?
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.
Why is this more secure... (Score:5, Insightful)
Re:Why is this more secure... (Score:3, Informative)
Ethernet has a exponential-wait scheme to prevent cloging of pipes, and TCP uses a authorized sent only packet. No data is send until prior ones are OK'ed.
Re:Why is this more secure... (Score:3, Insightful)
portknocking.org (Score:5, Informative)
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
So how do you 'start' this? (Score:4, Funny)
>/etc/rc.d/rc3.d/s95Knock UP
?
So there I was (Score:4, Funny)
It's broken, and the real solution is simple (Score:5, Insightful)
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.
Re:It's broken, and the real solution is simple (Score:4, Insightful)
Responses to assertions that this is insecure (Score:5, Insightful)
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.
A different solution (Score:5, Informative)
These kind of things are not ment for full access, only by allowing you access to the daemon which still has its own acl. When you travel sometimes you're not aware of what IP address your laptop will have so you set a dns query to your home machine which opens the SSH port for you. The whole point is to prevent random attacks from people scanning vulnerable daemons. The following are links to Brian Hatches explinations and code.
Part 1 [hackinglinuxexposed.com]
Part 2 [hackinglinuxexposed.com]
Part 2 [hackinglinuxexposed.com]
port knocking with perl (Score:5, Informative)
|use File::Tail;
|use Crypt::CBC;
|use Schedule::At;
|use Math::VecStat qw(sum);
|use POSIX qw(strftime);
|use Pod::Usage;
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.
i've noticed a lot of posts (Score:4, Insightful)
try doorman.sourceforge.net (Score:3, Informative)
Order and Delivery Of Packets Is Not Guaranteed! (Score:5, Informative)
There are less stealthy but more secure alternatives. I wrote one [homeunix.org].
Re:Multiple kocks (Score:4, Informative)
Re:Multiple kocks (Score:2)
Say you needed a specific knock sequence from two specific IPs: Those two knock giving access to one of them, while in that process false knocks can be sent in case anyone is monitoring packets being sent to the server.
so even if you did manage to see what was going on, it would be difficult to figure it out if it involved something like 4 IPs giving dummy sequences.
Re:Multiple kocks (Score:3, Informative)
Re:Secrets are not security (Score:4, Insightful)
Your 10000000 bit PKI key is just a secret. If you are relying on not giving that secret out to handle your security, then you don't have any. Its just a secret, I guess I am better off not using encryption
The arrangement of pins in my doorknob is a secret. I guess I am better off not locking my doors.
The password to log into my workstation is just a secret. I should just leave it open.
The more "secrets" you have in any given situation, the better secured you are.
Random portscans where they get all your secrets wrong : could be random noise.
Random portscans where they get 2/3 of your secrets right : You have probably identified an active intrusion attempt. Also you have identified a possible leak in your secrets. Time to change the passwords.
Re:Secrets are not security (Score:4, Insightful)
No one will stop you to implement an adv_knockd which requires the knocking sequence to be the current time in GMT, signed with your private key. Then your adv_knockd checks your signature with your public key and verifies the timestamp.
This makes your adv_knockd invulnerable against replay attacks, if you declare an sequence already sent to be invalid for the next hour (you have to allow for a grace period in the timestamp, because of network delays and asynchronous clocks, so a replay of an already sent sequence within a few seconds would still come through).
The knockd is explicitly called a proof-of-concept. Using it directly as part of your security policy is strongly disencouraged
Re:Secrets are not security (Score:3, Funny)