Knock Safely With portknocking_v1.0

mrdeathgod writes "The Port Knocking project at SourceForge has just released portknocking_v1.0. Based on my undergrad thesis, this client/server package does not use pre-defined knock sequences, but rather utilizes Blowfish in order to encrypt the client data into a sequence of port numbers. This enables a client with the proper password to remotely manipulate firewall rules without fear of replay attacks. While currently designed for FreeBSD+ipfilter, expanded portability is in the works."

Comments

It would seem to me that the title of this article

[Tim_F]

should be knock safely. Not the trollish "kock safely..."

hrm...

[blackcoot]

i usually use condoms when i want to kock safely ;-P

Re:hrm...

[hitchhacker]

blackcoot's Latest 24 of 161 Comments
Subject Datestamp Replies Score
hrm... Fri Jun 18, '04 02:30 AM 1 4, Funny
attached to Kock Safely With portknocking_v1.0

hehe

-metric

Re:hrm...

[archen]

Well theres more to kock safety then that. I know when I knock the wrong port on my girlfriend she gets pretty pissed. Remember, this is about protecting the ports too =P

Re:hrm...

[blackcoot]

the boyfriend doesn't seem to mind at all ;)

Re:It would seem to me that the title of this arti

[manjunaths]

Right, I even went and looked up 'Kock' and this is what I got 'No entry found for kock.'

By god

[Anonymous Coward]

If your gonna let your port get kocked, do it safely.

Preview button...

[geschild]

Admonishing us for not using the preview button or a spell checker?! :D

"Well. I guess I'll have to see your 'dupe on the same day' and I raise you... a glaring spelling mistake in a title."

At least the editors can edit their entries. :P

I'm still not convinced...

[dotz]

Even after reading this one.

A list of one-time passwords & a simple daemon, that verifies them & enables ssh access (in some high level language) at the user request would do as fine. Give such daemon some IQ, so it would make brute-force attacks very hard, and you have the same thing. Except for the "cool" part.

Re:I'm still not convinced...

[sporty]

So you'll still have a firewall for all other ports, leaving your sshd daemon visible, which may be flawed. And you'll ignore a new technology which will block off ALL ports and only open one to sshd, which may be flawed or not, if you know the right port sequence?

um...

Re:I'm still not convinced...

[dotz]

No, sire. I'm thinking about a very simple daemon, written in high-level language, that would manipulate my firewall rules using unencrypted OTPs. It could open ssh port for 5 seconds only to IPs, that gave right one-time password. Store only MD5 hashes of those one-time passwords on the server, and voila.

In Python I could write such daemon in 30 minutes or so. "man ipfw" or "man ipf" would be the part, that would take me most time (not to mention testing, of course) :)

Kock Safely

[I(rispee_I(reme]

Freudian slip, much?

Offtopic?

[hitchhacker]

(Score:0, Offtopic)
WTF?

the topic is:
"Kock Safely With portknocking_v1.0"

It's not my fault the topic is offtopic..

-metric

Re:Offtopic?

[blackcoot]

we are not all one with the typo detection ;-)

You forget

[hummassa]

That a portscan reveals nothing in the case of port knocking.
And it shows a listening port in the case of the deamon, well, listening, conventionally.

Re:You forget

[dotz]

Yes, of course. Hiding such things means exactly, that you use "security by obscurity" approach, which "portknocking" is told not to use. Really only good thing is, when compared portknocking to one-time passwords in my proposed approach, that in passwords each "digit" can be one from about 63 characters possible (upper case, lower case, 10 digits) - and in portknocking each knock could be around 655350 - which makes a short port knock sequence harder to bruteforce, than a long one-time password.

Re:You forget

[NicolaiBSD]

"And it shows a listening port in the case of the deamon, well, listening, conventionally."

Not if you firewall it. I cannot see the point of this (except for academic exercise ofcourse).

Re:You forget

[Curien]

Huh? Without portknocking, you have to have at least /one/ listening service.

The advantage with portknocking is that if someone was scanning IP ranges for computers running exposed services, you won't show up as a valid target. You'll look like an unused IP or a computer that's off (or one that's simply firewalled every port).

Re:You forget

[dotz]

Unused IP? Yes, with TCP_BLACKHOLE, why not. But... if portknocking is active, it is also a kind of listening service - even if it won't show up on nmap, it also does listen for network events. At a given level of abstraction, this will be the same as network daemon listening on open port ;)

Re:You forget

[claudius0425]

