OT: RE: Looking for some upgrade advice

[Fairlight]

Only Bill Campbell would say something like:
> I suspect that the vast majority of kernel updates are for features, not
> security issues.  I've seen very few kernel level exploits, most of which I
> think required local access to the machine.  Assuming that your critical
> server is internal and not directly exposed to the Internet, this wouldn't
> worry me.

There have been some kernel upgrades that addressed network stack
vulnerabilities, for instance.  A good percentage are local exploits, as
Bill says--but not all.  And usually after they finish with a kernel line
(say, x.x.18-ish) it starts becoming a case of maybe 9 more releases, one
or two of which might address a security problem, and the rest containing
back-ported features from the next development line--things that can be
brought backwards.  Historically it has run like that.

If your system is entirely firewalled, I wouldn't worry about it.  A little
part of me worries about that wireless situation with no WEP or WPA-SPA in
place, where someone could get use of the WLAN for an attack, but network
stack security flaws have been very, very few and far between in the last
five years.  Let me put it this way:  If you're comfortable running Windows
in that environment, don't worry about the linux server.  :)

> We just retired a Caldera OpenLinux 1.3 machine running on a Pentium 75
> that had been doing our dialup uucp, HylaFAX, and mail services for dozens
> of domains.  It was running a 2.0.35 kernel.  I'm in the process of
> replacing a Caldera OpenLinux 2.3 machine with a 350MhZ PII which was our
> primary incoming mail server, usenet news, etc., etc. machine since 2000 or
> so.  We have several SuSE 9.0 Professional systems in production, and I
> don't see replacing or updating their kernels (the server software is the
> OpenPKG version so that's all current).

I know someone that has an active 1.3.3 system.  It's been holed (mostly
because it -is- directly on the net, Apache is ancient and decrepit, and
they're running seriously flawed CGI on there...someone found a way to
hole it and IRC-bot it...but again, it's on the public net) that is still
in production.  (Solution that was used temporarily, since there's no
sensitive information on it, was to inverse firewall traffic from that box
to any other system on ports >1023, and to all machines but a few on 23 and
22.  The attacks stopped right after that, when it became useless to them.
They put a few other rules in, but I said if you can't update it yet, at
least make it as useless to them as possible.  It's worked surprisingly
well.

I personally ran RH 5.2 with a 2.0.36 kernel for four years or so without
bothering to update much of anything.  I just -used- it, period, the end.
It was totally isolated on a hardwire 10b2 LAN with no net access, so
external security wasn't an issue, as the only people that could get at it
were my wife and myself.  Stability really isn't an issue.  Mostly I -am-
dealing with at least partially exposed systems these days, and I tend to
also patch for local exploits (although if they're low-level threats, they
may wait a week or three so I do all my patching at once if I know more
might be coming from the alerts).  But by and large, security updates have
revolved more around libraries and applications than the kernel in the last
few years anyway.  I can only remember two kernel updates in the last year
that were security related off the top of my mind; one was so minor it was
almost not worth considering, the other was so convoluted an attack to
launch that it was -almost- "theoretical at best".  Some of these fixes are
for things script kiddies wouldn't be doing...you'd almost have to be under
a concerted effort by someone--and you'd REALLY have had to piss them off.

I concur with Bill that it's situational; I'd say if it's an isolated
system, put it in, make sure it's stable and updated to start, and you
can more than probably let the thing go on and on with the exception
of a power outage that exceeds your UPS time and never really lose a
night's sleep thinking about it.  You know the last thing -I- want to do is
start a Windows thread here, but if you trust the 'doze boxen on the same
infrastructure, the linux box is the least of your problems.

mark->