Re: [cobalt-security] Securing Admin Pages

["Steve Werby" <steve-lists@xxxxxxxxxxxx>]

"duncan gray" <duncanrobertgray@xxxxxxxxx> wrote:
> Ive recently just had one of my websites hacked on my
> server I have know Idea how as I thought my server was
> pretty secure, As I've kept up to date with all the
> latest patches, switched my tellnet over to SSH, and
> so forth

"And so forth" is pretty vague.  It might be useful for you to elaborate.
Every day, new security vulnerabilities are discovered for software that you
may be running on the server.  Do you have a firewall in place with
appropriate rules, something in place for intrusion detection, checking for
weak passwords, checking logs for suspicious activity, etc.?  If not you
probably have a false sense of security.  Security is relative.  And
improving your security requires technology, procedures and design and is
not a one-time thing.

> my bigest guess is that you have to pass the
> root password to the machine while logging in over the
> Web admin pages, this scare me some what.  But raises
> some questions in my mind.

Yes, that's true.  As someone pointed out, you can change the root password
to be different from admin's using passwd from the shell.  And as they
pointed out, that will do little good to prevent anyone who learns the admin
password from gaining access to the GUI and changing the admin password,
which will also change the root password.  There are some steps you can
take.  Setup your GUI to run under SSL.  Edit srm.conf or httpd.conf
(depends on your server) and change the URL directory for the GUI admin
site.  Make edits so it runs on a different port.  Setup an IPCHAINS rule
(if you haven't installed IPCHAINS you should consider doing so) that limits
access to the GUI to your IP.  Of course, it's more complicated if you need
customers to be able to access the site admin and user GUI, but it's not
much more difficult.  The point is you have some options.

> A. is there a way to make the main admin pages work
> off a different user account, If not why not as it
> seems like a huge security hole to me.

That's not possible.  The scripts need to have root user privileges b/c they
modify some files that are owned by root.  That's not to say that Cobalt
couldn't have done it differently, but I don't think customers would have
been happy.  They could have made the GUI run as an unprivileged user and
have it write all of its actions as pending actions to a file or db and then
have a root-owned set of cron jobs check the pending files or db records and
take the appropriate action.  The problem is that this would require a
process that ran pretty frequently in the background and would likely result
in delays between the admin's desired action and when it was put into effect
and would result in higher server load.  And that's just the simple
explanation.

> B. Secondly I dont know much about certificates, but
> Is it possible to issue a client certificate or some
> sort of certificate so you can limit only certain
> browsers/users to access that site? and making sure
> that the link between the server and the client is
> secure?

You can use SSL, then the data sent will be encrypted.  You can use IPCHAINS
or .htaccess to limit access by IP.  There are other tools you can use as
well and other ways to control access depending on your needs.  Keep in mind
that even if you have great technology in place for security, there are
other areas you should address.  For example, I personally wouldn't give any
customers shell access unless you/they have a very good reason and you trust
them, though gut feeling isn't always a good indicator of honesty and
intentions.  You can also disallow user access to the GUI and set passwords
for users yourself and/or force them to be changed on a regular basis.  You
want strong passwords - ones containing a mix of meaningless upper and lower
case letters, numbers and non-alphanumeric characters.  Keep in mind that
even if you take all of the main typical security measures, your server is
still vulnerable.  Fortunately, unless someone has targeted your server
specifically, making your server much more secure than other servers out
there will go a long ways.  But keep in mind that there may be things that
are difficult for you to control.  For example, I've dealt with hosting
companies that don't check ID of a person wanting physical access to "their"
server.  And I've had a number of data centers give me a client's login
info. over the phone without verifying that I'm actually authorized by the
client to login to the box.  Scary, but true.  Security is a constant job.
You need to periodically check your server, read about new vulnerabilities
and be prepared to take the necessary security steps or hire someone who can
do it for you.

--
Steve Werby
President, Befriend Internet Services LLC
http://www.befriend.com/