Re: improving ssh
Doesn't this belong on the old SSHv2 WG's mailing list? On Sat, Jul 14, 2007 at 11:43:53AM -0700, Ed Gerck wrote: SSH (OpenSSH) is routinely used in secure access for remote server maintenance. However, as I see it, SSH has a number of security issues that have not been addressed (as far I know), which create unnecessary vulnerabilities. The SSHv2 protocol or OpenSSH (an implementation of SSHv1 and SSHv2)? Some issues could be minimized by turning off password authentication, which is not practical in many cases. Other issues can be addressed by additional means, for example: 1. firewall port-knocking to block scanning and attacks Do you think that implementations of the protocol should implement this? (From what you say below I think your answer is yes. Which brings up the questions why? and how?) 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) SSH servers could integrate features like this without needing firewall APIs. 3. pre- and post-filtering to prevent SSH from advertising itself and server OS Unfortunately SSH implementations tend to depend on accurate client and server software version strings in order to work around bugs. Anyways, security by obscurity doesn't help. 4. block empty authentication requests What are those? Are they requests with an empty username? The only SSHv2 userauth methods that support that are the GSS ones, and that's a good feature (it allows the server to derive the username from the client's principal name). 5. block sending host key fingerprint for invalid or no username Currently the only way to do this is to configure SSH servers to support only SSHv2 and only the gss-* key exchange algorithms (see RFC4462, section 2). There exist implementations that support this. To get rid of the host authenticates itself first attitude for all non-GSS-based SSHv2 userauth methods will require radical changes to the protocol and deployment transitions. 6. drop SSH reply (send no response) for invalid or no username The server has to answer with something. Silence is still an answer. So is closing the TCP connection. I believe it would be better to solve them in SSH itself, as one would not have to change the environment in order to further secure SSH. Changing firewall rules, for example, is not always portable and may have unintended consequences. Coding to firewall APIs is even less portable (heck, not all OSes have firewall APIs). Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: improving ssh
On Sat, Jul 14, 2007 at 11:43:53AM -0700, Ed Gerck wrote: SSH (OpenSSH) is routinely used in secure access for remote server maintenance. However, as I see it, SSH has a number of security issues that have not been addressed (as far I know), which create unnecessary vulnerabilities. Some issues could be minimized by turning off password authentication, which is not practical in many cases. Other issues can be addressed by additional means, for example: 1. firewall port-knocking to block scanning and attacks That is, security by obscurity and either adding another dependency (libpcap) or code involving many incompatibilities between systems which OpenSSH portable is ported to (raw sockets interface). I think this can explain why it wasn't included in OpenSSH. 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) Actually, this can be done at PAM library level with similar effectiveness and greater simplicity (I did it some time ago as a PoC). Dictionary attacks, however, should be prevented from by forcing users to select strong passwords (appropriate PAM module, again). 3. pre- and post-filtering to prevent SSH from advertising itself and server OS Something like tcpwrappers? I think, this would be pre-filtering. How would you want to do post-filtering? And why not to advertise SSH version? There are as many pros as cons. 4. block empty authentication requests What kind of requests are you talking about? 5. block sending host key fingerprint for invalid or no username 6. drop SSH reply (send no response) for invalid or no username ...so one can easily enumerate existing system users. And you didn't mention about 7. removing subliminal channels in D-H key agreement and IV choosing for CBC and CTR modes. This issue was brought up (for SSH, SSL and IKE/ESP) about year ago in Poland. You know, kleptography is a funny thing. -- Stanislaw Klekot - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: improving ssh
On 7/14/07, Ed Gerck [EMAIL PROTECTED] wrote: 1. firewall port-knocking to block scanning and attacks I would love to see a mode like freenet's silent bob, where connectors must prove probable knowledge of the host key before the node will talk. 5. block sending host key fingerprint for invalid or no username This makes some sense... 1. Client may request proof of host private key. 2. Client must authenticate. 3. Client may request a copy of the host public key. -- Taral [EMAIL PROTECTED] Please let me know if there's any further trouble I can give you. -- Unknown - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: improving ssh
On Jul 14, 2007, at 2:43 PM, Ed Gerck wrote: 1. firewall port-knocking to block scanning and attacks 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) 3. pre- and post-filtering to prevent SSH from advertising itself and server OS 4. block empty authentication requests 5. block sending host key fingerprint for invalid or no username 6. drop SSH reply (send no response) for invalid or no username None of these are crypto issues. The OpenSSH dev list (http:// www.openssh.com/list.html) would almost certainly lend itself to a more productive discussion of these concerns. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: improving ssh
Ivan Krstić wrote: On Jul 14, 2007, at 2:43 PM, Ed Gerck wrote: 1. firewall port-knocking to block scanning and attacks 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) 3. pre- and post-filtering to prevent SSH from advertising itself and server OS 4. block empty authentication requests 5. block sending host key fingerprint for invalid or no username 6. drop SSH reply (send no response) for invalid or no username None of these are crypto issues. Perhaps not the way they are solved today (see above), and that IS the problem. For example, the lack of good crypto solutions to protocol bootstrap contributes significantly to security holes 1-7. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: improving ssh
i'm an OpenBSD developer, so i have some knowlege but could be biased. SSH (OpenSSH) is routinely used in secure access for remote server maintenance. However, as I see it, SSH has a number of security issues that have not been addressed (as far I know), which create unnecessary vulnerabilities. Some issues could be minimized by turning off password authentication, which is not practical in many cases. Other issues can be addressed by additional means, for example: 1. firewall port-knocking to block scanning and attacks 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) i guess it can be handled in lines of spamd (greylisting) on OpenBSD. 3. pre- and post-filtering to prevent SSH from advertising itself and server OS is there any point in this as you can fingerprint OS both actively (nmap) and passively (p0f)? 4. block empty authentication requests 5. block sending host key fingerprint for invalid or no username 6. drop SSH reply (send no response) for invalid or no username i can understand your desire, but this is a feature used by some of the anonymous services such as anonymous CVS. i'd leave it to openssh developers. itojun - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: improving ssh
Ed Gerck [EMAIL PROTECTED] writes: Some issues could be minimized by turning off password authentication, which is not practical in many cases. That would probably make things much worse. A study of SSH attacks a few years ago showed that nearly two thirds of all SSH private keys were stored on disk with no protection at all, so that simply being able to read a hard drive will get you access to any number of systems without having to trojan the SSH client or plant a keyboard logger as you'd need for an SSH password. So turning off password auth would make things less secure, not more. 1. firewall port-knocking to block scanning and attacks 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) I started work on an paper that looked at doing exactly this based on traces from SSH scanning attacks a year or two back, and realised that this is an arms race that you can't win. No matter what heuristics you use, all an attacker has to do is change their scanning pattern to avoid them and all your work is rendered useless. The reason I never finished the paper (well, apart from that fact that this type of defence is a lost cause) is because there's a much easier way to do this than at the firewall or network level. There's a paper by Pinkas and Sander, Securing Passwords Against Dictionary Attacks, later updated by van Oorschot in a TISSEC paper (sorry, don't have the ref.handy) that contains a very nice, elegant way to defeat SSH (and, in general, any password-based protocol) scanning attacks. I have an RFC draft to add this to SSH on the back burner, I just haven't finished it yet because (a) too many other things to do and (b) I'm not sure how it'll be received by the SSH community, who seem to see public-key auth as the answer to any problem. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
summary, Re: improving ssh
List, Thanks everyone for the feedback. There are now some ideas how things could be improved using crypto. I prepared a summary of the public and private responses, and clarifications, at: http://email-security.blogspot.com/2007_07_01_archive.html Comments are welcome in here (if crypto) an in the blog in general. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
improving ssh
List, SSH (OpenSSH) is routinely used in secure access for remote server maintenance. However, as I see it, SSH has a number of security issues that have not been addressed (as far I know), which create unnecessary vulnerabilities. Some issues could be minimized by turning off password authentication, which is not practical in many cases. Other issues can be addressed by additional means, for example: 1. firewall port-knocking to block scanning and attacks 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) 3. pre- and post-filtering to prevent SSH from advertising itself and server OS 4. block empty authentication requests 5. block sending host key fingerprint for invalid or no username 6. drop SSH reply (send no response) for invalid or no username I believe it would be better to solve them in SSH itself, as one would not have to change the environment in order to further secure SSH. Changing firewall rules, for example, is not always portable and may have unintended consequences. So, I'd like to get list input (also by personal email if you think your comment might be out of scope here), on issues #1-6 above and if you have other SSH security issues that you would like to see solved /in SSH/. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
