Re: [cobalt-security] SFTP on Raq4 as Root?

["Stephen Rice" <support@xxxxxxxxxxxxxxxxxxxxxx>]

Well I think John and Zeffie have more or less sorted themselves out, but
just to clear up a few misunderstandings... (alternatively, skip to the last
paragraph!)

Zeffie wrote:
> > To be honest, if "Mr BadGuy" has root privilege on your box, that's
> > the least of your worries!
> Actually it's going to be your first thing to worry about.... Remember...
> You need it before you can do anything as root
Yes you do. I'm not disputing that. But as I already said, an intruder could
equally change your root password (or delete telnet, change your sshd_config
for that matter) if they really wanted to lock you out. Not having to su
isn't really that much of a help here. You're right you want to get in quick
and fix things. I'm just saying that making it more difficult for someone to
retain control once they're in is probably not as good as making it more
difficult for them to get that control in the first place.

> > Why do you think Raqs have this two-level admin user setup?
> the Raq's are based on redhat..  And thats why they are the way they are.
I didn't ask what distribution they're based on, I asked why that feature
was put there. Whether Cobalt did it or RedHat is beside the point. You may
as well say that a new car model has lights because the previous one did,
rather than for seeing in the dark.

> Root logins via telnet has been a no no for a long time...  and thus the
> need to login with a user account and then su to root...
Yes. Why is it so different with SSH? It can't be simply
encryption/sniffing, as your password is sent in plain text over telnet
whether you login directly or su later on??

> with some people "forcing" the same passwd for a user account and root
> kinda defeats the purpose....
Yes it defeats the purpose. It doesn't mean it wasn't a good idea in the
first place, and it doesn't mean, as people trying to increase security,
that we shouldn't encourage others do do the job properly.

> Aparently you have a problem determining who and when your logins happen.
When I say accountability I mean that not only do you have a record of where
the connection came from, you also have an account name attached to this
that was su'd from. Whether the account is hacked, or one of your
non-privileged users is actually having a go, you have more information to
go on.

> I get a message for every attempt... every login, and that's followed by
> a "disconnected" message....
Sounds good, but this is you personally. Does your advice still
hold to the rest of us in this group without these scripts? Or could you let
us all know where we might get hold of something like them?

> > If you don't have [local access to hacked box], then you have a problem,
> > whatever happens.
> wrong... there is more then one way to access your box without being
> there...
I guess you mean SUID CGI scripts to do quick-fixes to re-enable access or
something like that. Can you provide more information so we can do this kind
of thing too? Of course, if we do set up these other ways in, why would we
want to enable root SSH access as well? How many doors into the system do
you need?

> in fact...  I have root access with my "cell phone"....
I just hope that nobody finds this "hole" of yours and exploits it too. As
they say "security through obscurity is no security at all" blah etc :o)

> It's all
> in what you want to do with your server....  and how you admin it....
Yes, I agree. Finally!
But for us mere mortals with cobalt boxes unadorned with script that talk to
our phone and so on, isn't the best thing for the group to follow the advice
of very many books and guides[1], and disable root SSH login. Yes, as well
as the inconvenience, there are security disadvantages like your "deleting
su" point. I just don't want people to go off with the impression that
that's an overriding reason for allowing what is, in general, considered
more of a risk than a benefit. Now stop arguing :o)

Cheers
Stephen

[1] Such as http://www.uga.edu/ucns/wsg/security/linuxdetails.html