RE: [cobalt-users] CGI Script Question

[Steven Werby <steven-lists@xxxxxxxxxxxx>]

On Sun, 13 Aug 2000, Jimmy Gross wrote:

> If that were true the the username admin is a security risk.

Above was in response to Zeffie:
> To me this is a security problem.  If I know the usernames on a unix box    
> then I'm  half way in.  All I need to do is guess the passwd or automate
> it 

Jimmy, Zeffie makes a good point.  Anything you can do to make it more
difficult for potentially malicious users to view and access critical and
sensitive files is probably a good idea.  As is anything you can do to
make it harder for hackers to gain access.

Creating usernames that do not match email address aliases and are
difficult to guess is an excellent idea.  I do so myself.  I never have to
worry about email sent to one user accidentally going to another b/c of a
conflict b/w a username on one site and an alias on another.  Plus, from
the username alone I know exactly what server and what site that user is
part of.  It also reduces the ability of a hacker to gain access by trying
to login using the left-hand side of an email address as a username since
that is never a username on my servers.

Cobalt servers have had known exploits from time to time also so making it
more difficult for a hacker to know you are running Cobalt servers can be
a good idea.  Every single Cobalt server I've telneted into except my own
has informed me that I was logging into a Cobalt server in the pre-login
prompt.  Using a browser to check for the existence of an /admin/,
/siteadmin/ and /personal/ directory will do the same.  As will entering a
URL with a bogus filename.  These are all things that are easily altered
in a few short minutes.  It's called security by obfuscation.

Of course, it's wise to proactively monitor log files for unusual
activity, run security software, run firewalls and do a number of other
things, but a lot of us don't have the time or knowledge to do so.  That's
understandable.  But making poor administrative decisions that can easily
be avoided at minimal effort on your part isn't very rational.

BTW, those of you wondering where you can make some quick changes should
study the following:

/etc/issue
/etc/httpd/conf/srm.conf

--
Steven Werby {steven-lists@xxxxxxxxxxxx}