I don't see any mention of this in the CentOS announcements forum. I'd consider dropping the mailing list and switching to forums if this kind of warning appeared there.

https://www.centos.org/modules/newbb/viewforum.php?forum=53

On Thursday 25 Aug 2011, Colin Coles wrote:

There are some work-around suggestions here: http://lwn.net/Articles/456268/

This has now been updated as original work-around was incomplete:

http://lists.grok.org.uk/pipermail/full-disclosure/2011-August/082427.html

--On Thursday, August 25, 2011 9:09 PM +0100 Always Learning centos@u61.u22.net wrote:

The temporary fix is shown on several web sites as this, shown below, added to Apache's conf file:-

I try to minimize changes to main files. Presumably putting that code in a separate file (eg. conf.d/RangeVulnerabilityWorkaround.conf) should work equally well?

On Thu, 25 Aug 2011, Always Learning wrote:

To: CentOS mailing list centos@centos.org From: Always Learning centos@u61.u22.net Subject: Re: [CentOS] Apache warns Web server admins of DoS attack tool

On Thu, 2011-08-25 at 13:31 -0700, Kenneth Porter wrote:

...

--On Thursday, August 25, 2011 9:09 PM +0100 Always Learning centos@u61.u22.net wrote:

...

The temporary fix is shown on several web sites as this, shown below, added to Apache's conf file:-

...

I try to minimize changes to main files. Presumably putting that code in a separate file (eg. conf.d/RangeVulnerabilityWorkaround.conf) should work equally well?

I have a different set-up but I believe your suggestion should work.

I have broken-up the very large conf file (/etc/httpd/conf/httpd.conf) into 3 main parts. Part 1 is left in situ. Parts 2 and 3 are located elsewhere.

#-------------- Section 2: 'Main' server configuration -------------

Include /data/config/apache/server.conf

#--------------- Section 3: Virtual Hosts -------------------------

include /data/config/apache/domain.*

#----------------------------------------------------------------------

I've done something similar with the modules section, as that what appears to change the most between the default httpd.conf files :)

#----------------------------------------------------------- # Dynamic Shared Object (DSO) Support Include conf/dso-modules

# The php install script will look in this file # for 'LoadModule' directives. # # To keep the php installer happy, we load the libphp5.so # module here, in this file.

# LoadModule foo_module modules/mod_foo.so # LoadModule php5_module modules/libphp5.so LoadModule php5_module modules/libphp5.so

#-----------------------------------------------------------

Kind Regards,

Keith Roberts

----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk

All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------

On Thu, 2011-08-25 at 14:36 -0700, John R Pierce wrote:

On 08/25/11 1:45 PM, Always Learning wrote:

...

I have broken-up the very large conf file (/etc/httpd/conf/httpd.conf) into 3 main parts. Part 1 is left in situ. Parts 2 and 3 are located elsewhere.

