[Melbourne-pm] Knockd for Web

[Daniel Pittman]

scottp at dd.com.au writes:
> ----- "Daniel Pittman" <daniel at rimspace.net> wrote:
>> Given that port knocking is just another way of delivering a password
>> to the
>> destination system, there is no security difference between it and
>> just using
>> the password in the vast majority of cases.
>
> Sorry this is very inaccurate Daniel. There are many reasons for that, but
> here are a few:
>
> * As your port is closed - you suffer from none of the DoS attacks to your
>   service (e.g. SSH)

That isn't true: you have a daemon listening on a raw socket, accepting
packets.  That does prevent DoS attacks to other daemons, but does not
eliminate them for the port knocking daemon.

> * As your port is closed - you suffer from none of the buffer overrun, or
>   various other back door and bugs in your daemon

You have a daemon listening on a raw socket.  You might move these risks to a
different daemon, but you can't eliminate them.

> * As your port is closed - you don't even look like you are there - not even
>   a response from your IP, no scan as the ports are closed, so unless you
>   know to attack that location, you won't even try.

This is a valid claim.  The same, of course, is true of an arbitrary CGI
script running on your system, or an HTTP service listening on an arbitrary
port.

> The knock can also even be a one time key - obviously you need some way to
> know the next/ time based entry, which would not suit me.

Absolutely.  Just like a password collecting service could be.

>> Using existing, well tested security mechanisms like SSL is almost
>> certainly going to beat out building your own.
>
> As with the documentation of knockd, it is not about replacing the need for
> good security via SSL and passwords. This is not, as you suggested, a
> replace your authentication with a roll your own.

Well, it replaces user authentication via a known and tested protocol with
user authentication through the knock protocol.

It then, subsequently, modifies the firewall to grant further access, at which
point you go beyond the scope of my comments; I restrict those exclusively to
the use of knockd vs something else for the initial "authenticate and open the
firewall" part.

> Knockd is a well established and commonly used tool to add a layer to that
> security.

Yes.  Only, perhaps not so well establish and tested (or standardized) as
using ssh to achieve the same result via authpf[1], or using SSL certificates
via HTTPS, or any number of other choices.

[...]

> There are a number of problems also with using SSL. The purpose of my
> requirement is to allow me access with my own knowledge, from an unknown
> location. The example given to me was that your laptop, desktop and usb key
> get stolen over night. Or you just plane forgot your usb key and laptop :-)

Now, that is a legitimate object to client side SSL. ;)  If I was going to do
this I would certainly allow, if not prefer, password based authentication to
open the firewall.

> Finally, there has been a number of attacks and holes in Apache SSL
> implementations over the years - if you have an admin service you don't need
> to give access to (i.e. not a public site) then blocking even access to the
> service is a good idea.

*nod*

> The kernel via iptables can throw away packets far faster than a connection
> to Apache - thus you are reducing the DoS attacks as well.

Granted.

> If you have security monitoring tools, you can even use knockd technique to
> reduce the reports of automatic or scripted attacks to those that are
> serious. Logs are just full of script kiddies attacks - so much so that you
> can't even see the serious ones.

Yes, you can.  Specifically, the technique of collecting authentication
information and then opening the firewall works *regardless* of how you
collect that authentication — SSL certificates, passwords, or "port knocking".

>> Finally, if you are in sufficient control of the destination system and
>> userbase to require port knocking you can almost certainly just use
>> client-side SSL certificates for authentication.
>
> Yes. You can of course just use basic auth - thehehe. You can use what you
> like. But clearly my requirements were not clear enough, as that would not
> meet the needs.

Well, that is fair.  SSL certificates don't, in this case, meet your needs.

>> Those provide zero-knowledge proof of possession over the Internet without
>> *any* reasonable risk of attack.
>
> 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.

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

[...]

> In the end adding a layer of security can not be "the same" as not adding
> that layer. My need here is to provide the same established security of
> knockd to web services via proxies.

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.

Regards,
        Daniel

Footnotes: 
[1]  http://www.openbsd.org/faq/pf/authpf.html