On Wed, 3 Jul 2002, Christian Henn wrote:
> > Is this the right version against the new apache worm ?
> > Is this a special SuSE patched version ?
> Whenever a service/programm/whatever gets exploited, you can _not_ wait
> for your distribution to fix it, but have to build your own Package
> (rpm, deb, depot, pkg, whatever) or just tar xvf ....; ./configure; make
> ... .
I'd be careful here. Integrating your own software and having it actually
work properly, as well as not causing large management headaches down the
road is not quite that simple to do. By the time you get a correctly
built and integrated package, your distributor has probably already
released their own tested, integrated package -- made by someone who
probably knows the system better than you do (or at least better than I 8^)
>
> If you're still running SuSE 7 you should consider upgrading the whole
> operating system, as there was a number of problems with libraries (zlib
> buffer oflow) as well as the OpenSSH-blues (hexor, x2) everyone is
> fighting with. As far as I know, the current distribution is SuSE 8.
SuSE has a good track record of releasing updates for all supported
platforms going back several revisions, simultaneously. I don't think
that there are any updates that are in 8.x that don't have official
packages for 7.x released at the same time. Upgrading your whole OS for
dubious reasons is a great way to break everything for little actual
benefit. If you have something that works well, consider upgrading only
when the vendor stops supporting it with updates, etc. unless you plan to
build your own update packages.
Heck, I've still seen RH 4.2 machines until this last year or so. They
work, you build our own updates, all is good.
>
> But whatever, if running public services you have to be fix in terms of
> upgrading or you might get serious problems because of the masses of
> script kiddies...
Public services that are exploitable have the highest priority for fixing
(and you are turning off all services that you don't actually need for
business reasons, correct?). Most distributors are good about updating
them quickly, but in many cases you can mitigate the potention for trouble
by reconfiguring or restricting the service. For example you can pretty
easily restrict traffic to OpenSSH so that it only responds to machines in
your NOC and sidestep almost all potential for vulnerability. You can
then prepare tested updates without having to integrate them in a panic.
--
Mark Tinberg <[EMAIL PROTECTED]>
Network Security Engineer, SecurePipe Inc.
Remember: Wherever you go, there you are!
Key fingerprint = AF6B 0294 EE33 D802 F7A1 38A4 CF52 5FE0 7470 E5F7
Your daily fortune . . .
If you're not part of the solution, you're part of the precipitate.
