[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6d456c3604082612013e215e59@mail.gmail.com>
From: tremaine at gmail.com (Tremaine)
Subject: !SPAM! Automated ssh scanning
On Thu, 26 Aug 2004 12:26:04 -0500 (CDT), Ron DuFresne
<dufresne@...ternet.com> wrote:
> On Thu, 26 Aug 2004, Stephen Agar wrote:
>
> > I think many of you are missing the point. Yes the guest/guest account is
> > weak, but this kernel is (according to debian) patched..therefore free from
> > local exploits that can be used to gain superuser access. I mean if this
> > were the case, then any box that ran this version of debian to do something
> > like "web hosting" that gave users shell access, may as well give them all
> > full sudo. Because you people are assuming that if someone can gain access
> > to the box, secured or not, they can gain root..i disagree.
>
>
> The issue here is why does debain include such a weak account,m thaqt has
> not been tamed via a very restricted chroot env!?
That's not the issue though. As someone who has installed and
maintained debian systems over a period of years, I can assure you
that debian does not include a guest account (or any account) with a
weak password or shell.
There aren't any shell accounts other than root on a debian install
until added by the administrator.
The weak account in question here was created by the original poster
with the intent of catching one of these apparently automated ssh
attacks.
> As Barry pointed to directly, it all depends upon what you make available
> to your clients once in a shell. It;s very likely your server would be as
> exploitable as most 'default' installs with the kitchen sink dropped in.
> Perhaps not, but likely, depending upon what you 'installed and allow
> clients access to'.
>
> Thanks,
>
> Ron DuFresne
As for the defaults on the original posters install... that would of
course depend entirely on what install method he chose. Like many
current distros (Mandrake, Redhat etc) Debian offers a packaged
install of a couple varieties (desktop, server, workstation etc) for
an admin to pick from, or they can choose to run dselect (package
management interface) and choose by hand what they do and do not want.
This of course again comes back to not knowing what the initial poster
did with the system beyond running dselect -> update -> install which
would have autohandled updates and dependency resolution for installed
packages.
--
Tremaine
IT Security Consultant
Powered by blists - more mailing lists