On Wed, 2006-01-04 at 12:31, Mike Johnson wrote: > Jon Carnes wrote: > > I don't like to apply kernel updates unless it's for a vulnerability > > that makes the machine accessible to an outsider. Over the past couple > > of years I haven't seen one that allows an outsider to hack into my box > > - though there have been a few that allow a local user to gain root. > > Fortunately, I'm the only user on my Linux servers - and I *already* > > have root access... so no biggie. > > > > It's not the greatest systems philosophy - and not one I would apply if > > I were working for someone besides myself. But it works for me. If I'm > > wrong, I'm sure my Trilug buds will give me the slap down that I > > deserve! > > Well, I can't pass up that challenge, now can I? ;) > > The majority of kernel vulnerabilities allow for user privilege > escalation. This means, as stated, one has to already be a user to be > able to exploit the vulnerability. However, this turns could allow an > attacker to gain privileges that would have been otherwise limited. For > instance, exploiting a vulnerability in most network daemons (opensshd, > sendmail, postfix, apache, etc) would grant, at most, the rights of that > user. So, say there's an unpatched vulnerability in apache. Were an > attacker to exploit the vulnerability and gain the ability to execute > arbitrary code, they can only execute said code as the user of the > webserver (nobody, httpd, www-user, etc). Now, if that code were a > kernel exploit, they now have root privileges. > > The steps would look like this: > 1) Exploit vulnerability in apache > 2) Exploit code downloads additional program and invokes it > 3) New program exploits kernel vulnerability and is now running as root > 4) New program binds a bash shell to port 22222 > 5) Attacker points netcat at port 22222 and is greeted with a # prompt > > As an aside, if you don't reboot your system until you absolutely have > to, how do you know that when you -do- reboot it, there will be no > problems? Put another way, rebooting during a maintenance window > ensures that when you have an emergency reboot, the system will return > to a running state. > > Mike
Mike, you wily old goat, Good Points! The other reason I don't like to reboot the mail server or firewall is that each is set to take over for the other should one go down. The mail server has built-in firewalling and will take over the IP of the unresponsive firewall box... and the firewall box will do the same for the mail server (with Postfix on stand-by). I've tested them and it works great, plus they are using a standard set of fail-over scripts that I've been using for years. When I do a systems upgrade next year I will be replacing each of those units with brand new servers. At that time the old ones will be re-assigned to simply be fail-over backup's for their replacements. So I won't be using cross-purpose machines for fail-over/backup, and I'll feel more comfortable in rebooting them for a whim. Till then, uptime is king! Jon BTW: I *do* keep them updated for Apache, Postfix, and any other application that I run on the servers - so for the above scenario to work, they would have to exploit an unknown vulnerability in apache... Still it's better to have multiple layers of security... and I do. MSEC runs in paranoid mode on that box and prevents *any* change to apache - or any other app. I have to drop MSEC to upgrade the apps, then bring MSEC online and have it rescan the box. Man, I love that MSEC! -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
