Uptime vs. Kernel updates (was Re: [TriLUG] Prosperous New Year)
jonc at nc.rr.com
Wed Jan 4 14:48:02 EST 2006
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, 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!
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!
More information about the TriLUG