He has a good point. Consider, for example, a student at a university that forbids you to run any servers (say, UF with ICARUS). With portknocking, you could keep all ports closed yet, with minimal effort, open a transient hole in your firewall, allowing you to, say, access an ssh server, but only from the machine originating the portknock. This is particularly useful in a DHCP based environment, where a static firewall rule would be utterly ineffectual.

DISCLAIMER: No, I do not attend UF, don't send in the goons. It is just an example.

Re:You forget

[Anonymous Coward]

That explains it for me. I couldn't think of a reason this is useful. It's only advantage over ssh is stealth. Stealth is of little advantage to white hats (please no, security through obscurity arguments). Black hats love stealth. This will be a great techology for open proxies, etc.

Re:You forget

[kace]

DHCP environments are a good example of when this method can give you more benefits than just having no open ports to scan -- which is a pretty darn big plus too start off with.

I'd suggest that you incorpaorate something like a RSA-SecureID system -- so that you'd have a [nearly] unlimited supply of one time passwords -- and this method becomes even stronger.

Remember the onion -- layered security.

K.C.

Re:You forget

[Khazunga]

Just use a datagram service, like UDP instead of TCP. Have your protocol not reply to requests until the authentication is done. Presto! It works, has all the benefits of port knocking, and uses no clever trick.

This is a solution in search of a problem....

Re:You forget

[evilviper]

if someone was scanning IP ranges for computers running exposed services, you won't show up as a valid target.

Same is true if you run SSH on some obscure port, especially if you remove the version number, etc.

Port knocking is obscurity, and obscurity is not security. People forget that a lot.

Re:You forget

[lewp]

Obscurity is, however, a valid part of security. Even if I'm patched, up to date, and configured properly, I'd still prefer to give away as little info as possible.

Re:You forget

[pboulang]

Nope. You are wrong. Consider it as another key. Normal ssh would require you to have a username and a password. Paranoid firewall rules might say that you need to ssh from a specific IP. Even more paranoid rules would require that specific IP to portknock.

