[cobalt-users] General security suggestions

[Matt Perry <matt@xxxxxxxxxxxxxxx>]

Apologies if this has all be covered before...

On Fri, 9 Mar 2001, Steve wrote:

> I think protecting your server by programs is one thing, but does it improve
> the security of a server if you let it only be root-accessed by SSH from a
> single IP? What do you think of that and has anyone tried that yet?

Everything helps.  Security is a matter of making a trade-off with
convienence.  How restricting SSH logins may help is if a script kiddie
roots your box and installs a root kit, they may not be able to log in if
you've disabled telnet, and then restrict SSH only from certain hosts.
This depends entirely on what root kit they install and how they set up a
backdoor.  If they add a new line to /etc/inetd.conf to let them in with a
root shell such as what was recently posted to this list, then you aren't
going to be helped by the SSH restriction.

Sometimes they might replace services with trojan services such as
replacing inetd with a version of inetd that is fully functional but gives
a root shell if you telnet to a certain port.  This is different from the
above example because this is something that could be compiled into the
executable irregardless of what your inetd.conf might read.  It's probably
more likely to happen on an Intel machine than the older MIPS machines
just because there's less of a chance of them wasting their time compiling
rather than using a binary that's already created for them.

My rule of thumb is to split out services to different machines rather
than try to run everything on one box.  I realize that for some people who
only have one Cobalt as their only computer, this may not be an option.
In particular, I run DNS on it's own box with no other services other than
SSH.  I also scan all of my machines every week with Nessus
(http://www.nessus.org).  This might not be a good idea if you are running
port sentry.

I also keep an Excel spreadsheet that lists all of my machines, the
services that they run, the versions of those services, the last time that
I applied patches, the last time I checked for patches, and the last time
that I performed a scan.  I use this to know when to look for new versions
of software.  I check the Cobalt, Apache, ProFTP, etc web sites about once
or twice a month to look for new versions.  I read the changelogs.  I look
to see if any security issues have been resolved and if so, I will
download and upgrade if Cobalt doesn't have an upgrade package already.

Regarding PortSentry, I just wanted to say that I think it's better to
configure a proper firewall and than run PortSentry.  PortSentry is
reactive whereas a properly configured firewall is proactive.  Having
something like what someone posted to the list recently where by telneting
to post 60000 you could get a root shell, would be prevented by not being
able to connect to post 60000 at all.

I say a properly configured firewall because I want to stress that it's
not easy to properly configure one.  There can be a lot of small gotcha's
that can cause trouble if you are not aware of them.  Worse yet is a
misconfigured firewall that appears to work.  There's nothing worse than a
false sense of security where there really is none.

Last, write up a security policy.  It doesn't have to be a big,
bureaucratic document, just something to tell you what to do if there's a
security incident.  You should know how to record what happened to what
machine, and if you want, anything that your investigation turned up.
Did you find things they modified, etc?  It's an enlighening experience to
view what's left over, and old source code they may have been compiling
and programs they were running.  A spreadsheet like the one I describe
above will help as well.  It's a good idea to document any changes you
make to your machines.  This will help you to document what happened and
rebuild or repair your server rather than just sit there and panic.

Just my $0.02.

 - .\\