"Brian Sydney Jathanna" <[EMAIL PROTECTED]> writes:
> Port Knock service secures the network by having all the ports closed
> and listens on a secret port for the secret handshake.
When you say "secures the network", do you mean to imply that there are
significant security risks in the Linux IP stack that are present only
in open sockets, not closed sockets?
Alternately, do you mean to suggest that there is less complexity and/or
more testing of the code that listens to raw sockets than in, say,
Apache and the Linux PAM stack?
Unless you can quantify /how/ the "port knock" approach is more secure
than Apache, a CGI script, and PAM, then you are (in my opinion) seeing
a "Rube Goldberg" mechanism for additional security -- when it is only
additional complexity.
> When the client intiates a connection, the connection is verified
> through the internal database as to which service the particular
> client has access to.
*nod*
> The doorman approves the connection. Once the client is approved the
> connection, it is only allowed access to the particular service for
> only that particular session.
*nod*
> And in the whole process passwords are never exchanged.
*nod*
So, essentially, you are saying that this is identical to the Apache/CGI
approach, except that you have *less* security, because you don't use
passwords.
Is that correct? If so it seems a ... weak argument to me. On that
basis I presume I have misunderstood your point somewhere; would you be
kind enough to correct me?
> The advantage gained here is the client is given access to the
> required service only within the requested session,
This is not, in any way, distinguished from using the Apache/CGI
approach, where you would authenticate to a service, it would consult
the database of permissions and then dynamically alter the firewall
rules.
For another implementation, specific to the PF firewall, you could look
at the authpf system:
http://www.openbsd.org/faq/pf/authpf.html
Admittedly, that uses ssh to secure access and then alters the firewall,
making it less helpful in the current case of ssh brute force attacks,
but the principal is sound.
> which defeats port scanners, sniffers, network hijackers and the rest
> of the scum.
It isn't even remotely clear, from what you have said, how this is
achieved.
The variant of port knocking you describe, in which no password is
exchanged, is the simplest variant, and is vulnerable to all of the
above.
The more complex variants, where either a sequence of "knocks"
substitutes for a password, or a password is supplied in the packet,
reduce one of these risks, but do nothing for the others.[1]
Specifically, port scanners can trivially defeat a single port "knock"
solution without further authentication. The process is trivial to
determine: first, scan for ports in the ranges used by the knock system,
then for key services.
Given that an exhaustive scan costs you ~ 5MB of traffic, most attackers
with the resources to implement a brute-force attack can implement this
port knocking bypass with no real worries.[2]
As the complexity of the port knock sequence grows so does the attack
complexity, so a multi-port sequence does gain resistance. This is no
different to a single port using a strong password, though.
Specifically, you are now using a password authentication mechanism
where IP packets are treated as password "symbols", and where you have a
code space of ~ 60,000 codes to select for each symbol.
You need less IP packets for the same level of entropy that a password,
using a code space of ~ 36 codes, would need characters -- but you don't
actually gain anything more than that.
Finally, none of these techniques do a damn thing to protect you against
"sniffers, network hijackers and the rest of the scum", as you comment:
Unless you implement genuine public key cryptography *with* peer
verification[3] within your "port knocking" sequence then you are
sending a clear-text password.[4]
This means that a sniffer or network hijackers can trivially detect your
port knock sequence and replay it to your server to gain access.
(...and did I mention that real SSL style encryption would require
communication back from your server, something that port knocking sets
out to avoid? Alas, it really doesn't help.)
As to the "rest of the scum" ... I can't identify any other attack
vector where port knocking makes a lick of difference; if you had
something in mind other than vague implications that this adds security
then feel free to name the scenario.
Regards,
Daniel
Footnotes:
[1] Technically, you could be arguing that a multi-port knock sequence
is not a "password", which is vaguely true but not especially
relevant, as it is identical to a password in use and effect.
[2] Obviously, this is only effective for the attacker if they are
specifically targetting you[5], or if this is common enough to be
profitable as a line of attack for them.
[3] Which gives you both perfect forward secrecy and immunity to "man
in the middle" attacks. Imperfect implemantions give you neither.
[4] ...a clever implementation could use a time dependent password
scheme, or some other "smart server" authentication scheme that
supports secure password exchange over insecure channels ...
but, then, you could just implement that in PAM for SSH to
authenticate via, making the entire addition of port knocking moot.
[5] ...and if they were you wouldn't be arguing about port knocking. ;)
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
