[Melbourne-pm] Knockd for Web

Daniel Pittman daniel at rimspace.net
Mon Jun 1 20:26:24 PDT 2009


scottp at dd.com.au writes:

> This is more of a security question than perl, but I wasn't sure where else
> to get the answer :-)
>
> We use knockd to protect our SSH connections. It works great, anywhere I can
> ssh from, I can usually get fairly open outgoing ports, so I can just type 4
> telnet commands to send TCP packets to 4 ports, opening my SSH port from my
> source IP. For those not in the know - check out here:
> http://www.zeroflux.org/projects/knock. Once successfully received, it adds
> a IP Tables rule opening the connection. One thing that makes it work so
> well is that it is listening silently on those ports, so port scanners etc
> can't even know which ports to access.
>
> I am looking at doing the same process for Web reqeusts. Now the first
> question you may ask is "what's the difference"? And the answer is Firewalls
> and Proxies. In many office, work and even share network situations you are
> restricted to using only well know ports (possibly even only 80) and via a
> proxy.
>
> So it occurs to me that we can easily write a web server / CGI that can
> achieve almost the same as knockd via URLs.
>
> E.g.
>  http://special.host/1137
>  http://special.host/1199
>  http://special.hsot/4922
>
> or really any url you like.

Absolutely.  In fact, you could even make it more convenient:

    use CGI;
    use Test::Deep qw{eq_deeply};  # lazy, I know.
    my $secret = [1137, 1199, 4922];
    # Did I remember the array return type correctly, I wonder?
    my $got = CGI->new->param('secret');
    if (eq_deeply($secret, $got)) {
        system("sudo allow-access-from ...");
    } else {
        die;  # that should be enough to return a 500 error
    }

You could even substitute the hard-coded secret for 'use Authen::PAM' and
position it behind HTTPS, to make the whole thing a little bit easier to
configure and all...

[...]

> Not a hard script to write and secure, but my first thought was - maybe it
> already exists. My second thought was - maybe I am barking up the wrong tree
> and there is another way.

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.

Using existing, well tested security mechanisms like SSL is almost certainly
going to beat out building your own.

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.

Those provide zero-knowledge proof of possession over the Internet without
*any* reasonable risk of attack.

Regards,
        Daniel


More information about the Melbourne-pm mailing list