Besides that point, what you say about ssh on an obscure port is much worse that you think. The very moment someone does a portscan, finds a responsive host (remember that a portknock protected computer wouldn't even show up) and then has open ports on some obscure port, then it becomes INTERESTING. I hold that that description is the LAST thing you want to have for your site... like having a .gov URL. Plus, it would take all of about 2 seconds to guess what the protocol running on that port would be:

Telnet to that port... hmmm, no version number, no service description.. therefore not http, not smtp, etc

ssh to that port.. hey, a login prompt. Joy. Let's run known scripts against it now.

Re:You forget

[evilviper]

someone does a portscan, finds a responsive host (remember that a portknock protected computer wouldn't even show up)

Now this is wrong... A machine trying to be stealthy is far worse than a machine that admits it exists, but has no open ports.

I say that because anybody can tell if an IP address is in use. If they find that they don't get any reply from pinging that host, they know they're dealing with a host trying to be stealthy, and will spend much more time working on it.

If a machine just returns the normal messages, like a TCP rst on all common ports, then the scanner will just figure it's a normal machine with no open ports.

This is a case where trying to hide your machine actually gives people more information about it, and makes you the subject of more interest.

then has open ports on some obscure port, then it becomes INTERESTING.

No, there are 65535 ports on every machine. Do you expect anybody to scan all ports on millions of machines, then investigate every single open port to find if one happens to be an SSH daemon? No, in reality they just scan port 22 and move on. It takes a long time to scan all the possible ports on a machine, and it leaves them open to easy detection by a port-scan monitor, which could then refuse to accept connections on the SSH port from their IP address, and from anyone else for a few minutes time. Then even a full port-scan wouldn't detect your single open port.

it would take all of about 2 seconds to guess what the protocol running on that port would be:

The idea was just to hide the version, so they'd have to run hundreds of exploits, since they don't have any idea what brand of SSH daemon is running, and no idea vhat version. It would be easy to catch them in the process. But that's besides the point, the odds of them discovering the SSH daemon on an obsecure port in the first place is practically 0.

Re:You forget

[pboulang]

I guess the part I really had a problem with is the "security through obscurity" flippancy. I totally agree that simply hiding and hoping is worthless. But let's take the "scan port 22 and move on" example and delve. You say change ports and hide the version, I say basically the same thing, except do a better job of hiding.

Let's change the example into a lock on a door. With a normal door lock, you can look at it and determine the make and model, maybe check if there is a master key floating around. That would be vanilla SSH, sitting on port 22 with version 2.exploitable branded on the connect string. You say, leave the lock where it is, but rub out the make and model, make someone try and use a bunch of different keys to figure out what's going on. You watch when someone does that. I say, hide the lock, make them push my secret squares on the door before they can even tell that there IS a lock on the door. I don't think our solutions are at all mutually exclusive.

Put this way, I feel that more bits to decode means I have more time to realize I am being attacked. (My answer to that 2 years ago was to implement IDS and bond with IPFW and disable all connections from whatever IP was bothering me for 24 hours.. hugely entertaining in my head to think of someone saying.. umm, where did it go!?!?) And maybe we both will end up with scripts that say, hmm, nothing here no port 22, next machine. I still better not exposing a possibly critical/vulnerable service at all until someone has messed with my machine and given my IDS a chance to trigger "IPFW 10 DENY IP $Bad-person to $EXT_NIC"

Re:You forget

[Tassach]

Huh? Without portknocking, you have to have at least /one/ listening service.

Again, what's the point? I can not see any legitimate purpose for this. The only reason I could see where you'd want to completely obscure the fact that a box has open ports is if you are up to no good -- eg, hiding a back door on a subverted box or running an unauthorized service on your employer's network. It may be an interesting hack, but it has zero practical value.

knock knock

[kwoff]

Knock, knock.
Who's there?
Kock.
Kock who?
Kock you!

Well, my nephew would get a kick out of it, at least.

Missing the point (see other posts below)

[hummassa]

If you enable portknocking, your computer does not show up in a IP range portscan as a target. To a portscanner, your computer looks like all ports are closed, no way to reach it. It's turned off for all the port scanner knows. So the 5kr1p7 k1dd1ez will not bother you.

I would be stupid, though, if *after* the port knock open some door, you get to open a telnet port for instance, instead of a more secure ssh port.

What the topic *is* about is that now you can have OTPs and other types of non-fixed port knocks. Additionally to the security of not being "seen" by port scans, the port knock sequence changes and is more difficult to brute force.

Re:Missing the point (see other posts below)

[dotz]

What's the point of having the machine look like invisible/unused, if you still can watch packets with data (heck, even encrypted) come to it?

portknocking won't help you keeping your IP hidden. Having a tunnel from your IP to a trusted machine will (so you will appear as another IP and noone administrating that machine will give your "secret" IP to public).

pr0n kiddiez? Man, just change SSH port from 22 to 2222 and you have pr0n kiddiez off your back. In the times of scanner automation (scan IP range, find vulnerable hosts, launch all known exploits, install rootkits) people won't bother trying to hack your sshd if it's not standard anyway - just because in the time they are trying to find, where is your sshd at, they can find & hack all those 5 windows 98 machines, which NEVER saw Windows Update, on the same network.

Re:It would seem to me that the title of this arti

[MullerMn]

*bing* *bong* Captain Obvious to aisle 5 ..... Paging Captain Obvious...

I'm confused

[epine]

This does nothing more than redefine an existing problem. It's still a communication channel between two participants, whether the bits are conveyed inside the IP packets, or as attributes of the IP header.

The "genius" of this approach seems to lie in the fact that the closed machine makes no response whatsoever until a valid doorknock sequence is received, which renders the system more clandistine from a very narrow point of view.

One of the reasons why ssh security negotiation is two sided is to eliminate replay attacks. The doorknock concept is going to have a problem with this.

I find it interesting to imagine that the doorknock sequence is defined as a function of the IP address of the requesting system. This would eliminate a replay attack by an adversary who can snoop traffic, originate traffic under its own identity, but not actively impersonate.

Re:I'm confused

[CamMac]

This isn't an attempt to redefine a problem, this is an attempt to provide a diffrent solution to a known problem. Two sided ssh security negotiation might work great for your application, but it might not be so hot for mine. Diffrent solutions have diffrent strenghts and weaknesses, and the more solutions we have, the better able we are to select one which matches our security needs. Options are a /good/ thing.

And honestly, its a damn good idea with a simple implementation. Because its so simple to implement, there will be more than one portknock server. How would an external attacker know if a broken version of portknock was being used, or if there wasn't even a computer there?

Pay attention to portknock, because you will see it again.

--Cam

Re:I'm confused

[Anonymous Coward]

You're right; the implementation is simple. And by simple I mean simple in a bad way. First of all, it's easily vulnerable to DoS. Look at the code. The way it handles determining if a sequence from an ip address is correct is easily made by an attack to allocate arbitrary amounts of memory that is never freed. It also doesn't bother to check to see if its allocation succeeds, and will write into unallocated memory when an attack takes place, causing the daemon to segfault; leaving the firewall rules in an indeterminate state and removing legitimate usage of the service. Each packet processed involves searching through a linked list of the entire collection of addresses, so on its way to running out of memory and segfaulting, it will happily suck all of the CPU time of one processor.
You'll also notice that even if it wasn't designed like some 19-year old that just learned C and has absolutely no understanding of algorithmic complexity wrote it, that the approach taken is easily DoSed period. IP blocks can be easily poisoned.

Yes, pay attention to this retarded concept and its terrible implementation. You can learn a lot about how little people on Slashdot know about anything by how they either praise something that they know nothing about, or skirt the issue entirely and ramble about philisophical issues. Not one person bothered to look at this program and realize that it's a piece of shit. It's a wonderful learning device really. Q: Just how ignorant is Slashdot? A: Very.

Re:I'm confused

[CamMac]

Sigh... I can't believe I'm actually responding to this troll. Anyways

The code looks like it was designed by some one who just learned C because, well, it was. The code is something called a proof of concept. A proof of concept, for those that are unfamiliar with the idea, is when something is quickly done just to prove that it might work and is feasible. Its usually the first step that leads to larger projects that address concerns like segfaulting.

And NO security measures, short of pulling the plug, is immune to DoS. So ignoring a security messure that is succeptable to an attack that almost all security measures are not immune to is idiotic. Perhaps I should stop using my firewall because my poor 56k modem can get DoSed.

--Cam

Re: Headline typo

[mhesseltine]

It's nothing major. It's just that Michael's "N" key is worn out from "approving" stories:

Approve this one? N

Approve this one? N

Approve this one? N

Approve this one? N

Approve this one? N

Approve this one? N

Approve this one? N

Approve this one? N

Approve this one? N

Approve this one? N

Approve this one? N

Approve a story on port knocking? Y

Broken keyboard? Y

That explains why it's so hard to get your stories posted. (wink, wink, nudge, nudge)

K is funny.

[Ayanami Rei]

Cake is funny. Muffin? Not funny.

three things

[Hubert_Shrump]

1. you have a single point of vulnerability in your daemon
2. for the moderately paranoid, you can just shove all your stuff up into the ephemeral port range - most portscanners don't scan past 6000 unless you tell them to
3. anyone that didn't think this thread would be mainly about 'kock' hasn't had their coffee. such as myself
4. there is no item the fourth

+1 Funny

[dotz]

... only if I had mod points :)

Kock

[dotz]

Kock is a real place. You don't belive me? Just click here

Anyway, dear /. editors, it's a great way to ruin a story. 90% of posts in this discussion are offtopic, just because you did a typo (for those who plan to mod me down - I did posted a serious comment already, have mercy!).

Re:Trolls that write themselves

[Anonymous Coward]

you forgot the part about BLOWfish encryption.

Why so complicated?

[technothrasher]

Why do you need to go to the trouble of hitting a one time sequence of closed ports rather than just knocking with a one time password in a single UDP datagram?

Re:Why so complicated?

[tigga]

Why do you need to go to the trouble of hitting a one time sequence of closed ports rather than just knocking with a one time password in a single UDP datagram?

Then there is a daemon which listens on that port and you may feed it with UDP stream trying to DOS it.

Re:Why so complicated?

[technothrasher]

Then there is a daemon which listens on that port and you may feed it with UDP stream trying to DOS it.

Yeah, that's a point... but if you know the port to DOS, you must have been snooping. If you're snooping, you can just DOS whatever service the knocking opens up regardless of the knock protocol. Port knocking just keeps port scanners from seeing open services, it doesn't guard against a targetted DOS attack.

Re:Why so complicated?

[Krunch]

And what stops you from DOSing the portknock daemon ? If you are concerned about DOS, just change the port it listens to every 30 minutes or so and have it be a function of current time. Something like this: port_number = md5_to_portnum(md5((++time)+secret_salt)). Now if you know the secret_salt and current time you know on which port the daemon is listening for the current 30 minute period. But no DOSer can tell. You can also change the password using the same technique.

I think this is easier to implement and to use than port knocking.

I just realized why portknocking is so good

[doc modulo]

Traditionally, port communications are safeguarded by the application behind the port. This means that if you have 13 network applications, there are 13 possible ways of someone owning your system with a trojan.

On the other hand, portknocking is handled by a single daemon that is simpler than most applications. Portknocking could even be handled by the OS.

This means that instead of having to trust several net-connected programs with your system security, whose primary focus will probably not be safety, you only have to trust 1 program which IS focused on security. Added to that, a portknocking program is easier to make safe because it's simpler than most other programs which have to handle both network defence AND some other task (Instant Messaging).

Re:I just realized why portknocking is so good

[ubiquitin]

What you describe here is also a good part of the rationale behind TCP wrappers.

Re: Headline typo

[Anonymous Coward]

Except this one was posted by timothy.

Alka-Seltzer is funny.

[Anonymous Coward]

Nice. Reference. To. The. Film: the Sunshine Boys

done...

[Anonymous Coward]

I have implemented such a system and am presenting on the subject of Cryptographic Port Knocking @ BlackHat this year!
Check out the abstract @ http://www.hexi-dump.org/bytes.html

Re:FreeBSD is Dying

[Tezkah]

If *BSD is dying, why do you feel the need to post this in *every* BSD story? Shouldn't you just ignore it and let it go away?

has anyone read the thesis?

[Anonymous Coward]

I must say I'm quite disappointed in this. Anybody listening in on the "knock" will know the plaintext used in the encryption process. It's then a trivial matter to brute-force the password. This is because 99% of the time, the client will be run from the machine you're connecting from, giving the attacker the source IP and the destination port.

Also, it seems that an ordinary portscan would add 32 random firewall rules, that would never be cleaned up.

I'm not even going to mention that an MD5 hash is used to determine if the original file has changed.

Broken Implementation

[btg]

Not only is the concept stupid, but I looked at the guy's thesis for five seconds and his crypto is totally broken - there is a trivial known plaintext attack to recover the secret password if you can intercept knocks on the wire. The plaintext is [IP addr][port][action] for 4 + 2 + 1 bytes each. The last byte is pad - which is cunningly hardwired to null.

The IP address makes up 4 bytes of a 7 byte plaintext (which is already small enough to brute force) and the IP address will be that of the knocking host. Wait, it gets worse! The "action" byte is basically "open" or "close" and the port bytes don't quite use the full 2^16 range. In other words I need to brute force a little less than 17 bits. This is only challenging if I want to make like ET and do it with a reprogrammed Speak N Spell.

Back to sleep for me until version 5.0.

Re:Broken Implementation

[Hektor_Troy]

It's proof of concept, not "here, use this in your ultra secretive secure thing-a-ma-jig".

I knew a guy who had ten locks on his door. You had to turn the key the same way to lock and unlock. He usually only locked two or three locks, when he left, simply because he figured, that by the time he gets home, a possible burglar still haven't unlocked the door (probaby by locking some of the unlocked locks).

This is (to me anyway) somewhat the same thing.

It may not be entirely difficult to figure out, what ports are being used to knock, but as I understand port knocking, there's more to it than just the ports; the timing has to be right as well. And using a one time pad, makes sniffing useless. And just how do you brute force a secret knock?

Just for kicks, let's say we restrict ourselves to knocking on 4 ports, and we have a range of 128 ports.

Well, if you can knock on a port more than once, you'll end up with 128^4 (268.435.456) (it could be 4^128 which is MUCH worse). Not too shabby, right?

This is even ignoring any timing restrictions. If you have to say knock on port 1004 first, wait 3 seconds, knock on port 1100, wait 1 second, knock on 1001, wait 5 seconds, knock on port 1027, HOW would you brute that? Remember, knocking on a wrong port in the sequence will reset your attempt.

I don't even want to speculate on the numbers in that case.

Clients?

[NickeB]

Okay, so we have portknocking, but do we have clients that can utilize it?

Let's say I want to access machine X's ssh daemon, which utilizes portknocking, is there any ssh client today that can access it?

Anyhow, I'm gonna name my firewall "Heavens door" when this works.

you said portknocker

[specialRrider_Joe]

Butthead: you portknocker! Beavis: he he hehehe Butthead: uhhh huh haha Beavis: he he.... you said knocker Butthead: uhhhh huh ha ha huh Beavis: he hehe he

lolskate

[Anonymous Coward]

no that's hemos

No, it's a reference to Jerk City.

[Ayanami Rei]

Can't find the strip... "Kafka is twice as funny to neoclassical existentialists. But rape is funny and I don't hear a k. The implication is you can FEEL the k."