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.
"shave and a haircut" into port numbers?
"Prefiero morir de pie que vivir siempre arrodillado!"
Is pursuing something worth spelling correctly? also 'Yes'.
You can keep on knockin' but ya can't come in
So how do we map musical notes to port numbers?
I want to get "shave and a haircut" ported over to the new protocol.
"Trademarks are the heraldry of the new feudalism."
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
Who's there?
Just a bunch of hackers knocking with sequences they captured from sniffing.
I am not that familiar with port knocking, but what if multiple attempts from the same IP are made to access the port at the same time, Would the knocks then get all mixed up?
Opera Watch - An Opera browser blog.
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?
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...
The port knocking idea is pretty old.. at least for months now all kinds of people are knocking my 135 1433 3127 and a bunch of others to DEATH, like hundreds a day, trying to get in..
Oops, that's Microsoft port knocking.. never mind, sorry, I guess it is new to Unix..
Who's there?
Packet.
Packet who?
Packet up bitch, you've been hacked.
Don't come a knockin'
Sigs? We don't need no stinking sigs!
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....'
I just hope nobody knocks up my server
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.
is pasmal
That's a nice start.
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.
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.
But what happens if something else "knocks" in the middle of a series of port checks?
If this technique becomes widespread, then it will just encourage more and multiple port scans of IPs. If that causes problems, then people aren't going to use port knocking, if it keeps getting interrupted.
Lots of info available via a google search...
A few implementations 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...
"I either want less corruption, or more chance
to participate in it." -- Ashleigh Brilliant
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.
If this server is rocking dont come nocking
The problem here is that the ``password'' (the port knock sequence) is sent in plaintext. Anyone with a sniffer anywhere between you and the other machine can see what you're doing. If this ever catches on, any L337 |1dd13 with half a rootkit will be sniffing for anomalous port-requests, and you'll be just as hosed as if you logged on via telnetd.
Than a single coded UDP packet?
You'll find some more stuff on http://www.portknocking.org...
Repeat after me...secrets are not security.
Lazy programmers and closed source shops use methods like this to say the are secure when they are not.
This can be detected and defeated by packet sniffing. So ISP's would be able to find them pretty easily.
is this at all related to fart knocking? Because I spent a good deal of my time in jr. high school learning all about that....
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
You can only sniff packets on a network you are attached to.
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.
No, the knock-sequence itself is no more secure than a plaintext password. So using it for access to ssh is no more secure than simply using ssh alone.
That's all this is, and as many others are saying, not how I'd want my boxes protected.
That being said, I'm sure MS will find someway to package this into XP SP2's new firewall.
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 long, etc.). Moreover, it might be possible to have the system bar further attempts from a given IP address after two or three failed attempts during a given period of time.
Only Women Bleed (Sex, Sharia remix)
Yeah, but if your ISP is using Netflow to analyze the traffic, wouldn't it detect a syn/ack handshake going in the wrong direction (inbound) and be a dead giveaway as to the traffic? That, and doesn't the ftp protocol have a distinguishable signature in the control channel? It's easier just to VPN it.
Do you type:
>/etc/rc.d/rc3.d/s95Knock UP
?
Yes I would.
he's probably too busy hitting on women that are really men
p.s. im a hot linux babe!
Fart Knocking?
I'd just scp'd a new file to my ISP, ssh'd in to edit index.html, checked email, and then when I refreshed the page in http, suddenly I has root access!
try { do() || do_not(); } catch (JediException err) { yoda(err); }
I'm still waiting for some Jessica Lynch slash-fiction, btch!
And this one doesn't rely on security through obscurity. Check it out: Port Knocking
I knock, knock, knocked on that Gibson's door!
Game Overdrive - Gaming News
Can you tell I don't post to blogs much? Port Knocking
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.
Generate a knock sequence that includes (a) some random data and (b) the same random data, but encrypted by a key that only you have.
Have knockd decrypt the encrypted part and make sure it's the same as the random data.
Have knockd keep track of what random data has been used, to prevent replay attacks.
Highly unlikely you'll generate the same random data twice. But an eavesdropper cannot replay your key, and cannot generate random knock sequences either.
You could also set up error-correction in case somebody blocks one of the ports you're using for knocking.
Landshark.
That's "Mr. Soulless Automaton" to you, Bub.
If you are using portknocking as your only defense, then you are as smart as dirt and deserve what's coming to you.
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?
www.portknocking.org
Note the encryption/hash of the ports, source IP, and port to be opened.
www.portknocking.org/view/documentation
There is a Perl reference implementation. (GPL'd, of course)
"I am in no way affiliated with this group."
Fart knocking? I only ask because I came from the Beavis and Butthead generation of MTV. Knock it off Beavis, you port knocker.
Next idea.
...and let the 'knock knock' and three little pigs allusions commence ad nauseam.
My favorite phrase: You have 5 Moderator Points! Use 'em or lose 'em!
I was hoping for the giant shark.
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.
Wouldn't sending random connections at a server (whatever qualifies as a 'knock') interfere with anyone else completing a pattern to open a port?
If you want people to have to authenticate without revealing what services you're running, couldn't you just do a real (unlike replayable, sniffable plaintext like this) authentication one-way over UDP? That doesn't give anything away either, and is much less hokey.
It could even run on a well-known port... Is there already a UDP authentication protocol, or would one have to be designed?
Please see subject. Thanks!
You must mean the Nmap Security Scanner.
If Port knocking was such a good idea, why isn't it in IPv6? Or something like it, where service ports are only exposed with a key sequence?
n .htm)
The answer is because more advanced protocols that set up encrypted tunnels exist to do this, and have far more uses. If you want to secure your Linux box badly enough to implement port knocking, and go to the trouble of giving other people the knock sequence (let's call this 'the key') then just compile FreeSWAN or one of the spinoff IPSEC variants and let ISAKMP do that work for you. It was designed to do something port knocking was not - thwart man in the middle attacks using Diffie-Hellman.
(http://www.netip.com/articles/keith/diffie-helma
Do yourself a big big favor, don't re-invent the wheel.
there is another similar idea written by Brian Hatch author of Hacking Linux Exposed. Instead of 'knocking' ports which as I understand it can be vulnerable to brute force like attacks Hatch's solution uses dns queries to dynamicly open up ports through the firewall, using the dns query as a password. There is no 'service' listening but there is a sniffer waiting for a key string on port 53 that it will take action on. The best thing is it is OS agnostic since DNS query tools are already on all OS's no client software, or technical know-how is needed. And easily customizable if you're fluent in perl.
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
Part 2
Part 2
-- "of course thats just my opinion, I could be wrong." --Dennis Miller
My friend Thom Harrison at the Omaha Linux Users Group has posted some scripts which do port knocking and have the following CPAN dependencies:
|use File::Tail;
|use Crypt::CBC;
|use Schedule::At;
|use Math::VecStat qw(sum);
|use POSIX qw(strftime);
|use Pod::Usage;
http://tinyurl.com/4ny52
I really don't see the point. It seems far easier to try bruteforce port knocking than try bruteforce user/password combinations.
As mentionened seems that nmap will get some extra features soon if this becomes popular.
The only interesting really is the idea of having services running behind a closed port and actually able to respond.
But then, this could be done using udp that actually contained data, identifying the client, and encrypted ofcourse.
Idea (sorry if this might get a bit off topic): The server knows it's clients, it has a public key of each client, and each client has been equipped with a public encryption key of the server.
Know the client can send a signed packet encrypted with the server public key for the server to verify.
On success the server will open for connections for that client. In any case there will be sent no respond to the udp packet.
The result is the same, the server appears not to be listening on any ports, yet capable of accepting new connections.
But in this case the client does not gain access using some preknown knocking sequence, but actually identifying itself using encryption.
The problem seems to be manageing keys, and then to select a set of data to be signed and encrypted such that client is fully identified. (and keeping it all in one datagram is probably also a good idea).
But isn't that worth the trouble for the extra security? Does this give extra security?
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...
The use of port knocking should be as a deception device, not necessarily as an active defense.
You are hiding the fact that you have something to hide, ala steganography. Once that something is found (the knock sequence), it is open to attack just like anything else.
Stego + encryption is the way to go. Not necessarily for this application (port knocking), but it could have some great security uses.
So with port knocking, you still want that encrypted channel to be required (SSH, etc.) on the port that you successfully knock to.
"Sed Quis Custodiet Ipsos Custodes?" -Juvenal
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.
So if I use this technique, can I knock-up a server?
One of the cool things with this is that you could set it so that it actually starts SSH or the FTP daemon or whatever as well as open up the firewall on the appropriate port and shut it down again after.
Saves mem usage as well as being that teensy bit more secure!
Also in answer to post further up - WinXP's firewall can log dropped packets to a text file.
bagging secret methods of keeping things secure. well i'm sorry kids but ultimately keeping something secret is necassary for a secure system. what is NOT secure is keeping that secret in an accessable mode. good passwords are the most effective way of having a secret way into a system, since your brain isn't plugged into a computer it's only accessable to the correct person. port knocking sounds intresting, but it's like having a secret knock to let you in a physical door, anyone listening will know that secret knock.
If you mod me down, I will become more powerful than you can imagine....
a) ...increase scans exponentially. ...excuse for DDoS: "Sorry, thought I knew the knock... so I tried every possible combination."
b)
You are quite correct.
Set up a port that pretends to run XYZ service. Keep it open by a dummy daemon that doesn't do anything except act like a tarpit to slow down scanners. Maybe it even tries to fake the initial phases of the protocol.
So you port knock... then just signal the daemon to release that port and have it claimed by the real deal. A port scan might not turn up anything that looks different, until they try connecting to the service.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
How about implement a timebased port knocking system incorporated with GPG key and a rotating honey pot and listen for UDP?
Ugh, I am already confused by my own obscurity.
Huh huh huh... uhhhhh, Shut up, Beavis!
heh heh, You shut up, PortKnocker!!!
Candygram?
"Never attribute to malice that which can be adequately explained by stupidity." -- Hanlon's Razor
For portknocking, try doorman.sourceforge.net Got crypto.
--- There is no bun but Bun, and Fuzzy is His prophet! Bunbun akbar! ---
And a few more thoughts:
Probably not much more than obscuring your open ports.
Some are adding ecryption. I preffer ssh to ecrypt my data. I know its not obscure that I am talking over an encrypted link, but port knocking isnt going to be obscure forever.
There will likely be a problem using this over proxied TCP connections such as TCP acceleration used over SAT links.
It would very likely seem usefull for those that are fighting with thier ISPs (such as me) about open ports on the household firewall (such as my ssh, they hate that for some reason). Ports reject by default, after a few knocks open it up for the terminal your at... could work OK if the 'knocker' portion was fairly portable.
I think you underestimate just how much I just dont care.
Actually, as the CPU clock speeds up, port-
knocking may prove to be an ideal way to keep
the black-hats out of your network. Imagine
applications that don't maintain explicit
open ports, but only open up a port with the
right "shave-and-a-haircut" knock-knock. If
generic port scans can't find any holes, how
do the script-kiddies break in?
Port Knocking Acceptance using UDP is very unlikely to be detected by ISPs, because the usual implementations are that somebody sends you a packet and you don't respond with a reject packet. It's much less visible than TCP services. On the other hand, if you use port knocking to turn on your Port 80 HTTP server, the ISP may not catch your server when scanning but may still have port 80 blocked in their routers, so it doesn't really help much.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I just drop connections from any source that also tries to connect on 21,25, 119, or 137-139 which are ports my ISP's TOS checker scans, but I don't use. Anyone who knows what they're looking for on my system won't bother with these ports.
This is only implementing basic static knock sequences, but it could (and likely will) be further developed to support cryptographic knocks that are embedded with other data, such as which port to open.
The guy at portknocking.org has a good example of how to do this.
check it out
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
If the port's be a rockin' don't bother knockin' --Stevie Ray, l33t g33t4rist
"The first rule of intelligent tinkering is to save all the pieces." --Aldo Leopold (Paraphrased)
If the server's a-rockin', don't come a-knockin'.
It goes from God, to Jerry, to me.
I seem to remember the University of Florida was kicking students off its network who used any sort of server (including web). As they were claiming that they were basically doing this to prevent any peer to peer networks from running. I wonder if they could implement this to prevent the school from nocking them off the network and still be able to play their games and various other things. Course, blocking all on campus port searches using a firewall could also do that i think.
Fly me to the moon Let me sing among those stars Let me see what spring is like On jupiter and mars
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.
"That's the stupidest combination I've ever heard in my life! That's the kind of thing an idiot would have on his luggage."
--Dark Helmet
"A great democracy must be progressive or it will soon cease to be a great democracy." --Theodore Roosevelt
Or your could reply to the second correct knock with information required to make the connection, e.g. something as simple as the correct port number that you're going to open, or some password to hash a third knock with. It's probably best not to do this for the first knock unless you require a password in the knock, because somebody who portscans your entire space would presumably hit one correct port, unless you block them after too many incorrect attempts (which has other problems, e.g. they DOS your friends by sending lots of forged incorrect knocking packets....)
Anonymous Coward's assertion that you've got no way to prevent replay attacks other than annoying one-time passwords is incorrect. You could do simple things like using the timestamp as a challenge string, and rejecting knocks that have timestamps that are too old. (Dude - if you want to talk to me, get yourself a decent NTP feed first!) Or you could do the reply-on-second-correct-knock bit I discussed previously. In general, if you're going to be paranoid, it's much more important to be paranoid about somebody hijacking the session that gets built after the knocking is over.
Besides's AC's concerns (and I generally agree with the "keep it simple or don't do it" advice), one of the purposes of this kind of system is to implement the knocking mechanism in a firewall that's simple enough to protect and doesn't contain critical data, and only permit connections to that buggy DDOS-able easily-cracked Windows server in your DMZ after doing some authentication. It's Defense-in-Depth, though it's the kind of thing that's much more useful for your 31337-h4x0r buddies to play games with each other than it is for your blog or corporate web page...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Of course, a smarter setup would be to set up an S/KEY-like sequence for the port knocking -- that is, the sequence changes in known way from connection to connection, but the sequence is hard to predict without knowing the predetermined, shared key.
GET YOUR WEAPONS READY! --DR.LIGHT
Now someone needs to make an implementation for that Linksys WRT54G...
Starbucks, Harbuckle of Breath.
There are some tradeoffs - knocking systems are usually lightweight, while authpf is probably more thorough, especially about making sure the firewall hole gets closed when you leave. Different knocking systems have different bugs in them, and OpenBSD+SSH+AuthPF has the risks of more people attacking it, but the knocking systems have random authors while Authpf and its environment have to be blessed by Theo, so you've got some level of assurance about QA and future fixes. Also, knocking systems need various clients to knock with, and may be susceptible to firewall damage in between, while SSH is pretty widespread and firewalls generally let you make outgoing SSH connections.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Fark Knocker.
Be who you are and say what you feel, because the people who mind don't matter, and the people who matter don't mind.
Square peg into. . . wait, what is my pass code. . . um. . . oh yeah, square hole.
Good God. I did this years ago.
There are less stealthy but more secure alternatives. I wrote one.
PHEM - party like it's 1997-2003!
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
Sweet!
... "cause ol' Adolf wus a man o'God ... he kill'd them Jews din't he", George W. Bush
Just a nice reminder to George W. Bush that in order for the Christans to kill off all no-Christans, without the use of nukes, that the current occupation of Iraq will continue well beyond June 2004.
Why?
Answer! Bush is a Christan. Therefore, anyone who is not a Christan must die.
However, before "everyone must die", the Christans have it as a God given right that they can violate all non-Christans to their hearts content because, God gets such a hard-on when a Christan violates
and non-Christan that it's worth a billzion bucks, even George W. Bush would curtail his nightly visits to Gay brothels to beat-off in front
of the monitor just to see an Iraqi being violated by a Marine, it's the Amarican way, and the only way George W. Bush will be re-erected.
But let's give Christan their due. After all, they are hands-on-a-dick the most killing people on the planet today. Just mention the name,
Adolf Hitler, to George W. Bush, and he will sperm his pants
was overheard saying to Condo Rice as he was butt-fuck'n her in front of Dick Cheney. Cheney was so excited he was beat'n-off like
it was he last day on Earth. Your could smell it 5 doors down from the oval office (why do they call it "oval"?).
Well, guess that the new erectilite drug will give George W. Bush a new Presidency; now he will have the stamina to butt-fuck all the gays in DC.
Toodles.
I used to have a system that listened on the telnet port and when someone knocked it printed out some ascii art and blacklisted their IP.
I snared about 2 people a day with that approach, since ultimately anyone who saw that telnet was open on my box would inevitably try it first...
My ISP also had a spider that went out and checked common ports, so we firewalled that so it didn't see ftp, mail and such running.
I can't believe this crap made the news.
What's next, http over port-knock?
I'd rather read something published on april 1st
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
Portknocker
no sig, no plan, no clue
but for geeks?
and a miniature piano for playing rachmaninoff
Oh I just cant wait, hamster-made midi-music that also opens ports.
Compare this to real life. You have a stack of porn magazines locked in a drawer. The security is the lock, preventing your mother from ever getting access to the porn. That's fine. But surely you would feel much better if your mother didn't even know there was porn in the drawer! That's obscurity. It doesn't make the lock any more secure, but it is useful.
1) Where do you store the OTP? What do you do when it runs out
2) How do you know where you're up to in the OTP?
This won't work. OTP is *not* a magic incantation for wonderful security.
Xenu loves you!
A reason to mention the lovely Scottish village of Portknockie!
I'm no expert on port knocking (since I hadn't heard of it until I read this article) but it seems like a lot of folk are completely missing the point that this is an EXTRA layer of security on top of what is already there.
In the parent post the secret knock is more like the existing password based authentication. Port knocking would be more like painting the door to look like the wall. You can't try to guess the 'secret knock' if you don't even know where the door is.
---
We spoke for about a half an hour. I don't recall a thing we said. - Colorblind James Experience
This is a great idea! You could easily map the ID output into a sequence of port knocks.
Ha, ha! Nobody ever says Italy.
Though it would keep comcast from discovering my ssh service.
What? Provided you never use it? Anyone with a packet sniffer on your network can see there's an ssh server when it's in operation.
There is basically zero security reason to use anything like this to access legit services - just run a secure service in the first place. If you need to only access it from certain locations use a firewall or tcpwrappers. If you need authenticated access then use a VPN or SSH. These are all much better scrutinised approaches than some crappy daemon which somebody just...um...knocked up.
Remember that if it's a legitimate service then somebody should weigh the security value (in this case bugger all) against the potential risk introduced by adding a brand new service which is going to need significant privileges to run (given that it executes commands to open ports or change firewall rules.)
Where this _is_ amazingly useful is to hide services like rootkits and zombie-control interfaces from automated port and vulnerability scanners. This method is already used in some rootkits to avoid detection.
In summary, this is only useful when concealment is the key objective - it doesn't add any security per se. cf "security by obscurity" and "welcome to clueville".
What do you do if part of the proper sequence is in the initial random garbase? For example, let's say my proper sequence is 6 4 5 4.
4876454877 works fine, but
46496454219 won't, because 649 appears before 6454, and the 9 causes the attempt to be aborted and logged.
Other than that, it sounds like a neat idea.
tasks(723) drafts(105) languages(484) examples(29106)
> Anyone with a packet sniffer on your network can see there's an ssh server when it's in operation.
Do you know what a port knocker is, or are you posting blindly? The POINT is that your SSH port ISN'T OPEN FOR SNIFFING until you knock the correct sequence of ports. Then you are able to connect. So unless the scan happens w/in 10 seconds (or whatever predetermined time) of the conclusion of the knock, no, they WON'T see there's an ssh server running. THAT IS THE WHOLE FRIGGING POINT.
Ultimately, all these security measures are there for what ? Keeping some data on the hard drive and memory secret. Secrets that protect secrets that protect secrets that... My head hurts.
Maybe we deserve this world ?
And what part of 'in operation' did you miss? During an ssh session the fact that ssh is running will certainly show up on a sniffer, if it didn't, there would not be packets and the connection would not exit. I did not see SCAN anywhere in the original post, so if you want to blast someone's post, please at least read the post (yeah I know it breaks slashdot tradition but it DOES improve the signal to noise ratio).
start looking for seemingly random port probes by machine A on machine B, followed by machine B spewing gobs of data to machine A on a random port.
Seems like there are a variety of interesting permutations possible for port knocking, such as introducing a 3rd party machine.
Machine A sends a few pings special ports to Machine C, which then relays some packet to Machine B signaling that A wants to get service on port P. It will look as if B is initiating service with A since no packet went from A to B in the first place.
As an aside, I've always thought that the size of the time interval as well as the port number could be used for low bitrate communication channels that would look like noise.
Probably, though, it would give itself away as most servers emit from predictable ports, except maybe NAT firewalls...
"Provided by the management for your protection."
I would handle it like this:
:-)
4 - no, wrong start port. Treat as random hit and ignore, or log IP with a timestamp.
6 - yes, that's OK. Start of sequence.
4 - yes, second port OK.
9 - Oops! Wrong. Port knock failure. Log failure.
6 - yes, start of sequence.
4 - yes, second port OK.
5 - yes, third port OK.
4 - yes, sequence COMPLETE. Log successful knock.
2, 1, 9 - Ignore, as sequence is done.
Pause for a few random secs and open SSH acces for this IP.
If you get lots of failed attempts after the first or second port, that's when you really need to get paranoid and block and/or report. Random port scans should not be allowed to DOS your port knock server by filling logs. Brute force attacks should get blocked.
I would use sequences of perhaps 20-30 ports. Perhaps in range 1025-65536? And 10-20% random ports prepended and appended. Should give a nice set of possible sequences for your one-time pad?
What is the sound of one hand clapping?
cat
For all that the "but they have to be on your segment" argument can be rather true. I suspect that the largest number of script kiddies, by far, are living out their lives on cable modems.
Do you trust the punk next door? I hope you do... he's probably reading your web-mail and pop3 passwords.
Its certianly not that tough to put a cable modem into permiscuous mode, particularly if it is attached to your computer via USB instead of eithernet.
Repeat after me:
There is *NO* *RATIONAL* assumption of physical plant security when you are using a common carrier.
Cable modems are (within the toggle of one bit) the data equivalant of a good old fashioned party line.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Can't someone DoS them know by intermitantly knocking randomly?
Have you read my journal today?
> your SSH port ISN'T OPEN FOR SNIFFING until you knock ...THAT IS THE WHOLE FRIGGING POINT
You are confusing "sniffing" with "scanning". Port knocking hides from simple scanning (using NMAP for example) but once a connection has been established it would be obvious to the ISP or anyone on the local net using a packet sniffer (Ethereal for example).
The next time you get the urge to post in FRIGGIN ALL CAPS, maybe you should try calm down a little bit and make sure you know what you are talking about.