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

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.

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.

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

[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

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?

[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.

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.