Slashdot Mirror
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."
i usually use condoms when i want to kock safely ;-P
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.
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.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
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.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
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
All jocks think about is sports. All nerds think about is sex.
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).
- -- Truth addict for life.
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.
No GNU has been Hurd during the making of this comment.
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.