the existing EL httpd.conf includes /etc/httpd/conf.d/*.conf and any changes are expected to be made there rather than editing the stock file.

Hi John,

No Centos updates are likely to interfere with my Apache server options and virtual hosts. The existing /etc/httpd/conf/httpd.conf is large and laborious to read and fully understand especially with so many useful comments.

'including' the parts that do change and are not operating system dependant, meaning putting them somewhere which has no connection to the operating system, for example

/data/config/apache/server.conf /data/config/apache/domain.*

means, I believe, that if a change to one small file goes wrong then there is absolutely no danger to 'damaging' any of the other files and the source of the problem is quick and easy to identify. Thus 'change damage' is strictly limited to one small self-contained file and can not affect any of the other files.

I have too much experience of so-called collateral damage inadvertently caused to other parts of a file being changed. It costs time and money to trace and diagnose problems, so economically it is a good idea to eliminate as much as possible non-involved configuration parameters.

As you will have noticed Apache actually offers the ability to fragment configuration parameters to other files by supplying - for the benefit of people like me - the 'include' facility. If Apache never wanted folks to use this useful facility, it would never have offered the 'include' ability.

Anyone who has ever worked on the nightmare called Windoze will know that one tiny fault in the Registry can cause the entire operating system to malfunction. Spreading the risk with Apache configuration files is my chosen method to minimise potential disruption and it works very successfully for me on Centos 5.3, 5.4, 5.5, 5.6 and hopefully on 5.7 and 6.1 et al.

However you are entirely free to configure your servers as you wish. That same freedom extends to me too.

Best regards,

Paul.

On 08/25/11 10:48 PM, Emmanuel Noobadmin wrote:

I think you're misunderstanding John there? Rather than suggesting using a single large httpd.conf file, he seems to be just pointing out that the default config already includes any *.conf files inside the conf.d directory so you could just add the additional/sub .conf files in there for consistency.

and modifying a config file thats part of the base RPM can easily cause issues downstream. if nothing else, an httpd update will leave a .rpmnew file there for you to puzzle over and match against your changes. by putting all your site specific configurations in various .conf files in the conf.d directory, your stuff is portable, and can be rpm deployed on any el system without complications.

but AlwaysTalking seems to know better.

On 8/26/2011 7:27 AM, Always Learning wrote:

On Thu, 2011-08-25 at 22:56 -0700, John R Pierce wrote:

...

by putting all your site specific configurations in various .conf files in the conf.d directory, your stuff is portable, and can be rpm deployed on any el system without complications.

That is exactly the flexibility I have when I put my site specific Apache stuff in /data/config/apache

Paul.

I think the point is making use of what is by default built in to apache on our CentOS boxes. And this is and has been for some time making use of the include directed to look in /etc/httpd/conf.d directory and read in any *.conf files in that directory. So, why try to teach somebody to use another structure and customization?

And why is this a good idea? Well, it does add complication in having multiple files to deal with. But the upside to that is it does reduce the number of edits to the main conf file. What is useful about this? Well, I do remember one time editing httpd.conf in Vi and after I finished Apache wouldn't restart. Panic of course immediately sets in when a webserver is not running and I looked and looked and looked and looked and couldn't find any problem with what I had done. Finally, after what seemed like an eternity, I found that I must have accidentally hit the 'x' key just after opening the file and had deleted the first '#' from the first line.

I was working on a new virtual server during that edit and just knew I hadn't edited anywhere else... so had been totally concentrating on the end of the conf file instead of really looking at the top. If this had been in vhost.conf, I could have easily moved vhost.conf to vhost.conf.bak and immediately known that it was not the problem... and actually, wouldn't have had the main conf open to start with so would never have made that mistake.

So, argue all you want, but many programs 'by default' add their apache conf files into /etc/httpd/conf.d so why not follow conventions? If you die, the next admin should know to look there first. And, removing or doing a temp something.conf.bak file quickly takes potential errors out of the equation. To me, the use of this includes directory is simply good practice for multiple reasons. On this list, teaching best 'standard' practices is a good idea. Who is going to think to tell someone to go look in /data/config/apache for a configuration two years from now when something breaks due to following non-standard practices?

John Hinton

On Fri, Aug 26, 2011 at 10:37 AM, Always Learning centos@u61.u22.net wrote:

Apache creates a default set-up. Default for those who need something which 'works out of the box'.

'Apache' is infinitely configurable. It is the upstream/Centos distribution that provides a working base configuration that is also the expected base for a large number of optional packages.

Apache then gives the creative person the facilities to experiment and, as you illustrated, the ability to minimise collateral disruption when something goes wrong when changing files (like the mouse wheel button pasting copied text into unwanted places).

That's kind of irrelevant. The thing that matters in a distribution managed by a package manager is that the base and optional components don't conflict with each other. In many places the distribution handles this by splitting what might be one big file into a directory of included components so each package can manage its own optional components. Apache is one of these. There are a number of web applications available in the base and 3rd party repos that drop snippets of apache config into /etc/httpd.conf.d and if you add your own packages you can do the same without conflict as long as you choose a different filename.

Everything in, for example /data, is entire operating system independent. Simple. The operating system dependant parts of Apache are in the /etc /usr and /var directories, so they can be updated with other operating system revisions. Remember the /etc /usr /var directories are operating system directories, so we keep non-operating system items out of them.

Your are kind of missing the point there. Do you also think /home belongs to the OS and put your own files elsewhere?

If I wanted to move everything to another operating system, for example Solaris or BCD, everything in /data will work on the new operating system without changes ! Just needs a few quick changes to the operating system configuration files. Simple, Easy and Reliable.

That's equivalent to saying you should always install programs from source tarballs with 'configure; make; make install'. You can do that across different platforms, but that's probably much less important to most people than having automatic updates available from packages already well tested on your distribution. Once in a while there is a good reason to do something that isn't pre-packaged, but even then you don't have to do it in a way that is incompatible with existing packages.

On Fri, Aug 26, 2011 at 11:13 AM, Always Learning centos@u61.u22.net wrote:

Les,

There are no /home directories on our servers.

I thought you were trying to give general advice - or that what you posted might be taken that way.

Data we create which is NOT essential for the operating system to function is usually not in an operating system directory.

That's interesting, but not a necessary condition for anything.

'yum update' still works successfully.

But, can you still 'yum install' any/all of the large number of packaged web applications from the base and 3rd party repos that will drop additional files into conf.d and expect a certain base setup?

On Fri, Aug 26, 2011 at 11:30 AM, Always Learning centos@u61.u22.net wrote:

...

But, can you still 'yum install' any/all of the large number of packaged web applications from the base and 3rd party repos  that will drop additional files into conf.d and expect a certain base setup?

Definitely. That is essential. Non-operating system customisations go in /data

But there is nothing related in those two statements. It would be equally true if you put your customizations in differently named files under /etc/httpd/conf.d and in directories under /var/www/html. The difference is that anyone familiar with the standard layout could look at a system and understand it quickly where your non-standard locations would have to be carefully documented and a new admin would need to waste time figuring it out.

Always Learning wrote:

On Fri, 2011-08-26 at 11:46 -0500, Les Mikesell wrote:

...

But there is nothing related in those two statements. It would be equally true if you put your customizations in differently named files under /etc/httpd/conf.d and in directories under /var/www/html. The difference is that anyone familiar with the standard layout could look at a system and understand it quickly where your non-standard locations would have to be carefully documented and a new admin would need to waste time figuring it out.

<snip>

We do not willingly add anything to /etc/httpd/conf.d or to /var/www/html. Our chosen operating system does not require it.

"Does not require"?

I dunno. My current job, and the last two - that goes back to '06 - *all* did minimal changes to /etc/httpd/conf/httpd.conf, and put *everything* else in /etc/httpd/conf.d, including ssl.conf. IIRC, in fact, the package install puts proxy_agp.conf there.

Also, it makes things a *lot* cleaner to have website1.conf, website2.conf, etc in conf.d, rather than in one huge httpd.conf.

mark

On Fri, 2011-08-26 at 12:47 -0400, John Hinton wrote:

OK, so if you do an install of squirrelmail from a repo, is that operating system or customization? Where does squirrelmail.conf wind up?

We do not use Squirrelmail.

Are you running two include lines in httpd.conf? One for /data/apache/custom and one for /etc/httpd/conf.d? Or maybe doing a ln from conf.d to custom?

/etc/httpd/conf/httpd.conf has:-

112: Include conf.d/*.conf

126: User apache 127: Group apache 128: 129: #------------ Section 2: 'Main' server configuration ------------ 130: 131: Include /data/config/apache/server.conf 132: 133: #------------- Section 3: Virtual Hosts --------------------------- 134: 135: include /data/config/apache/domain.* 136: 137: #------------------------------------------------------------------

Paul.

On Fri, 2011-08-26 at 13:37 -0400, m.roth@5-cent.us wrote:

Paul, you've completely missed what John was asking: what qualifies as o/s, and what qualifies as third party, or whatever? Which is apache, or php, or gcc, or tomcat5? Certainly, tomcat and httpd get fired off by root at system boot.

Mark,

I don't know about your systems but on ours

php gcc tomcat5

do NOT require customisation. Apache does. For example:-

ServerAdmin ServerName DirectoryIndex DefaultLanguage LanguagePriority and all the other site options

Keeping the bits that remain static separate from the bits that change per server is our choice.

Putting virtual hosts, including those with sub-domains, in a individual 'domain name' text file ensures for us smooth running. For us deleting a virtual host is deleting one named text file. Adding a virtual host means creating one text file. Changing a virtual host means changing one file. Moving a virtual host to a different server or even to a different operating system means moving one file. Of course it requires a

service httpd restart or reload

Meanwhile nothing else is disrupted, or at risk of disruption or inadvertently altered. We like quickness, simpleness and easiness. Keep it plain and simple is our motive.

Those who like dumping everything in one large text file can. I was speaking to a sys admin this week who has only 1,200 virtual hosts in the main Apache file.

Paul.

On 08/26/11 11:00 AM, Always Learning wrote:

Those who like dumping everything in one large text file can. I was speaking to a sys admin this week who has only 1,200 virtual hosts in the main Apache file.

which part of /etc/httpd/conf.d/*.conf are you missing? Each vhost gets its OWN conf file, ideally packaged with the vhost's application files and depedencies as an RPM, so it can be deployed/undeployed by a single command, or included in a kickstart, or whatever...

there should be NOTHING in the main httpd.conf that needs changing, I haven't had to touch that file in years on any of my EL4/5/6 systems. I put global stuff in a /etc/httpd/conf.d/00globalstuff.conf (the *.conf files are loaded in sort order so a 00something file will get loaded before any others).

On Fri, 2011-08-26 at 14:19 -0400, m.roth@5-cent.us wrote:

If you and the rest of your team go out to lunch, and are killed by food poisoning, or an out-of-control senior citizen, anyone walking in will take a good bit longer to find where all versions of *Nix normally put their configuration files, ain't. And you *are* customizing /etc/httpd/conf/httpd.conf.

We have D-O-C-U-M-E-N-T-A-T-I-O-N which remains behind we we go home, go to lunch and go on holiday.

I stay with std. practice, as much as I can.

I do too but where there are multiple servers using almost the same setup, the changeable bits are 'included' and kept in individual files.

I slept with Frisch's Essential Systems Administration. from O'Reilly.

I'll have a look but I prefer to sleep with someone who is warm and cuddly. Not sure a book is an adequate substitute however interesting the text may be :-)

Oh, and php *certainly* requires configuration.

Can't remember what I changed in /etc if I changed it.

Paul.

Forget it. He won't listen and will continue to further his nonsensical methods of configuration with silly justifications that don't hold up. Please, just let him be "right" so he'll stop needing to get the last word in all the time and perhaps this thread can die.

John

On 8/26/2011 3:02 PM, Always Learning wrote:

...

Oh, and php *certainly* requires configuration.

Can't remember what I changed in /etc if I changed it.

It should be there in your documentation... ;) LOL!!! Me? My documentation is in my head... 'burned' into my brain, from following upstream's suggestions for the last 15 or more years. And yes that 'upstream book' has been revised over those years, but not everything.

John

Always Learning wrote:

On Fri, 2011-08-26 at 15:25 -0400, John Hinton wrote:

...

On 8/26/2011 3:02 PM, Always Learning wrote:

<snip>

I only wish I have come to Linux years ago. It is so refreshingly nice. Everything a real operating system should be and reminiscent of the once great Mainframes.

You don't think they're still great? Check IBM, who's sales of m'frames keep up, and grow. Y'know, 'bout 10 years ago, using their VM (that they've had since the seventies...), one of their engineers found that he could comfortably run 32000 instances of Linux on one big iron, and only maxed it out at over 48000 VMs....

And, of course, IBM really, *really wants folks to use Linux. I mean, if *you* were Big Blue, would you want to support, uh, sys38/4000/RISC6000/AIX/"DOS/VSE/SP/<whatever letters in the last 15 years)>/MVS/zOS... or just Linux? (You've grown your business, and need a bigger machine? Great! Here's the next large box, just throw it on, maybe just recompile, and no porting needed!)

mark

On Fri, 2011-08-26 at 15:38 -0700, John R Pierce wrote:

they still push z/OS (the descendent of OS/370)

Whatever happened to IBM 360 and OS/360 ?

Paul.

Always Learning wrote:

On Fri, 2011-08-26 at 14:19 -0400, m.roth@5-cent.us wrote:

...

If you and the rest of your team go out to lunch, and are killed by food poisoning, or an out-of-control senior citizen, anyone walking in will take a good bit longer to find where all versions of *Nix normally put their configuration files, ain't. And you *are* customizing /etc/httpd

/conf/httpd.conf.

We have D-O-C-U-M-E-N-T-A-T-I-O-N which remains behind we we go home, go to lunch and go on holiday.

Right. And you have a 100% confidence level that it will a) *always* be up to date, b) available, and c) actually readable.... http://24.5-cent.us/http://24.5-cent.us/egoless_documentation.doc We'll ignore the old Dilbert where, was it Dogbert or Dilbert, who stood on a chair, with their head over the top of the cube farm, and yelled out, "HAS ANYONE RTFM?!", and got no answers....

...

I stay with std. practice, as much as I can.

I do too but where there are multiple servers using almost the same setup, the changeable bits are 'included' and kept in individual files.

...

I slept with Frisch's Essential Systems Administration. from O'Reilly.

I'll have a look but I prefer to sleep with someone who is warm and cuddly. Not sure a book is an adequate substitute however interesting the text may be :-)

I did say that was in addition to my ...late... wife.

...

Oh, and php *certainly* requires configuration.

Can't remember what I changed in /etc if I changed it.

Oh, no, it used to be worse - I'd have to edit the sucker down in, where was it, /usr/lib/php, or /usr/local/lib/php?

mark

Always Learning wrote:

On Fri, 2011-08-26 at 16:12 -0400, m.roth@5-cent.us wrote:

...

Right. And you have a 100% confidence level that it will a) *always* be up to date, b) available, and c) actually readable....

I've always been praised for my good documentation.

...

http://24.5-cent.us/http://24.5-cent.us/egoless_documentation.doc

404 Error File Not Found http://24.5-cent.us/egoless_documentation.doc - was that an IQ test ?

Sorry, typing too fast, had to go do actual work. <g> <snip>

...

Oh, no, it used to be worse - I'd have to edit the sucker down in, where was it, /usr/lib/php, or /usr/local/lib/php?

Not there on Centos 5.6 and /usr/local is empty.

php used to get installed in one of those, back in RHEL 3. Of course, where I was, we had to actually *build* the damn thing, since out of the box didn't support encryption.

mark

On Fri, 2011-08-26 at 14:34 -0400, John Hinton wrote:

OK, so you have just chosen to put your vhost confs in an alternate directory. There are sound reasons for doing that, like ease of backups and dumb minded restores that any low level tech could do.

Thank you.

To suggest others follow in your footsteps however is very short sighted.

I have never, not once, suggested others copy my layout.

The two includes in httpd.conf allows both areas to load, but does break 'alternative' installs, such as squirrelmail as just one of many examples (assuming you got rid of the /etc/httpd/conf.d include).

We have no intention of using Squirrel Mail.

So, yum install squirrelmail would not work without customization on your system, along with a number of other system wide tools one might want to run under apache. Python, php, manual, welcome, webalizer, ssl, squid, proxy_ajp, perl, cacti are all examples.

We have no problems running Apache with MySQL, PHP, SSL ...

.... to suggest an alternative area is just off the topic and potentially confusing to those that are trying to follow a step by step procedure down to the letter.

I have never, not once, suggested others copy my layout.

I do recognize the merits of what you are doing.

Thank you.

Paul.

On Aug 26, 2011, at 8:37 AM, Always Learning wrote:

On Fri, 2011-08-26 at 10:59 -0400, John Hinton wrote:

...

.... To me, the use of this includes directory is simply good practice for multiple reasons. On this list, teaching best 'standard' practices is a good idea. Who is going to think to tell someone to go look in /data/config/apache for a configuration two years from now when something breaks due to following non-standard practices?

Unlike some other installations everything is documented, so everyone knows. Keeping information a secret from other workers is not practised here.

Apache creates a default set-up. Default for those who need something which 'works out of the box'. Apache then gives the creative person the facilities to experiment and, as you illustrated, the ability to minimise collateral disruption when something goes wrong when changing files (like the mouse wheel button pasting copied text into unwanted places).

Everything in, for example /data, is entire operating system independent. Simple. The operating system dependant parts of Apache are in the /etc /usr and /var directories, so they can be updated with other operating system revisions. Remember the /etc /usr /var directories are operating system directories, so we keep non-operating system items out of them.

If I wanted to move everything to another operating system, for example Solaris or BCD, everything in /data will work on the new operating system without changes ! Just needs a few quick changes to the operating system configuration files. Simple, Easy and Reliable.

An English saying is: "Rules were made for the guidance of wise men but for the obedience of fools". Naturally I am not implying, nor would I, that anyone on this list are in the latter category. However I believe that saying makes a valid point.

Once upon a time people were killed for believing the world was not flat and if one sailed far enough their ship would drop-off the edge of the world. Blind and unthinking obedience and the intellectual inability to question and experiment are not conducive to the successful development and using of computers.

Please note I do not teach on here. I've already got a large workload :-)

Best regards,

---- oy - no wonder you turn off selinux - you are determined to re-engineer things that were designed with logic and intent.

Perhaps you should use some other non-redhat type of distribution (debian/ubuntu) to get a feel for the fact that there actually is intelligent ways to plan out configuration files and gasp, in /etc/

Craig

--On Thursday, August 25, 2011 9:09 PM +0100 Always Learning centos@u61.u22.net wrote:

...

The temporary fix is shown on several web sites as this, shown below, added to Apache's conf file:-

I try to minimize changes to main files. Presumably putting that code in a separate file (eg. conf.d/RangeVulnerabilityWorkaround.conf) should work equally well?

Hi,

Attached is what I've put into /etc/httpd/conf.d/CVE-2011-3192.conf and I'll just remove it after the coming update is done. At least killapache.pl doesn't kill anymore.

Works for me, YMMW.

Simon

...

...

--On Thursday, August 25, 2011 9:09 PM +0100 Always Learning centos@u61.u22.net wrote:

...

The temporary fix is shown on several web sites as this, shown below, added to Apache's conf file:-

I try to minimize changes to main files. Presumably putting that code in a separate file (eg. conf.d/RangeVulnerabilityWorkaround.conf) should work equally well?

Hi,

Attached is what I've put into /etc/httpd/conf.d/CVE-2011-3192.conf and I'll just remove it after the coming update is done. At least killapache.pl doesn't kill anymore.

Works for me, YMMW.

Sorry, forgot to mention that this is for EL4.

And while looking into it again I realize that my "solution" is not really a solution...

Simon