On Wed, 9 Jan 2002, Douglas Trainor wrote:

You might browse this paper:

"Timing Analysis of Keystrokes and Timing Attacks on SSH" by Dawn Xiaodong Song, David Wagner, and Xuqing Tian. 10th USENIX Security Symposium, 2001. They're from UCB and they're smart.

This would be an argument against logging in as a normal user and then su to root wouldn't it? As I remember from a talk I heard lately it is rather easy to identify when a password is typed after you logged in. That's where you can use timing analysis. The password you type into ssh before you log in is sent in one batch in the login procedure.

...

If I su to root after logging in via ssh then I am still transmitting my root password (although it is encrypted). From a security standpoint, what's the difference in exposure?

The argument against allowing direct login to root are guessing attacks to the password. The attacker can try all sorts of passwords and if he gets it right he's root. If root's not allowed to login directly the attacker has to know any username first and if he breaks the password by guessing then he's only user (at first). On the other hand there are the timing attacks mentioned above (which I consider rather low risk). If you use any sort of key authentication no password will be sent ever but you really have to guard your keys. Cheers Robert -- Robert Casties --------------------- http://philoscience.unibe.ch/~casties History & Philosophy of Science Tel: +41/31/631-8505 Room: 216 Institute for Exact Sciences Sidlerstrasse 5, CH-3012 Bern Uni Bern (PGP key on homepage: 3C7E CAA6 0A2A 6955 AA25)

On Fri, 11 Jan 2002, Kurt Seifried wrote:

Basically it's a lesson that yes traffic analysis works, and it can be combatted intelligently. Things like putting in a timing loop to openssh and delaying packets till the next 10 or 50 ms interval for example so packet timing gets delayed a bit and isn't as informative. As for guessing

That question (as most in software design) is full of tradeoffs. People using ssh interactively want uniform short delays. That behaviour enables timing attacks. A steady flow of encrypted traffic regardless of interactive use would be optimal from a security standpoint but a waste of bandwidth. Robert -- Robert Casties --------------------- http://philoscience.unibe.ch/~casties History & Philosophy of Science Tel: +41/31/631-8505 Room: 216 Institute for Exact Sciences Sidlerstrasse 5, CH-3012 Bern Uni Bern (PGP key on homepage: 3C7E CAA6 0A2A 6955 AA25)

From the remoteadmin box, you build up a VPN and make the ssh session

On Wed, 9 Jan 2002, Douglas Trainor wrote:

...

You might browse this paper:

"Timing Analysis of Keystrokes and Timing Attacks on SSH" by Dawn Xiaodong Song, David Wagner, and Xuqing Tian. 10th USENIX Security Symposium, 2001. They're from UCB and they're smart.

This would be an argument against logging in as a normal user and then su to root wouldn't it? As I remember from a talk I heard lately it is rather easy to identify when a password is typed after you logged in. That's where you can use timing analysis. The password you type into ssh before you log in is sent in one batch in the login procedure.

...

...

If I su to root after logging in via ssh then I am still

Hi, If we really want to talk paranoia :-), you could do it like that: Put a box with some kind of VPN functionality in front of the server or do it directly on the server in question. Allow ssh only through this tunnel. through this tunnel. For the VPN, you can use some kind of key authentication, for the ssh you can use normal username/password login. Your gain is: - someone must penetrate first your VPN - after that, they have to do the ssh-password trick - from network traffic analysis, the sniffer can't see, what kind of data is transmitted to the server - portscans won't reveal ssh Regards Reto Inversini ----- Original Message ----- From: "Robert Casties" To: "Douglas Trainor" Cc: "Matt Hubbard" ; Sent: Friday, January 11, 2002 10:25 AM Subject: Re: [suse-security] remote admin: su vs login as root transmitting my

...

...

root password (although it is encrypted). From a security standpoint, what's the difference in exposure?

The argument against allowing direct login to root are guessing attacks to the password. The attacker can try all sorts of passwords and if he gets it right he's root.

If root's not allowed to login directly the attacker has to know any username first and if he breaks the password by guessing then he's only user (at first). On the other hand there are the timing attacks mentioned above (which I consider rather low risk).

If you use any sort of key authentication no password will be sent ever but you really have to guard your keys.

Cheers Robert

-- Robert Casties --------------------- http://philoscience.unibe.ch/~casties History & Philosophy of Science Tel: +41/31/631-8505 Room: 216 Institute for Exact Sciences Sidlerstrasse 5, CH-3012 Bern Uni Bern (PGP key on homepage: 3C7E CAA6 0A2A 6955 AA25)

-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com

* Peter Nixon wrote on Fri, Jan 11, 2002 at 19:35 +0200:

On Fri, 11 Jan 2002 11:53:47 +0100 "Reto Inversini" wrote:

more of the ipsec capability in the native kernel, but Rusty said that he's never going to include it in it's current state, as a) buggy b) possibly/probably has remote root exploits in the userspace daemons c) doesn't hook into the rest of the kernel correctly

Yes, sometimes it seems that freeswan is not really clean and bullet-proof. There are cases where it isn't fitting correctly and such. Well, it's a really complex thing. The bug history of course is not small...

Now I ask you. What would you prefer to run as your face to the world?

- OpenSSH

It would prefere OpenSSH for Shell-Access things. But I wouldn't use portforwarding constructions if more than shell access is needed.

- FreeSwan - Which is written by a small subset of the Linux community, and is regarded the guy who writes the linux firewall code as buggy??

I would use it when I do need secure IP layer security, i.e. when needing non-shell services. OpenSSH lives on Application Layer. But this, you can identify users (not machines). It's more "endpoint-endpoint" than network level crpytography. OpenSSH allowes to fine grain permissions by user, source and whatever. On network level this is not possible. OpenSSH updates are much more easy (especially remotely) that freeswan/kernel updates, makes your chance of fast reaction greater. OpenSSH is more easy to set up correctly (especially if you have also Windows-Clients). OpenSSH get's usually involed by user interaction, which makes it easy to put the keys on floppies instead of theoretically potential compromized hard disks (with floppies, an attacker need additonally guess the timepoint when the floppy is inserted. Well, not the after-all solution, but a litlle better that HDDs). OpenSSH makes it more easy to use passphrases; IPSec gets startet usually autoamtically and transparent, which requires that some automatism can get the plain keys without user interaction. An Attacker can use IPSec without users notice more easy than hijacking an SSH session I think (in case of IPSec, the attacker needs just to connect :)). So finally I think I would use OpenSSH if possible. But if you need network (application transparent) security, you should use IPSec instead of OpenSSH + pppd or such non-reliable constructions (I tried this once, and in the test environment there were many fails without noticeable resons and so on). oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.