Need urgent help regarding security

[Alex Zbyslaw]

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?

--Alex