Need urgent help regarding security
xfb52 at dial.pipex.com
Sat Nov 19 17:36:22 GMT 2005
Mark Jayson Alvarez wrote:
> Now we have a couple of inputs, we just have to figure out which is the proper combination. Here they are:
> 1. Use private key for ssh logins (should bring the private key always... and if it is stolen.....)
Private keys can (and should) be passphrase protected. Then the key
itself is worthless without the passphrase and it (usually) takes social
engineering to get that. There is plenty of security info out there
about writing security policies and you cannot forget social
engineering. For keys you can't passphrase protect (used for cron jobs
for example) the keys can be limited to perform only specified actions.
There are plenty of manual pages and HowTo's out there.
Don't allow root logins. Limit root users. Enforce good password
practices. Investigate sudo, perhaps.
> 3. Constantly upgrade third party softwares (ssh, ssl, apache, bind) etc.. (too much work.. there are so many of them(postgres, proftp, mysql, php) must be member of various security mailing lists and discussions).
If this is too much work then maybe you are in the wrong business.
Keeping software up-to-date against security patches is priority number
one for any responsible system administrator irrespective of what OS
they run. Reading bugtraq takes me maybe 20 minutes a day, and that's
only because I choose to read messages that are interesting, even if
irrelevant. Portaudit can be run over night and email you output (and
does that out-of-the box on 5.4, probably earlier too). Time to check
email from even a dozen servers is small. If they are all the same,
then you only really *need* to read one message.
Also decide if you really *need* all these services. Proftpd pops up as
one that, in some circumstances, is easily got rid of and replaced with
ssh/sftp -- not always possible, but it's one less
difficult-to-configure package to worry about. Is proftpd actually
buying you anything over regular ftpd?
> 4. Constant Os upgrade(or should we shift to OpenBSD like one of our boss recommended(need to familiarize first, it is a *nix no problem... but it is still OpenBSD :)Also, was it really the 4.8 that has been hacked or the old version of BIND running on it? Anyway, its 6.0 now,
>guess we really have to upgrade now.
5.4 is still supported (as is 4.11 I believe, but I can no longer find
the relevant pages on the revamped website). If 6.0 works, then it's a
good time to choose it.
What OS you run is simply irrelevant if you don't keep up-to-date with
security fixes. If you keep up-to-date with security fixes you can run
a version as long as it is supported. I am not aware that there are any
outstanding security issue in any of 4.11, 5.4 or 6.0. For a production
server, an OS version upgrade should not be taken lightly. No project
can test a new release against every combination of h/w and s/w and most
especially they cannot test it against *your* h/w and s/w. If you
really care about stability then you can pick a server, upgrade just it
and burn it in. Once it proves stable you can upgrade others like it.
You can also plan for OS upgrade at install time. These days, I always
leave minimally sized spare partitions specifically for installing a new
(especially major) version e.g. going from 5.X to 6.X. If you don't
leave that space at install time, you'll never get it once a server is
running without adding a new disk. Minor version upgrades usually go
just fine using simple src upgrade, but for production systems you
should still do one and burn in before committing to doing them all.
But what OS you run (FreeBSD 4/5/6, OpenBSD) is pretty much irrelevant
if you can't be bothered keeping your software up-to-date with respect
to security issues and have your servers and security practices nailed
down to start with. OpenBSD will fall just as fast as FreeBSD if you
leave an insecure sshd running on it, or give a root password away.
Given that your root password was apparently found on the servers, you
likely had much bigger problems than any switch of OS or version would
solve. Was your root password a simple word (i.e. did a password
cracker get it)? Or did you log in with telnet as root so a network
monitor caught it?
> 11. Use ip forwarding so that public servers will never again face the Internet directly( does this require a supers strong machine that will act as firewall? or perhaps an appliance(brand new) can we acquire this right away?
It's not clear to me how you think this would actually help. If all
your machines are internet-facing (and from your ip forwarding comment,
it seems that they are) what good will forcing all the packets through
one machine do? If you have a buggy service on a "hidden" machine, but
you just forward packets to it from your firewall, what difference has
the firewall made? Maybe I misunderstand. If you are trying to hide
mostly internal hosts and forward only a limited number of services
(e.g. just ssh) that's a different matter.
Single firewalls are also single points of failure. And if your
firewall is cracked, you log in to it and then telnet to root on another
server, then an ethernet monitor will have caught your root password.
Without knowing more about the topology and uses of the servers, no-one
can give you a good answer.
>Investigate how the cracker got into the system? Why?
How are you ever going to feel secure about your newly configured
machines until you *know* that the hole used to crack them has been closed?
More information about the freebsd-questions