[Melbourne-pm] Knockd for Web

[Daniel Pittman]

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.

*nod*

>>> 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
friends do.

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[1], 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
> proxy.

*nod*

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

Absolutely.

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

Regards,
        Daniel

Footnotes: 
[1]  At least, not an Internet facing port.