dedicated host patches - GoFuckYourself.com

bigdog · 08-22-2003, 02:13 PM

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

GrimShawn · 08-22-2003, 02:15 PM

depends how good the tech support is

loverboy · 08-22-2003, 02:16 PM

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

liquidmoe · 08-22-2003, 02:25 PM

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.

dantheman · 08-22-2003, 02:26 PM

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

bigdog · 08-22-2003, 02:37 PM

do patches usally require a reboot of a linux server?

PbG · 08-22-2003, 03:30 PM

They should I know we do.

Quote:

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

Jeffery · 08-22-2003, 04:58 PM

Quote:

Originally posted by bigdog
do patches usally require a reboot of a linux server?

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

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

Dreamman010 · 08-22-2003, 06:30 PM

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 $)

Phil21 · 08-22-2003, 07:13 PM

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

bigdog · 08-22-2003, 07:21 PM

Quote:

Originally posted by Phil21
We do...

Actually any critical stuff that you use are 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 instally 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-diligance, we would break things, which is arguable 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

Dragon Curve · 08-22-2003, 07:25 PM

Quote:

Originally posted by Phil21
We do...

Actually any critical stuff that you use are 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 instally 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-diligance, we would break things, which is arguable 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

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.

Dragon Curve · 08-22-2003, 07:28 PM

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.

Phil21 · 08-22-2003, 07:36 PM

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

Dragon Curve · 08-22-2003, 07:50 PM

Quote:

Originally posted by Phil21
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.

Phil21 · 08-22-2003, 08:13 PM

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

08-22-2003, 02:26 PM	#5
dantheman OG Industry Role: Join Date: May 2002 Posts: 3,308	of course we do, it's part of the managed part __________________ M3server.com VPS>Get your 2nd month free Ded>$100 off your 2nd month since 1996 icq-25135623 dannyh at~m3server DOT com

08-22-2003, 06:30 PM	#9
Dreamman010 Confirmed User Join Date: Jan 2002 Location: Toronto, ON, Canada Posts: 1,081	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 $) __________________ <a href="http://www2.famoushost.com/home.php" target="_blank"><b><FONT COLOR="FFFF00">www.FamousHost.com</font></b></a><br>Free Hosting With No Headers, Real FTP, <u>Get listed on the biggest TGP's with us!</u>

08-22-2003, 07:13 PM	#10
Phil21 Confirmed User Join Date: May 2001 Location: ICQ: 25285313 Posts: 993	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 __________________ Quality affordable hosting. Last edited by Phil21; 08-22-2003 at 07:26 PM..

08-22-2003, 07:36 PM	#14
Phil21 Confirmed User Join Date: May 2001 Location: ICQ: 25285313 Posts: 993	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 __________________ Quality affordable hosting.

08-22-2003, 08:13 PM	#16
Phil21 Confirmed User Join Date: May 2001 Location: ICQ: 25285313 Posts: 993	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 __________________ Quality affordable hosting.

08-22-2003, 02:13 PM	#1
bigdog Confirmed User Join Date: Jul 2001 Posts: 6,964	dedicated host patches do most managed dedicated host patch up their servers automatically when a exploit is found?

08-22-2003, 02:15 PM	#2
GrimShawn Confirmed User Join Date: Oct 2002 Location: BONEPRONE MANSION serving drinks! Posts: 8,120	depends how good the tech support is

08-22-2003, 02:16 PM	#3
loverboy When it rains, it pours Industry Role: Join Date: May 2003 Posts: 20,609	do most hosting companies charge add't for any patch?

08-22-2003, 02:25 PM	#4
liquidmoe Confirmed User Join Date: Mar 2002 Location: NY Posts: 4,994	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.

08-22-2003, 02:37 PM	#6
bigdog Confirmed User Join Date: Jul 2001 Posts: 6,964	do patches usally require a reboot of a linux server?

08-22-2003, 07:28 PM	#13
Dragon Curve Confirmed User Join Date: Oct 2002 Posts: 252	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.