Wellllllll........ 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 > 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 > -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
