We
I don't know what makes you flame so hard with a simple suggestion of mine.
I've tested PortKnock, I like it and I feel comfortable with it. Since Phill
had asked an open question for alternative approaches to secure his network,
I made a simple suggestion.
I don't know why you take it so personally to prove your point better than
mine and start an all out war with it, or is it the technical supremacy ego
that kicks in at times...
Mate, we all don't know everything, but we're here to learn and share with
others... I'm sure you have more knowledge and experience than me and I
respect you for that. And I'm sure your CGI script or some other approach
would do the trick just fine, but what I learnt along the way I thought
of sharing in this space am I wrong for it, you be the judge.
Cheers Slug,
Brian
On 10/11/08, Daniel Pittman [EMAIL PROTECTED] wrote:
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
