Date: Sat, 19 Nov 2005 17:36:18 +0000 From: Alex Zbyslaw <xfb52@dial.pipex.com> To: Mark Jayson Alvarez <jay2xra@yahoo.com> Cc: questions@freebsd.org Subject: Re: Need urgent help regarding security Message-ID: <437F6292.1070403@dial.pipex.com> In-Reply-To: <20051119053725.88837.qmail@web51606.mail.yahoo.com> References: <20051119053725.88837.qmail@web51606.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?437F6292.1070403>