[Melbourne-pm] Knockd for Web
daniel at rimspace.net
Tue Jun 2 05:48:05 PDT 2009
Scott Penrose <scottp at dd.com.au> writes:
> On 02/06/2009, at 8:14 PM, Daniel Pittman wrote:
> All what you wrote above (removed) is reasonable. I only differ very
> slightly in opinion, not enough to worry about :-)
*nod* Also, in case it isn't clear, I don't think that port knocking is
useless in terms of security — just that there are simpler solutions that
provide the same benefits. In my opinion, of course.
>>> The security experts seem to disagree.
>> Ah. I thought you were going to post links to disagree with the claim that
>> SSL is reasonable secure.
> Oh no. Sorry I didn't mean to imply any one way or the other about SSL
> security. In fact in a different circumstance (e.g. an admin web interface
> for a company) I would be using certificates as auth.
>>> Indeed, if all you say is true, we can throw away iptables and firewalls
>> That certainly isn't my argument, and I am vaguely surprised you found
>> anything to support a belief that it was in what I wrote. :)
> Quite right, I was going a little over board to make a point. What I had
> missed from your previous post sorry, was that you were using an SSL
> certificate to then open a firewall port (e.g. to SSH). My personal
> conclusion, after reading what a number of experts have to say, is that it
> is not as safe as having no open ports.
*nod* I agree here.
> Having that one service (e.g. an SSL server) makes the machine
> vulnerable. You did talk in the deleted section about security of knockd -
> and it does have to run as root, but accepts no user input - so while there
> is a potential for DoS (although very small in compared to any socket
> interface), it is not likely to have any other hole. Of course... famous
> last words :-)
Ah. The knockd you reference does open a port, however: it opens a raw socket
to receive link-layer packets using the same kernel interface that tcpdump and
Now, you /could/ implement a version of the tool that either used the iptables
userspace queue or netlink logging facilities directly, or that parsed an
on-disk log, that didn't require an open port, but the common implementation
is not done that way.
That all transfers the risk to the daemon that handles the link-layer packets,
which are untrusted user input. You can argue, probably successfully, that
such a daemon has a smaller codebase and, consequently, less risk, and I
wouldn't entirely disagree.
>> My contention, for what it is worth, is that you gain as much security
>> using a more common method such as SSH or SSL secured HTTP to perform the
>> same authentication collection as the knock service.
> Thanks Daniel. I am afraid I still want to block all open ports with
> iptables, so no open SSL or SSH connection, plus as I originally mentioned,
> I am coming in from networks that don't support anything but HTTP via a
> Which leaves me still with a way of "knocking" via a firewall - for which a
> CGI type solution may work. And because it still then uses secure passwords
> over SSL I can probably be confident that it is good enough. Which is what
> security is all about, there is no perfect solution, just tools.
> Which comes around full circle back to my original question, which is
> probably no, has anyone seen an existing script. Yes I can write it easily
> (And Daniel did too), but I like to find someone who has found all those
> hidden issues I have not yet thought of.
I am afraid not. All the dynamic IPTables CGI stuff I know is all about
outbound connectivity, not inbound, so isn't really appropriate, and that all
does real HTTP anyhow...
 At least, not an Internet facing port.
More information about the Melbourne-pm