dedicated host patches
 

do most managed dedicated host patch up their servers automatically when a exploit is found?

depends how good the tech support is

do most hosting companies charge add't for any patch?

Depends what the exploit is, OS level, daemon level, etc, and its severity and the availability of exploitable code. But we do patches for our dedicated clients, free of charge, like all other tech support.

of course we do, it's part of the managed part :thumbsup

do patches usally require a reboot of a linux server?

They should I know we do.

If it is a kernal patch -- yes. But never any other time.

Kernal patches are desperately needed maybe 3-4 times a year.

It all depends on the host and the plan. Managed hosts patch their clients' servers, but charge extra fee for such service.

Unmanaged dedicated service (e.g. Rackshack) don't patch your servers unless you activate their managed service. (exra $)

We do...

Actually any critical stuff that you use our default install on (apache, php, ssh, openssl, etc. etc.) will automatically get patched as soon as there is an upgrade available. This check is performed once every 8 hours or so.

For critical things like the latest apache remote exploit, we of course do pre-emptive testing of customer machines. If someone has an unmanaged box we no longer have access to, we e-mail them and offer to fix it if they like.

It's actually more tricky than it sounds. Many people once getting a ded box decide they don't want the apache install it comes with, or the php install, or whatever, and go compile/install their own. In these cases it's not something we can come around and fix instantly behind the scenes, because we need to consult w/ the customer first to figure out what, if any modifications were made. If we didn't do the due-diligence, we would break things, which is arguably worse than fixing it in the first place.

If we fully manage a box though, it's cake. Usually all machines on our network are patched within hours of an exploit being announced.

-Phil

ok cool thats what i wanted to know

Erm, latest Apache exploit? The only major "exploit" for Apache recently was for <=2.0.45 which was just a DoS and you needed DAV or mod_proxy enabled which isn't by default.

Other than that, the only one previous to that was the chunk-encoding overflow which only really affected BSD (I've never seen a POC on Linux, don't think that was possible).

Re kernel patches, you should upgrade your kernel every time a new kernel is released. Upgrading 3-4 years apart is stupid and insecure.

People have these blind ideas that security is defined by the number of patches you've grabbed lately. While this helps, it cannot in any way guarantee your security. For starters, there are a very reasonable amount of exploits floating around out there that are totally private. Apart from this, any competent hacker will be able to develop his own methods of breaking the box.

Unless you have a competent system administrator and audit all your web applications and the like, hacking by misconfiguration is rather trivial. There is rarely a case where a box not administrated by a certified sysadmin, which is in constant use, is not breakable via misconfiguration.

On a side note, if you run multiple dedicated servers and require more security than just your hosting service reading mailing lists and running rpm -U on your box, you should seriously consider either employing a system administrator, or have your entire services pen tested. Just my two cents.

Upgrading the kernel every time a new release comes around IMO is stupid and unneccessary.

Unless there are documented (even in theory) problems with kernel code, it's nigh on insanely improbable that there is a remote attack available. (If you have local users you don't trust, or give out FTP accounts, etc. - anything that users have system level access to, I would be more paranoid here).

Upgrading like that will over time cause you more problems than it fixes. Our policy is to wait 3-5 weeks after a kernel is released, and note any new bugs that surface that may impact us. We also note any improvements made to the kernel, and upgrade as we see fit there.

That said, we usually are running the latest kernel on most machines 2-3 months after release. We usually schedule kernel upgrades w/ other maintaince windows and systems get rebooted when otherwise unavailable anyways.

And yes, I would fully agree that misconfiguration/inexperience is by far and away the #1 reason systems are penetrable. By default our dedicated machines come with only apache, ftpd, and sshd installed as services, so a customer would have to actively do something to change that. No matter what we do though, we can't protect people from themselves. No matter how many times we explain permissions, or why folks should learn unix security basics before opening that file provided in user input with PHP, people still insist on "knowing better".

-Phil

I strongly disagree with you in this. Kernels are released for a reason, and each major kernel release fixes many problems - although maybe not as severe as remotely exploitable or locally root exploitable, it can greatly increase a hacker's chance of combining it with something else to achieve their goal.

Causing more problems than they fix? The kernels don't change their entire specs with new versions, they syscalls DO in fact stay the same. You just have to know what you're doing when compiling it to ensure you include all the modules etc. that you require - any competent system admin would have no trouble with this what-so-ever - it's one of the most fundamental Linux security tasks.

As for testing a new kernel, if you frequented kernel.org or were current with the way the kernel upgrading works, you would realise that they don't just hit you with a brand new release. They have rc candidates for months before hand that are tested by thousands of people (including RedHat, Debian, all the popular distributions). This has been the case for as long as I can remember which is why you can be confident in installing a stable final release.

It is an extremely rare occurence that the kernel itself will cause more problems than it fixes over the previous kernel, unless human error and/or stupidity with upgrading the kernel comes into effect.

Yeesh,

I am very familiar with the way kernel upgrading "works".

Unfortunately, even with all the testing, bugs still get pushed through. It's a fact, which you know since you obviously read up a lot on kernels. :)

We've actually had problems with some scheduling in certain kernel releases, which were in fact, later on documented bugs. These would have caused outages if put on machines that got heavily hit. Luckily, we don't haphazardly go running off and getting the latest-n-greatest the second we see the post on slashdot. It's called testing.

99 times out of 100 you are correct, upgrading a kernel will cause zero problems, and perhaps fix some you didn't know you had. But when you're pumping thousands of dollars per day through machines, I'm not going to take the chance of fucking that up because of something that may or may not be there.

If you like, I can give you dozens of links to kernel bugs in scheduling, file systems, whatever - that were in final production releases.

Also, security is not the only reasons new kernels are released. New and better hardware support, changes to the scheduler, changes the way VM is handled, whatever are more common than a security problem.

For your own systems, sure go and upgrade the day a kernel is released. You'll be fine. But we actually have people to answer to when that new feature screws with someones specific app. Saying we upgraded them "because it's newer" aint gonna cut it.

To each his own though, I'll let our track record speak for itself.

-Phil