Re: Darn skiddies (ssh login attempts)
On Mon, Apr 04, 2005 at 09:46:26AM -0700, Chris Adams wrote: Policy was the wrong word - the basic idea is just that either way the users have a password but a private key isn't directly replayable since the attacker doesn't actually receive the key information or password. Depending on the attack. That's the point I'm making--rsa keys protect against certain attacks but do absolutely nothing about other attacks and shouldn't be seen as a magic bullet. Central distribution is also quite easy and allows you to decide how much control you want over the process - simply change the authorized key path to a directory which isn't user-writable and use your existing management tools to synchronize changed keys. Dude, that does *nothing* to manage the private key. Not entirely. With passwords there's the important requirement that a password actually be sent through a compromised machine. With private keys, you're in trouble if any machine that the user happened to leave the key on gets compromised. Only if the key wasn't protected with a password - sure, it's possible for an attacker to brute-force the key but that's a lot more work than they'd have to do if you're using password authentication and it gives you more time to detect the intrusion and get users to change their keys. Huh? You do realize that the passphrase on the private key can be brute forced, and that it's possible to do so without connecting to the target system at all? (So that there is no record that someone is trying to brute-force the key password.) More importantly, good policy also tells users to use ssh-agent instead of copying private keys all over the place - sure, not everyone will do it but the same is true of password policies No, password policies are enforceable--you control what the user can set the password to. Key management policies are not enforceable. ssh-agent also intruduces another vulnerability in that new sessions can be started using the secret key for authentication without the user being aware that it's happening. The easiest way is simply to replace ssh-keygen with a wrapper which calls cracklib before passing the password to the real ssh-keygen. This also has the advantage of reusing any existing cracklib policy. Interesting. Now how do you keep the user from resetting their password on any system where you aren't controlling the ssh-keygen? Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
Michael Stone wrote: Depending on the attack. That's the point I'm making--rsa keys protect against certain attacks but do absolutely nothing about other attacks and shouldn't be seen as a magic bullet. They were also never portrayed as such - merely an additional layer of protection which has the side benefit of completely blocking some very widespread attacks. Central distribution is also quite easy and allows you to decide how much control you want over the process - simply change the authorized key path to a directory which isn't user-writable and use your existing management tools to synchronize changed keys. Dude, that does *nothing* to manage the private key. It allows you to step in the middle of the process - it's not simply a question of dropping a file in ~/.ssh/ with no checks. Since the user can't use any key they want this allows you have, say, a process of requiring a decent password, stashing the public key somewhere else, making the private key file immutable to prevent password changes or removal, and record an audit log entry (all of which could be done by an ssh-keygen wrapper). Only if the key wasn't protected with a password - sure, it's possible for an attacker to brute-force the key but that's a lot more work than they'd have to do if you're using password authentication and it gives you more time to detect the intrusion and get users to change their keys. Huh? You do realize that the passphrase on the private key can be brute forced, and that it's possible to do so without connecting to the target system at all? All of which is irrelevent - we're comparing it to plaintext authentication, where our hypothetical attacker already has their password without having to brute force anything. It also requires you to have a copy of the keyfile in the first place, which is harder than firing up an ssh brute-force bot. More importantly, good policy also tells users to use ssh-agent instead of copying private keys all over the place - sure, not everyone will do it but the same is true of password policies No, password policies are enforceable--you control what the user can set the password to. Key management policies are not enforceable. Right, but in the real world password policies don't work so well because normal humans don't handle high-entropy passwords well and they're going to find an algorithm which your policy doesn't catch, generate helpdesk traffic due to lost passwords and store it insecurely because they don't always remember it. The details aren't equivalent but the underlying problem is: you're going to have to depend on your users cooperating with your policy; if it's too onerous they'll find some way around it. ssh-agent also intruduces another vulnerability in that new sessions can be started using the secret key for authentication without the user being aware that it's happening. That's not actually true for all ssh-agent implementations but in any case, it's simply restating a point which was never in question: if the attacker has compromised the user's client they can already do anything they want. If they can violate host security to abuse your ssh-agent they can also capture everything else you do. The easiest way is simply to replace ssh-keygen with a wrapper which calls cracklib before passing the password to the real ssh-keygen. This also has the advantage of reusing any existing cracklib policy. Interesting. Now how do you keep the user from resetting their password on any system where you aren't controlling the ssh-keygen? The system I outlined above means that they can't simply use any random ssh key but, frankly, if your users are actively trying to subvert your security system you have bigger problems than script kiddies. You also can't prevent them from writing their password down, giving it to their office-mates, hard-coding it in a configuration file or storing it in some app's weak password store. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
On Mon, Apr 04, 2005 at 10:50:48AM -0700, Chris Adams wrote: They were also never portrayed as such - merely an additional layer of protection It's not an additional layer if you replace passwords with keys. It allows you to step in the middle of the process - it's not simply a question of dropping a file in ~/.ssh/ with no checks. Since the user can't use any key they want this allows you have, say, a process of requiring a decent password, stashing the public key somewhere else, making the private key file immutable to prevent password changes or removal, and record an audit log entry (all of which could be done by an ssh-keygen wrapper). Which implies that you're controlling both the client and the server, which begs the question of why you're exposed to attacks from random hosts in the first place... All of which is irrelevent - we're comparing it to plaintext authentication, where our hypothetical attacker already has their password without having to brute force anything. It also requires you to have a copy of the keyfile in the first place, which is harder than firing up an ssh brute-force bot. So you're comparing a MITM password attack to a secret key brute force attack. Apples and oranges, anyone? Right, but in the real world password policies don't work so well because normal humans don't handle high-entropy passwords well and they're going to find an algorithm which your policy doesn't catch, So? If you can't figure out the algorithm with brute force attacks (e.g., cracklib) it's fairly likely that an attacker using the same techniques can't either--which means that the password policy takes care of the attack we started out talking about at the start of the thread. These worms aren't using secret password cracking mojo, they're largely trying things like account guest/password guest and other trivially preventable problems. The compromises I've seen due to these ssh worms that are going around have *all* been on systems that didn't enforce strong password policies. That's why I find it vaguely humorous when people suggest that replacing the passwords with ssh keys is the right solution and then wave their hands about the key management problem. The tools and (admin/user) education needed to enforce password practices are *trivial* to implement compared to the tools and education required to secure private keys properly. If someone didn't implement passwords well, suggesting that switching to ssh keys without doing else will solve their security problems is a bit, well, far-fetched. ssh keys *can* be an effective tools, but *only* after doing a good risk assessment, understanding and accepting the new risks that ssh keys bring, and coming up with a good plan for deploying and using them in a secure manner. generate helpdesk traffic due to lost passwords As opposed to forgotten key passwords? Seems like a wash to me. and store it insecurely because they don't always remember it. Insecure storage is at the heart of the problems with ssh keys--you can't (with any sort of credibility) argue that users *can* store keys securely but *can't* store passwords securely. That's not actually true for all ssh-agent implementations And how do you control the client-side agent? The protocol allows it, so it's a vulnerability. case, it's simply restating a point which was never in question: if the Sure it was. At one point you (or someone) said that ssh keys were great because they couldn't be captured at intermediate hosts. But if you're forwarding the agent that attack vector is a wash. The system I outlined above means that they can't simply use any random ssh key but, frankly, if your users are actively trying to subvert your security system you have bigger problems than script kiddies. Welcome to real life. If your security relies entirely on users doing the right thing all the time you're going to get burned. A good security policy requires informed users but also some mechanisms to make it harder for people to screw up--unless your userbase is entirely infallible. (And I, for one, will welcome our new robotic overlords. :-) Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
On Fri, Apr 01, 2005 at 11:43:07AM -0800, Chris Adams wrote: There's no difference between the two as regards policy - it's a one-line command to change either a password or key, There's no difference? All of the tools to automatically expire passwords at a given interval, mandate minimum complexity in passwords, and then centralize all of that policy exist in a simple plug-and-play form on a typical debian install? Do tell. Some (not all) of these things are doable, some aren't even that hard, but they are not widely deployed or even considered. both, etc. - and it's still game-over if the user's client is trojaned. Not entirely. With passwords there's the important requirement that a password actually be sent through a compromised machine. With private keys, you're in trouble if any machine that the user happened to leave the key on gets compromised. It's not uncommon for users to leave keys all over the place--and you'll never know since you have essentially zero control over the private key. The two advantages to keys are the fact that a key doesn't get sent to the remote host (preventing the sort of collection attacks are becoming common on large networks) The key doesn't get sent but the key might be on a compromised host. It's a draw there. and that a key is effectively longer than a password, making a direct brute-force attack impossible and protecting you somewhat from casual attacks against weak passwords: Password complexity mandates prevent casual attacks against weak passwords also. How do you prevent weak rsa key passwords? Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
It worked. Being a person who reads these mailing-lists in order to gain experience, thank you. Regards, Anders Breindahl. On Saturday 02 April 2005 01:18, Henrique de Moraes Holschuh wrote: Sure. But I hope my post will make people at least read ldd(1)... That was the whole point. A new trick on their sleeves, so to speak. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
On Mar 31, 2005, at 11:40 PM, Robert Lemmen wrote: On Thu, Mar 31, 2005 at 10:44:53PM -0600, Brad Sims wrote: `less /var/log/auth.log|grep Failed|wc -l` shows 185 attempts to compromise my machine since March 27th... of course the only thing that really helps is good passwords, Or no passwords - if requiring public key authentication is feasible for a system you can disable password authentication entirely: PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no PAMAuthenticationViaKbdInt no If you have systems which for various reasons need to be accessible from many locations this is an excellent way to sleep a little easier. Given that many utilities exist to simplify ssh-agent use it's starting to be feasible to switch user-visible machines over to this configuration in many environments - ease of use is a big carrot. Chris smime.p7s Description: S/MIME cryptographic signature
Re: Darn skiddies (ssh login attempts)
On Thu, Mar 31, 2005 at 10:44:53PM -0600, Brad Sims wrote: Will not having the usual all: local break something? Yes: $ ldd `which portmap` libwrap.so.0 = /lib/libwrap.so.0 (0x4003) libnsl.so.1 = /lib/libnsl.so.1 (0x40039000) libc.so.6 = /lib/libc.so.6 (0x4004e000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) If you are using a GNOME environment (and thus, FAM, and thus, the portmapper) some services might not work properly (not only FAM, but posibly bonobo and oaf too). If, for some reason, you are using a database backend locally through TCP/IP instead of through UNIX sockets it will break too: $ ldd `which mysqld` librt.so.1 = /lib/librt.so.1 (0x4003) libwrap.so.0 = /lib/libwrap.so.0 (0x40042000) (...) If you try to use Nessus and establish local connections from the GUI to the server (Nessus does not use UNIX sockets, only TCP/IP), it will break too: $ ldd `which nessusd` libnasl.so.2 = /usr/lib/libnasl.so.2 (0x4003) (...) libwrap.so.0 = /lib/libwrap.so.0 (0x40248000) (...) Why not see for yourself? Try this to see which stuff in your system is compiled with libwrap (and thus uses tcpwrappers): for i in /usr/bin/* /usr/sbin/* /usr/local/bin/* /usr/local/sbin/* ; do \ [ -x $i ] [ -n file $i |grep ELF ] \ [ -n `ldd $i | grep libwrap` ] echo $i; \ done Regards Javier signature.asc Description: Digital signature
Re: Darn skiddies (ssh login attempts)
On Fri, Apr 01, 2005 at 01:23:09AM -0800, Chris Adams wrote: Or no passwords - if requiring public key authentication is feasible for a system you can disable password authentication entirely: I generally consider that to be a horrible idea. Instead of centrally managed password policies you now have your security entrusted to the security of all of your user's ssh keys. IME most users aren't really careful about how they handle those. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
Michael Stone wrote: On Fri, Apr 01, 2005 at 01:23:09AM -0800, Chris Adams wrote: Or no passwords - if requiring public key authentication is feasible for a system you can disable password authentication entirely: I generally consider that to be a horrible idea. Instead of centrally managed password policies you now have your security entrusted to the security of all of your user's ssh keys. IME most users aren't really careful about how they handle those. Sure, maybe a user does not handle the key carefully but do you think they are more careful with their password and don't write it down or something like this? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
On Fri, 01 Apr 2005, Michael Stone wrote: On Fri, Apr 01, 2005 at 01:23:09AM -0800, Chris Adams wrote: Or no passwords - if requiring public key authentication is feasible for a system you can disable password authentication entirely: I generally consider that to be a horrible idea. Instead of centrally managed password policies you now have your security entrusted to the security of all of your user's ssh keys. IME most users aren't really careful about how they handle those. Nowadays user passwords often end up being stolen, not broken (trojans, etc). Keys offer no degraded security in that scenario. But they don't offer improved security apart from stopping the brute-force attacks. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
On Fri, Apr 01, 2005 at 04:59:40PM +0200, Philipp Schulte wrote: Sure, maybe a user does not handle the key carefully but do you think they are more careful with their password and don't write it down or something like this? I'd rather have them write it down. Paper isn't subject to remote exploits. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
On Fri, Apr 01, 2005 at 12:11:29PM -0300, Henrique de Moraes Holschuh wrote: Nowadays user passwords often end up being stolen, not broken (trojans, etc). Keys offer no degraded security in that scenario. Wrong. It's much harder to force people to change keys than passwords. It's not impossible, but the tools aren't as common and there's this really unfortunate tendancy to think that keys are a magic bullet which keeps people from using what tools do exist. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
also sprach Chris Adams [EMAIL PROTECTED] [2005.04.01.2143 +0200]: you somewhat from casual attacks against weak passwords: if I obtain a copy of a user's password a public-key-only policy means that I still need some sort of privileged access to their home directory to exploit it - far from impossible but significantly more work for the kiddies. ... and you need a passphrase to decode the key -- or at least you *should* need one. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! #define emacs eighty megabytes and constantly swapping. signature.asc Description: Digital signature
Re: Darn skiddies (ssh login attempts)
On Thursday 31 March 2005 11:14 pm, Alvin Oga wrote: but make sure ssh is compiled with tcpwarppers, otherwise that lines are worthless How are they compiled by default on Sid? I think that ssh must be compiled that way by default as I had to add $WorkIP2 to allow access from that machine... but conformation would be nice -- Microsoft, Because $DEITY hates us. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
Hello *, On Fri, Apr 01, 2005 at 02:05:29PM -0600, Brad Sims wrote: On Thursday 31 March 2005 11:14 pm, Alvin Oga wrote: but make sure ssh is compiled with tcpwarppers, otherwise that lines are worthless How are they compiled by default on Sid? I think that ssh must be compiled that way by default as I had to add $WorkIP2 to allow access from that machine... but conformation would be nice ssh is compiled with support for tcp-wrappers. Taken from /usr/share/doc/ssh/README.Debian.gz, more confirmation could be taken from downloading and checking the Debian sources. HTH, Flo signature.asc Description: Digital signature
Re: Darn skiddies (ssh login attempts)
On Fri, 01 Apr 2005, Florian Ernst wrote: Taken from /usr/share/doc/ssh/README.Debian.gz, more confirmation could be taken from downloading and checking the Debian sources. ldd is your friend. Use it... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
On Fri, Apr 01, 2005 at 06:03:25PM -0300, Henrique de Moraes Holschuh wrote: On Fri, 01 Apr 2005, Florian Ernst wrote: Taken from /usr/share/doc/ssh/README.Debian.gz, more confirmation could be taken from downloading and checking the Debian sources. ldd is your friend. Use it... I personally do, but for some people information might be better suited if it is explicitely spelled out... Just the ldd output alone would still leave some people clueless as to the original problem, and mentioning documentation and sources could help people to help themselves... If you just want to point out how my posting wasn't completely exhaustive I'd definitely concur, though. Cheers, Flo signature.asc Description: Digital signature
Re: Darn skiddies (ssh login attempts)
On Sat, 02 Apr 2005, Florian Ernst wrote: I personally do, but for some people information might be better suited if it is explicitely spelled out... Just the ldd output alone would Sure. But I hope my post will make people at least read ldd(1)... That was the whole point. A new trick on their sleeves, so to speak. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Darn skiddies (ssh login attempts)
`less /var/log/auth.log|grep Failed|wc -l` shows 185 attempts to compromise my machine since March 27th... /etc/hosts.deny reads: ALL: ALL /etc/hosts.allow reads: sshd: $WORK_IP1 sshd: $WORK_IP2 Will not having the usual all: local break something? -- But when a long Train of Abuses and Usurpations...evinces a Design to reduce them under absolute Despotism, it is their Right, it is their Duty, to throw off such Government, and to provide new Guards for their future Security. -- Thomas Jefferson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
On Thu, Mar 31, 2005 at 10:44:53PM -0600, Brad Sims wrote: `less /var/log/auth.log|grep Failed|wc -l` shows 185 attempts to compromise my machine since March 27th... A similar command on the log server on a class B network (/16) shows 1482 such attempts in the past 19 hours or so. It's just a worm, and unless you've got a weak password policy, you don't have anything to worry about. Eventually you just get used to it. There's really not a whole lot that can be done to prevent it. /etc/hosts.deny reads: ALL: ALL /etc/hosts.allow reads: sshd: $WORK_IP1 sshd: $WORK_IP2 Will not having the usual all: local break something? Almost certainly not. Unless you routinely ssh to localhost. noah pgpHVhHWyIQlU.pgp Description: PGP signature
Re: Darn skiddies (ssh login attempts)
On Thu, 31 Mar 2005, Brad Sims wrote: `less /var/log/auth.log|grep Failed|wc -l` shows 185 attempts to compromise my machine since March 27th... /etc/hosts.deny reads: ALL: ALL good /etc/hosts.allow reads: sshd: $WORK_IP1 sshd: $WORK_IP2 good but make sure ssh is compiled with tcpwarppers, otherwise that lines are worthless - remove it and restart inet and you should no longer be able to ssh into it (though restarting inetd is not needed after changing it's files) Will not having the usual all: local break something? there is zero point to ssh localhost si yiu do NOT need to host.allow # bad idea ot have localhost sshd: localhost w.x.y.z allowing local will definitely break things .. local exploits of ssh or any daemon to become root on the box and you using daemon: all all : all being worst for allows c ya alvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Darn skiddies (ssh login attempts)
On Thu, Mar 31, 2005 at 10:44:53PM -0600, Brad Sims wrote: `less /var/log/auth.log|grep Failed|wc -l` shows 185 attempts to compromise my machine since March 27th... of course the only thing that really helps is good passwords, but i found this to be of great help too: http://blog.andrew.net.au/2005/02/17 cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
