Re: [SLUG] ssh certificate logins
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
[SLUG] Re: Atom Processor - what distro works?
Thanks Ken and Dion for the replies. I tried posting to the Slug List via my ISP's WebMail whilst in Osaka, but the post is apparently still being held pending Moderator approval. The Mini-ITX board I bought is an Intel D945GCLF2 which has a Dual-Core Atom Processor and integrated graphics, and has DDR2 667/533 memory support ( 2GB max). Link http://downloadcenter.intel.com/filter_results.aspx?strTypes=allProductID=2926OSFullName=All+Operating+Systemslang=engstrOSs=Allsubmit=Go! plus ITX board reviews http://www.geek.com/articles/xyzcomputing/mini-itx-2005095/ in which the Intel board comes out on top. Board cost 10800 Yen ( sale prce ) which, depending on currency exchang rate of the day, wil be somewhere around $130 Aust. I was spending Yen cash that I purchased last year for 92=$1 Aust so I got it for a good price :-P Bill -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] ssh certificate logins
Brian Sydney Jathanna [EMAIL PROTECTED] writes: We I don't know what makes you flame so hard with a simple suggestion of mine. I am not, by the traditional meaning of the term, flaming you here, though I will grant you that I am not working hard to be being especially nice about it. Because this /is/ important, let me explain why: I've tested PortKnock, I like it and I feel comfortable with it. Great. The problem is that while you like it, and feel comfortable with it, you don't really /understand/ it, especially not in the bigger picture of security, do you? Port Knocking is complicated, but it isn't any more secure than a wide range of alternatives, including the CGI option I mentioned -- in my opinion. One of the consistent lessons in security is that complexity is an invitation to failure -- you are more secure with the simplest solution that works, and adding complexity often *reduces* the protection you get. On the other hand, the reason that I asked you to define how it was more secure, or to detail how it protected from threats, was to give you a chance to prove my assumptions wrong. Perhaps you /had/ thought about and understood the wider security picture, or perhaps you could cite something other than personal feeling as a basis for believing that Port Knocking was a secure option. What you are advocating is that someone else *feel* secure without *being* secure. This is like advising them to put a magic crystal on their dashboard and forget about seatbelts -- it works just fine, until it actually matters, at which point it turns out to have added no value at all. Since Phill had asked an open question for alternative approaches to secure his network, I made a simple suggestion. Yup. 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... This isn't about winning -- I have nothing to gain from beating you, personally, or being more right here. If this was just a matter of opinion question, like the best distribution, or which text editor to use, and we disagreed like this I would shrug and accept that -- each person is different and all that. 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. I hope that the explanation above helps explain why I am reluctant to let this go -- why I have been asking you to explain why you are correct, even if I don't believe you. Finally, a large part of the problem is not my views -- I know that I have done enough in the security area to keep my systems secure, and to tell the difference between snake oil and security, most of the time. What I worry about are the people out there who don't have that experience, but see you advocating something that will leave them at risk -- and follow through, then end up burned by it. To me, this is like airport security: I am all in favour of securing air travel. I am not in favour of doing things that make people *feel* secure without actually doing a damn thing. Regards, Daniel -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] ssh certificate logins
2008/10/12 Daniel Pittman [EMAIL PROTECTED]: [snip] To me, this is like airport security: I am all in favour of securing air travel. I am not in favour of doing things that make people *feel* secure without actually doing a damn thing. Regards, Daniel Hey, Just to quickly weigh in on this... Port knocking, as long as it is not the entire security strategy could be a relevent addition here. The problem as stated by the OP is 'idiots from eastern Europe and Russia tring to crack my server'. The layer of obscurity that port knocking adds could be considered akin to changing the port number and even that small change often drops the number of attempts to zero (judging by the many reports and responses on other lists and forums). If someone is actually trying to break _your_ server then it won't help much, as you said, but if the intent is to break _a_ server then it may be sufficient to make them move on. In this regard a really simple sequence is just as effective as anything more complex. The vaunted airport 'security theatre' efforts are similar here in that they help prevent casual or impulsive incidents but (arguably) don't do much for any true, concerted efforts. cheers, Owen. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] ssh certificate logins
Owen Townend [EMAIL PROTECTED] writes: 2008/10/12 Daniel Pittman [EMAIL PROTECTED]: [snip] To me, this is like airport security: I am all in favour of securing air travel. I am not in favour of doing things that make people *feel* secure without actually doing a damn thing. Just to quickly weigh in on this... Port knocking, as long as it is not the entire security strategy could be a relevent addition here. The problem as stated by the OP is 'idiots from eastern Europe and Russia tring to crack my server'. *nod* I don't actually disagree. The layer of obscurity that port knocking adds could be considered akin to changing the port number and even that small change often drops the number of attempts to zero (judging by the many reports and responses on other lists and forums). Just as long as, you know, it doesn't get broadly taken up, at which point the value drops to zero. ;) If someone is actually trying to break _your_ server then it won't help much, as you said, but if the intent is to break _a_ server then it may be sufficient to make them move on. In this regard a really simple sequence is just as effective as anything more complex. I don't actually disagree with you here: it can add some value, for you, while it remains essentially ignored by the wider community. (Well, provided that the port knocking daemon doesn't add additional vulnerabilities, which for the trivial watch the firewall logs implementation, it almost certainly doesn't.) I think that y'all would be much better off using something like a VPN which provides a much more standard, tested and secure solution, or something like the Apache/CGI solution. Those also have the advantage that they /continue/ to work no matter what other people do. (Plus, you know, real security at about the same setup cost ;) The vaunted airport 'security theatre' efforts are similar here in that they help prevent casual or impulsive incidents but (arguably) don't do much for any true, concerted efforts. I don't think that there are many casual or impulsive efforts to destroy or hijack planes -- or to brute force SSH passwords, come to that -- but I take your point. Regards, Daniel Footnotes: [1] I say generally because I am not aware of any incidents of this type, ever, but I am only a casual student of this sort of thing, really. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
