Re: [SLUG] ssh certificate logins
Mary Gardiner wrote: There is one potential disadvantage of non-standard ports: there are a few networks with a default-deny outgoing connection policy who open port 22, but do not open most ports. (I find 443 the most useful alternative port to run SSH on, outgoing to 443/HTTPS is very often open!) OK, raise their hand everyone here who runs an SSH server somewhere out on the net on port 443 for the deliberate purpose of tunneling through a work-related proxy server / firewall combination to do non-proxy-allowed stuff. (/me sheepishly raises hand) (/me points at *everyone* at a certain large organisation that will remain nameless) :) Del -- 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 Del [EMAIL PROTECTED]: Mary Gardiner wrote: There is one potential disadvantage of non-standard ports: there are a few networks with a default-deny outgoing connection policy who open port 22, but do not open most ports. (I find 443 the most useful alternative port to run SSH on, outgoing to 443/HTTPS is very often open!) OK, raise their hand everyone here who runs an SSH server somewhere out on the net on port 443 for the deliberate purpose of tunneling through a work-related proxy server / firewall combination to do non-proxy-allowed stuff. (/me sheepishly raises hand) (/me points at *everyone* at a certain large organisation that will remain nameless) :) Del /me raises hand Though only since contracting at said large organisation[1]... there are other ways at uni. cheers, Owen. Footnotes: -- [1] Assuming we're thinking of the same one... otherwise... it's the same idea. -- 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
On Sun, Oct 12, 2008 at 09:48:59PM +1100, Owen Townend wrote: 2008/10/12 Del [EMAIL PROTECTED]: Mary Gardiner wrote: There is one potential disadvantage of non-standard ports: there are a few networks with a default-deny outgoing connection policy who open port 22, but do not open most ports. (I find 443 the most useful alternative port to run SSH on, outgoing to 443/HTTPS is very often open!) OK, raise their hand everyone here who runs an SSH server somewhere out on the net on port 443 for the deliberate purpose of tunneling through a work-related proxy server / firewall combination to do non-proxy-allowed stuff. (/me sheepishly raises hand) (/me points at *everyone* at a certain large organisation that will remain nameless) sort of, I use 563 which is nntps and many large org's allow this through as well, I did this before openvpn could shadow a port so that you can have 443 be https and openvpn Alex :) Del /me raises hand Though only since contracting at said large organisation[1]... there are other ways at uni. cheers, Owen. Footnotes: -- [1] Assuming we're thinking of the same one... otherwise... it's the same idea. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html signature.asc Description: Digital signature -- 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
On Sunday 12 October 2008 10:00:04 [EMAIL PROTECTED] wrote: 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. IMHO port knocking is a silly waste of complexity, specially since establishing (in practice) that non-standard ports makes the problem disappear so in that respect I found Daniels arguments well presented and met the goals of 'learn and share'. He may have presented his argument pedantically, but each and every assertion is presented in a way that I can debate or test, so it was very useful James -- 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
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
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
Re: [SLUG] ssh certificate logins
Port Knock service secures the network by having all the ports closed and listens on a secret port for the secret handshake. When the client intiates a connection, the connection is verified through the internal database as to which service the particular client has access to. 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. And in the whole process passwords are never exchanged. The advantage gained here is the client is given access to the required service only within the requested session, which defeats port scanners, sniffers, network hijackers and the rest of the scum. Cheers, Brian On 10/10/08, Daniel Pittman [EMAIL PROTECTED] wrote: Brian Sydney Jathanna [EMAIL PROTECTED] writes: On 10/9/08, Phill O'Flynn [EMAIL PROTECTED] wrote: Hi everyone I am running a fedora server and currently using hosts.allow to only allow ssh accesses from specific ip addresses. I did this because I was getting a lot of idiots from eastern Europe and Russia tring to crack my server. This has been ok but now is prooving to be too restrictive. Can I get the server to force certificate based logins only?? If so how do I do it?? Is this the best approach anyway?? I guess the best approach would be to consider using Port Knock http://www.portknocking.org/ Why would you consider that the best approach? Port knocking is an additional password specified through a non-standard mechanism, plus the added security of doing strange IP related things. You gain *exactly* as much protection by providing yourself a CGI script where you can enter a password and have the firewall modify your firewall dynamically, without the added complexity or debugging of having to find out why your IP based knock was delivered out of order, or any of the other potential issues. 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 -- 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: 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
Re: [SLUG] ssh certificate logins
2008/10/9 Phill O'Flynn [EMAIL PROTECTED]: Hi everyone I am running a fedora server and currently using hosts.allow to only allow ssh accesses from specific ip addresses. I did this because I was getting a lot of idiots from eastern Europe and Russia tring to crack my server. This has been ok but now is prooving to be too restrictive. Can I get the server to force certificate based logins only?? If so how do I do it?? Is this the best approach anyway?? In debian based systems it's done by editing /etc/ssh/sshd_config to disable password auth I imagine that Fedora would be very similar... see: http://www.debuntu.org/ssh-key-based-authentication-p3 There was a good thread arguing ssh protection measures a few months back on debian-security: http://www.nabble.com/What-to-do-about-SSH-brute-force-attempts--tt19090071.html#a19090071 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
Phill O'Flynn wrote: I am running a fedora server and currently using hosts.allow to only allow ssh accesses from specific ip addresses. I did this because I was getting a lot of idiots from eastern Europe and Russia tring to crack my server. This has been ok but now is prooving to be too restrictive. Can I get the server to force certificate based logins only?? If so how do I do it?? Is this the best approach anyway?? Also have a look at pam_abl: http://www.hexten.net/wiki/index.php/Pam_abl Erik -- - Erik de Castro Lopo - Anyone who says you can have a lot of widely dispersed people hack away on a complicated piece of code and avoid total anarchy has never managed a software project. - Andy Tanenbaum in 1992 on comp.os.minix -- 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
you can configured your sshd's configuration in /etc/ssh/sshd_config however in your case you might want to look at denyhosts http://denyhosts.sourceforge.net/ Dean Phill O'Flynn wrote: Hi everyone I am running a fedora server and currently using hosts.allow to only allow ssh accesses from specific ip addresses. I did this because I was getting a lot of idiots from eastern Europe and Russia tring to crack my server. This has been ok but now is prooving to be too restrictive. Can I get the server to force certificate based logins only?? If so how do I do it?? Is this the best approach anyway?? Regards Phill O'Flynn -- http://fragfest.com.au -- 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
On Friday 10 October 2008 07:29:25 [EMAIL PROTECTED] wrote: I am running a fedora server and currently using hosts.allow to only allow ssh accesses from specific ip addresses. I did this because I was getting a lot of idiots from eastern Europe and Russia tring to crack my server. This has been ok but now is prooving to be too restrictive. Can I get the server to force certificate based logins only?? If so how do I do it?? Is this the best approach anyway?? On a non-standard port I've had ZERO login attempts over the last 3+ years, compared (like you) to 10s and 100s per day. This is trivial to implement even has the advantage of multiple servers/virtual servers behind a DSL router (different non standard for each) James -- 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
Erik de Castro Lopo [EMAIL PROTECTED] writes: Phill O'Flynn wrote: I am running a fedora server and currently using hosts.allow to only allow ssh accesses from specific ip addresses. I did this because I was getting a lot of idiots from eastern Europe and Russia tring to crack my server. This has been ok but now is prooving to be too restrictive. Can I get the server to force certificate based logins only?? If so how do I do it?? Is this the best approach anyway?? Also have a look at pam_abl: http://www.hexten.net/wiki/index.php/Pam_abl Oh, nice tool. It is a pity that it isn't maintained upstream any longer, or packaged for Debian / Ubuntu. Being a PAM module is especially nice, since it means that this would work for *any* PAM integrated application, not just SSH. Personally, I use fail2ban[1] which uses the cruder, but still effective, technique of reading your logs and blocking people who try to guess passwords via iptables. I like it better than most of the alternatives because, unlike many tools, it ships with configuration for a range of services in addition to the basic ssh stuff. So, you can detect the same brute-force attacks via IMAP, POP, FTP, or any of the other common sources of this.[2] Regards, Daniel Footnotes: [1] http://fail2ban.sf.net/ [2] I am still amazed, in fact, that more of the brute forcing is not targetted at POP/IMAP accounts and passwords, since the mapping is frequently trivial to real accounts, and they are monitored so much less effectively. -- 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
On Fri, Oct 10, 2008, jam wrote: On a non-standard port I've had ZERO login attempts over the last 3+ years, compared (like you) to 10s and 100s per day. This is trivial to implement even has the advantage of multiple servers/virtual servers behind a DSL router (different non standard for each) There is one potential disadvantage of non-standard ports: there are a few networks with a default-deny outgoing connection policy who open port 22, but do not open most ports. (I find 443 the most useful alternative port to run SSH on, outgoing to 443/HTTPS is very often open!) -Mary -- 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
I guess the best approach would be to consider using Port Knock http://www.portknocking.org/ Cheers, Brian On 10/9/08, Phill O'Flynn [EMAIL PROTECTED] wrote: Hi everyone I am running a fedora server and currently using hosts.allow to only allow ssh accesses from specific ip addresses. I did this because I was getting a lot of idiots from eastern Europe and Russia tring to crack my server. This has been ok but now is prooving to be too restrictive. Can I get the server to force certificate based logins only?? If so how do I do it?? Is this the best approach anyway?? Regards Phill O'Flynn -- 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
Re: [SLUG] ssh certificate logins
Brian Sydney Jathanna [EMAIL PROTECTED] writes: On 10/9/08, Phill O'Flynn [EMAIL PROTECTED] wrote: Hi everyone I am running a fedora server and currently using hosts.allow to only allow ssh accesses from specific ip addresses. I did this because I was getting a lot of idiots from eastern Europe and Russia tring to crack my server. This has been ok but now is prooving to be too restrictive. Can I get the server to force certificate based logins only?? If so how do I do it?? Is this the best approach anyway?? I guess the best approach would be to consider using Port Knock http://www.portknocking.org/ Why would you consider that the best approach? Port knocking is an additional password specified through a non-standard mechanism, plus the added security of doing strange IP related things. You gain *exactly* as much protection by providing yourself a CGI script where you can enter a password and have the firewall modify your firewall dynamically, without the added complexity or debugging of having to find out why your IP based knock was delivered out of order, or any of the other potential issues. 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
On 10/10/2008, at 10:58 AM, Daniel Pittman wrote: Personally, I use fail2ban[1] which uses the cruder, but still effective, technique of reading your logs and blocking people who try to guess passwords via iptables. I use with great success an iptables rule to limit new ssh connections to 2 or 3 a minute, brute forcers will get a few attempts, then timeout and move on. -- http://chesterton.id.au/blog/ http://barrang.com.au/ -- 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
On Fri, Oct 10, 2008 at 03:41:57PM +1100, Michael Chesterton wrote: On 10/10/2008, at 10:58 AM, Daniel Pittman wrote: Personally, I use fail2ban[1] which uses the cruder, but still effective, technique of reading your logs and blocking people who try to guess passwords via iptables. I use with great success an iptables rule to limit new ssh connections to 2 or 3 a minute, brute forcers will get a few attempts, then timeout and move on. thats what I have found as well. for example the rules I am using now are iptables -A INPUT -i internet interface -p tcp --dport 22 -j SSH iptables -t filter -A SSH -m recent --set --name SSH iptables -t filter -A SSH -m recent --name SSH ! --rcheck --seconds 300 --hitcount 4 -j RETURN # Well, the NEW connection has been seen so let's update the SSH # recent list. iptables -t filter -A SSH -m recent --name SSH --update # I like to log on a line by it's self so I don't have to remember # to do it on my last line prior to the end of my script. iptables -t filter -A SSH --jump ULOG $ULOG_OPTIONS --ulog-prefix sydrt01 (SSH) iptables -t filter -A SSH -j DROP -- http://chesterton.id.au/blog/ http://barrang.com.au/ -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- The truth of that matter is, if you listen carefully, Saddam would still be in power if he were the president of the United States, and the world would be a lot better off. - George W. Bush 10/08/2004 St. Louis, MO Second presidential debate signature.asc Description: Digital signature -- 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
Well, Michael and Alex beat me to it. That's what I was going to say; use iptables. Though Alex's rules are somewhat more complex than mine, I think mine do the same. After setting up the chain, my salient rule is just; -A INBOUND_FILTER -i eth0 -p tcp -m tcp --dport 22 -m limit --limit 2/minute --limit-burst 2 -m state --state NEW -j ACCEPT Kind Regards Kyle Alex Samad wrote: On Fri, Oct 10, 2008 at 03:41:57PM +1100, Michael Chesterton wrote: I use with great success an iptables rule to limit new ssh connections to 2 or 3 a minute, brute forcers will get a few attempts, then timeout and move on. thats what I have found as well. for example the rules I am using now are iptables -A INPUT -i internet interface -p tcp --dport 22 -j SSH iptables -t filter -A SSH -m recent --set --name SSH iptables -t filter -A SSH -m recent --name SSH ! --rcheck --seconds 300 --hitcount 4 -j RETURN # Well, the NEW connection has been seen so let's update the SSH # recent list. iptables -t filter -A SSH -m recent --name SSH --update # I like to log on a line by it's self so I don't have to remember # to do it on my last line prior to the end of my script. iptables -t filter -A SSH --jump ULOG $ULOG_OPTIONS --ulog-prefix sydrt01 (SSH) iptables -t filter -A SSH -j DROP -- http://chesterton.id.au/blog/ http://barrang.com.au/ -- 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
