Discussion:
Apache Bandwidth Utilization / Reporting
(too old to reply)
Steve Leach
2002-11-25 09:57:18 UTC
Permalink
Group,

Is there a module for Apache 1.x or 2.x (new server so I have the option to
choose!!!), that will allow me to see what the cumulative bandwidth usage is
for (a) individual Virtual Hosts and (b) the Apache Server as a whole? I
would like to be able to produce adaily report that includes this
information in a formal bandwidth costing exercise.

If there is no feature (or module) for Apache, is there a product thatanyone
can recommend that will provide such functionality.

Thanks in advance.


Best Regards,


Steve Leach
IT / Network Manager
MI International Ltd



---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Dirk-Willem van Gulik
2002-11-25 10:04:24 UTC
Permalink
Try: modules.apache.org - it lists a few. A good option is the SNMP module
which allows you to get that information on a timely basis externally.

Dw.
Post by Steve Leach
Group,
Is there a module for Apache 1.x or 2.x (new server so I have the option to
choose!!!), that will allow me to see what the cumulative bandwidth usage is
for (a) individual Virtual Hosts and (b) the Apache Server as a whole? I
would like to be able to produce adaily report that includes this
information in a formal bandwidth costing exercise.
If there is no feature (or module) for Apache, is there a product thatanyone
can recommend that will provide such functionality.
Thanks in advance.
Best Regards,
Steve Leach
IT / Network Manager
MI International Ltd
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Sander Holthaus - Orange XL
2002-11-25 14:57:12 UTC
Permalink
Personally, I think such a feature should be implemented in Apache for a
very basic protection against (D)DoS-attacks. So you can set things like
MaxBandwith (per day/hour) or MaxPeakBandwith on a per server and
per-virtual-host basis.

Imagine what could happen if you are away for a few hours and someone
decides to fill up your connection with HTTP-requests. Such attacks are
becoming more frequent, and put a severe strain on not only the websever
itself, but also servers and networkcomponents around it. Not to mention
economic damages...

Anyone any thoughts on this?

Kind Regards,
Sander Holthaus

----- Original Message -----
From: "Steve Leach" <***@mi-int.com>
To: <***@httpd.apache.org>
Sent: Monday, November 25, 2002 10:57 AM
Post by Steve Leach
Group,
Is there a module for Apache 1.x or 2.x (new server so I have the option to
choose!!!), that will allow me to see what the cumulative bandwidth usage is
for (a) individual Virtual Hosts and (b) the Apache Server as a whole? I
would like to be able to produce adaily report that includes this
information in a formal bandwidth costing exercise.
If there is no feature (or module) for Apache, is there a product thatanyone
can recommend that will provide such functionality.
Thanks in advance.
Best Regards,
Steve Leach
IT / Network Manager
MI International Ltd
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Porter, Mark
2002-11-25 14:48:19 UTC
Permalink
Aren't you describing mod_throttle? I personally have never used it, but
in the cursory glance I gave the module description, it sounds like it
may be what you're looking for.



-----Original Message-----
From: Sander Holthaus - Orange XL [mailto:***@orangexl.com]
Sent: Monday, November 25, 2002 9:57 AM
To: ***@httpd.apache.org
Subject: Re: [***@httpd] Apache Bandwidth Utilization / Reporting


Personally, I think such a feature should be implemented in Apache for a
very basic protection against (D)DoS-attacks. So you can set things like
MaxBandwith (per day/hour) or MaxPeakBandwith on a per server and
per-virtual-host basis.

Imagine what could happen if you are away for a few hours and someone
decides to fill up your connection with HTTP-requests. Such attacks are
becoming more frequent, and put a severe strain on not only the websever
itself, but also servers and networkcomponents around it. Not to mention
economic damages...

Anyone any thoughts on this?

Kind Regards,
Sander Holthaus

----- Original Message -----
From: "Steve Leach" <***@mi-int.com>
To: <***@httpd.apache.org>
Sent: Monday, November 25, 2002 10:57 AM
Post by Steve Leach
Group,
Is there a module for Apache 1.x or 2.x (new server so I have the
option
to
Post by Steve Leach
choose!!!), that will allow me to see what the cumulative bandwidth
usage
is
Post by Steve Leach
for (a) individual Virtual Hosts and (b) the Apache Server as a whole?
I
Post by Steve Leach
would like to be able to produce adaily report that includes this
information in a formal bandwidth costing exercise.
If there is no feature (or module) for Apache, is there a product
thatanyone
Post by Steve Leach
can recommend that will provide such functionality.
Thanks in advance.
Best Regards,
Steve Leach
IT / Network Manager
MI International Ltd
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
Post by Steve Leach
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Steve Leach
2002-11-25 14:55:49 UTC
Permalink
Perhaps that is what is needed for bandwidth checks - my own requirement is
just for the reporting side (for now at least).
I'm looking at the modules and trying to see which can actually do
reporting, and which are functionally implementing limits on the bandwidth.
Is anyone else doing this type of thing now?


Best Regards,


Steve Leach
IT/Network Manager
MI International Ltd

----- Original Message -----
From: "Porter, Mark" <***@LibertyMutual.com>
To: <***@httpd.apache.org>
Sent: Monday, November 25, 2002 2:48 PM
Post by Porter, Mark
Aren't you describing mod_throttle? I personally have never used it, but
in the cursory glance I gave the module description, it sounds like it
may be what you're looking for.
-----Original Message-----
Sent: Monday, November 25, 2002 9:57 AM
Personally, I think such a feature should be implemented in Apache for a
very basic protection against (D)DoS-attacks. So you can set things like
MaxBandwith (per day/hour) or MaxPeakBandwith on a per server and
per-virtual-host basis.
Imagine what could happen if you are away for a few hours and someone
decides to fill up your connection with HTTP-requests. Such attacks are
becoming more frequent, and put a severe strain on not only the websever
itself, but also servers and networkcomponents around it. Not to mention
economic damages...
Anyone any thoughts on this?
Kind Regards,
Sander Holthaus
----- Original Message -----
Sent: Monday, November 25, 2002 10:57 AM
Post by Steve Leach
Group,
Is there a module for Apache 1.x or 2.x (new server so I have the
option
to
Post by Steve Leach
choose!!!), that will allow me to see what the cumulative bandwidth
usage
is
Post by Steve Leach
for (a) individual Virtual Hosts and (b) the Apache Server as a whole?
I
Post by Steve Leach
would like to be able to produce adaily report that includes this
information in a formal bandwidth costing exercise.
If there is no feature (or module) for Apache, is there a product
thatanyone
Post by Steve Leach
can recommend that will provide such functionality.
Thanks in advance.
Best Regards,
Steve Leach
IT / Network Manager
MI International Ltd
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
Post by Steve Leach
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
J. Greenlees
2002-11-25 23:35:38 UTC
Permalink
Steve,
from a friend that did this exact thing,
full steps for duplicating ( we have no idea when the hard drives ect
will be returned, a warezer put pirated movie on his server, cost him
the servers he was using for data transfer study )

"It's not too tough... if I ever get my #@$! hard drives and tape/CD
backups returned to me from UEN, I could just post you a copy of the
scripts.

Until then, you have to do a couple of things...

For data transfer:

Rig up awk to parse your httpd logs for anything ending in .zip, .exe,
.sit, and .ogg, and whatever else you have set out for download. Then
pipe that into something (awk or grep, machts nichts) that will suss out
the filesize (you can either try and snag it out of the httpd call line,
or out of an ls-generated table that will match the filename to the
filesize) . Then, pipe those numbers into a flat temporary text file,
and at the end of the day, let cron total the things all together, then
do some housekeeping by running /dev/null against the temp number file,
and backing up the daily httpd log (I used `date -I` to latch a
timestamp onto the filename), then running /dev/zero against the main
log file. You can then take that daily log file and run another script
against it, like I did, to count how many download requests you did have
(grep|count), count unique hits altogether (grep|diff|count), then echo
the error lines for your clients to look at when they get lost on something.

HTH a little... "

hope that helps.
btw, the person quoted teaches networking / server admin at university.
I asked him your question, this was his reply. his preffered os is red
hat linux.

Jaqui
Post by Steve Leach
Perhaps that is what is needed for bandwidth checks - my own requirement is
just for the reporting side (for now at least).
I'm looking at the modules and trying to see which can actually do
reporting, and which are functionally implementing limits on the bandwidth.
Is anyone else doing this type of thing now?
Best Regards,
Steve Leach
IT/Network Manager
MI International Ltd
----- Original Message -----
Sent: Monday, November 25, 2002 2:48 PM
Post by Porter, Mark
Aren't you describing mod_throttle? I personally have never used it, but
in the cursory glance I gave the module description, it sounds like it
may be what you're looking for.
-----Original Message-----
Sent: Monday, November 25, 2002 9:57 AM
Personally, I think such a feature should be implemented in Apache for a
very basic protection against (D)DoS-attacks. So you can set things like
MaxBandwith (per day/hour) or MaxPeakBandwith on a per server and
per-virtual-host basis.
Imagine what could happen if you are away for a few hours and someone
decides to fill up your connection with HTTP-requests. Such attacks are
becoming more frequent, and put a severe strain on not only the websever
itself, but also servers and networkcomponents around it. Not to mention
economic damages...
Anyone any thoughts on this?
Kind Regards,
Sander Holthaus
----- Original Message -----
Sent: Monday, November 25, 2002 10:57 AM
Post by Steve Leach
Group,
Is there a module for Apache 1.x or 2.x (new server so I have the
option
to
Post by Steve Leach
choose!!!), that will allow me to see what the cumulative bandwidth
usage
is
Post by Steve Leach
for (a) individual Virtual Hosts and (b) the Apache Server as a whole?
I
Post by Steve Leach
would like to be able to produce adaily report that includes this
information in a formal bandwidth costing exercise.
If there is no feature (or module) for Apache, is there a product
thatanyone
Post by Steve Leach
can recommend that will provide such functionality.
Thanks in advance.
Best Regards,
Steve Leach
IT / Network Manager
MI International Ltd
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Jacob Coby
2002-11-26 00:04:56 UTC
Permalink
Post by J. Greenlees
btw, the person quoted teaches networking / server admin at university.
I asked him your question, this was his reply. his preffered os is red
hat linux.
That's a little scary! He teaches server admin, but didn't know about the
warez on his server? Yay anon FTP! ;-)

Unless someone else finds one soon, I think I'm going to write an Apache
module to do this. I've wanted the functionality for a while, and have been
looking for a project to write in C/C++. It would operate similar to
mod_status where you can look at (host)/server-bandwidth and see (all units
are bytes, not bits):

- current bandwidth usage in kb/sec
- peak bandwidth in kb/sec and when it was hit
- min bandwidth in kb/sec and when it was hit
- average bandwidth in kb/sec
- total transferred bytes/kb/mb/gb/tb (depending on how much was moved)
- there would also be a machine-parsable output in csv format, similar to
mod_status
and possibly:
- current/min/max connection counts
- something else? thoughts?

-Jacob


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Sander Holthaus - Orange XL
2002-11-25 15:27:32 UTC
Permalink
Perhaps, I tried to check that, but that page gives me a 500. But I think
such a feature should be availeble in Apache as an extension and not as a
third party module.

----- Original Message -----
From: "Porter, Mark" <***@LibertyMutual.com>
To: <***@httpd.apache.org>
Sent: Monday, November 25, 2002 3:48 PM
Subject: RE: [***@httpd] Apache Bandwidth Utilization / Reporting


Aren't you describing mod_throttle? I personally have never used it, but
in the cursory glance I gave the module description, it sounds like it
may be what you're looking for.



-----Original Message-----
From: Sander Holthaus - Orange XL [mailto:***@orangexl.com]
Sent: Monday, November 25, 2002 9:57 AM
To: ***@httpd.apache.org
Subject: Re: [***@httpd] Apache Bandwidth Utilization / Reporting


Personally, I think such a feature should be implemented in Apache for a
very basic protection against (D)DoS-attacks. So you can set things like
MaxBandwith (per day/hour) or MaxPeakBandwith on a per server and
per-virtual-host basis.

Imagine what could happen if you are away for a few hours and someone
decides to fill up your connection with HTTP-requests. Such attacks are
becoming more frequent, and put a severe strain on not only the websever
itself, but also servers and networkcomponents around it. Not to mention
economic damages...

Anyone any thoughts on this?

Kind Regards,
Sander Holthaus

----- Original Message -----
From: "Steve Leach" <***@mi-int.com>
To: <***@httpd.apache.org>
Sent: Monday, November 25, 2002 10:57 AM
Post by Steve Leach
Group,
Is there a module for Apache 1.x or 2.x (new server so I have the
option
to
Post by Steve Leach
choose!!!), that will allow me to see what the cumulative bandwidth
usage
is
Post by Steve Leach
for (a) individual Virtual Hosts and (b) the Apache Server as a whole?
I
Post by Steve Leach
would like to be able to produce adaily report that includes this
information in a formal bandwidth costing exercise.
If there is no feature (or module) for Apache, is there a product
thatanyone
Post by Steve Leach
can recommend that will provide such functionality.
Thanks in advance.
Best Regards,
Steve Leach
IT / Network Manager
MI International Ltd
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org



---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
zeno
2002-11-25 14:45:36 UTC
Permalink
Post by Sander Holthaus - Orange XL
Personally, I think such a feature should be implemented in Apache for a
very basic protection against (D)DoS-attacks. So you can set things like
MaxBandwith (per day/hour) or MaxPeakBandwith on a per server and
per-virtual-host basis.
A problem with this is that people who use bandwith limits a day are being ddosed even more easily.
Some free hosters have bandwith limits and some people are simply writing a perl script to download the index page
100k times in a day and shutting them down for the rest of the month (example bugtraq.org).

- zeno
Post by Sander Holthaus - Orange XL
Imagine what could happen if you are away for a few hours and someone
decides to fill up your connection with HTTP-requests. Such attacks are
becoming more frequent, and put a severe strain on not only the websever
itself, but also servers and networkcomponents around it. Not to mention
economic damages...
Anyone any thoughts on this?
Kind Regards,
Sander Holthaus
----- Original Message -----
Sent: Monday, November 25, 2002 10:57 AM
Post by Steve Leach
Group,
Is there a module for Apache 1.x or 2.x (new server so I have the option
to
Post by Steve Leach
choose!!!), that will allow me to see what the cumulative bandwidth usage
is
Post by Steve Leach
for (a) individual Virtual Hosts and (b) the Apache Server as a whole? I
would like to be able to produce adaily report that includes this
information in a formal bandwidth costing exercise.
If there is no feature (or module) for Apache, is there a product
thatanyone
Post by Steve Leach
can recommend that will provide such functionality.
Thanks in advance.
Best Regards,
Steve Leach
IT / Network Manager
MI International Ltd
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Boyle Owen
2002-11-25 15:20:00 UTC
Permalink
Well, it's Open source - why don't you write it?
Post by Porter, Mark
-----Original Message-----
Sent: Montag, 25. November 2002 16:28
Perhaps, I tried to check that, but that page gives me a 500.
But I think
such a feature should be availeble in Apache as an extension
and not as a
third party module.
----- Original Message -----
Sent: Monday, November 25, 2002 3:48 PM
Aren't you describing mod_throttle? I personally have never
used it, but
in the cursory glance I gave the module description, it sounds like it
may be what you're looking for.
-----Original Message-----
Sent: Monday, November 25, 2002 9:57 AM
Personally, I think such a feature should be implemented in
Apache for a
very basic protection against (D)DoS-attacks. So you can set
things like
MaxBandwith (per day/hour) or MaxPeakBandwith on a per server and
per-virtual-host basis.
Imagine what could happen if you are away for a few hours and someone
decides to fill up your connection with HTTP-requests. Such attacks are
becoming more frequent, and put a severe strain on not only
the websever
itself, but also servers and networkcomponents around it. Not
to mention
economic damages...
Anyone any thoughts on this?
Kind Regards,
Sander Holthaus
----- Original Message -----
Sent: Monday, November 25, 2002 10:57 AM
Post by Steve Leach
Group,
Is there a module for Apache 1.x or 2.x (new server so I have the
option
to
Post by Steve Leach
choose!!!), that will allow me to see what the cumulative bandwidth
usage
is
Post by Steve Leach
for (a) individual Virtual Hosts and (b) the Apache Server
as a whole?
I
Post by Steve Leach
would like to be able to produce adaily report that includes this
information in a formal bandwidth costing exercise.
If there is no feature (or module) for Apache, is there a product
thatanyone
Post by Steve Leach
can recommend that will provide such functionality.
Thanks in advance.
Best Regards,
Steve Leach
IT / Network Manager
MI International Ltd
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
Post by Steve Leach
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP
Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP
Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Sander Holthaus - Orange XL
2002-11-25 15:46:05 UTC
Permalink
I wish I could, but I am already having a hard time with perl. I hope to
learn C one day, but I think that will be around the release of Apache 3.x
:-)


----- Original Message -----
From: "Boyle Owen" <***@swx.com>
To: <***@httpd.apache.org>
Sent: Monday, November 25, 2002 4:20 PM
Post by Boyle Owen
Well, it's Open source - why don't you write it?
Post by Porter, Mark
-----Original Message-----
Sent: Montag, 25. November 2002 16:28
Perhaps, I tried to check that, but that page gives me a 500.
But I think
such a feature should be availeble in Apache as an extension
and not as a
third party module.
----- Original Message -----
Sent: Monday, November 25, 2002 3:48 PM
Aren't you describing mod_throttle? I personally have never
used it, but
in the cursory glance I gave the module description, it sounds like it
may be what you're looking for.
-----Original Message-----
Sent: Monday, November 25, 2002 9:57 AM
Personally, I think such a feature should be implemented in
Apache for a
very basic protection against (D)DoS-attacks. So you can set
things like
MaxBandwith (per day/hour) or MaxPeakBandwith on a per server and
per-virtual-host basis.
Imagine what could happen if you are away for a few hours and someone
decides to fill up your connection with HTTP-requests. Such attacks are
becoming more frequent, and put a severe strain on not only
the websever
itself, but also servers and networkcomponents around it. Not
to mention
economic damages...
Anyone any thoughts on this?
Kind Regards,
Sander Holthaus
----- Original Message -----
Sent: Monday, November 25, 2002 10:57 AM
Post by Steve Leach
Group,
Is there a module for Apache 1.x or 2.x (new server so I have the
option
to
Post by Steve Leach
choose!!!), that will allow me to see what the cumulative bandwidth
usage
is
Post by Steve Leach
for (a) individual Virtual Hosts and (b) the Apache Server
as a whole?
I
Post by Steve Leach
would like to be able to produce adaily report that includes this
information in a formal bandwidth costing exercise.
If there is no feature (or module) for Apache, is there a product
thatanyone
Post by Steve Leach
can recommend that will provide such functionality.
Thanks in advance.
Best Regards,
Steve Leach
IT / Network Manager
MI International Ltd
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
Post by Steve Leach
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP
Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP
Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
J. Greenlees
2002-11-25 15:42:47 UTC
Permalink
I'm hosting around 50 files for free downloads for the 3d graphics
community, the largest right now being around 3 megs, ( all one client )
this one person's account would hit a peak bandwidth throttle around 12
times a day, a daily limit in around 3 hours.
( I'm glad I have high transfer allotmment with isp )
I'm literally working at getting myself set up with / as a backbone for
the internet to be able to have the capacity required by this one
community ( average for personal site in data transfer is 50 gigabytes a
month )
a university networking prof I know hosted 18 people's free downloads,
his use of the university data transfer capacity was 16 gigabytes a day.
I'll ask him what he used to measure the rates. ( when I get back from
seminar on Java in six hours )
Post by Sander Holthaus - Orange XL
I wish I could, but I am already having a hard time with perl. I hope to
learn C one day, but I think that will be around the release of Apache 3.x
:-)
----- Original Message -----
Sent: Monday, November 25, 2002 4:20 PM
Post by Boyle Owen
Well, it's Open source - why don't you write it?
Post by Porter, Mark
-----Original Message-----
Sent: Montag, 25. November 2002 16:28
Perhaps, I tried to check that, but that page gives me a 500.
But I think
such a feature should be availeble in Apache as an extension
and not as a
third party module.
----- Original Message -----
Sent: Monday, November 25, 2002 3:48 PM
Aren't you describing mod_throttle? I personally have never
used it, but
in the cursory glance I gave the module description, it sounds like it
may be what you're looking for.
-----Original Message-----
Sent: Monday, November 25, 2002 9:57 AM
Personally, I think such a feature should be implemented in
Apache for a
very basic protection against (D)DoS-attacks. So you can set
things like
MaxBandwith (per day/hour) or MaxPeakBandwith on a per server and
per-virtual-host basis.
Imagine what could happen if you are away for a few hours and someone
decides to fill up your connection with HTTP-requests. Such attacks are
becoming more frequent, and put a severe strain on not only
the websever
itself, but also servers and networkcomponents around it. Not
to mention
economic damages...
Anyone any thoughts on this?
Kind Regards,
Sander Holthaus
----- Original Message -----
Sent: Monday, November 25, 2002 10:57 AM
Post by Steve Leach
Group,
Is there a module for Apache 1.x or 2.x (new server so I have the
option
to
Post by Steve Leach
choose!!!), that will allow me to see what the cumulative bandwidth
usage
is
Post by Steve Leach
for (a) individual Virtual Hosts and (b) the Apache Server
as a whole?
I
Post by Steve Leach
would like to be able to produce adaily report that includes this
information in a formal bandwidth costing exercise.
If there is no feature (or module) for Apache, is there a product
thatanyone
Post by Steve Leach
can recommend that will provide such functionality.
Thanks in advance.
Best Regards,
Steve Leach
IT / Network Manager
MI International Ltd
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server
Project.
Post by Steve Leach
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP
Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP
Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Jean-Pierre Denis
2002-11-25 15:40:36 UTC
Permalink
Hi,
Post by Steve Leach
Is there a module for Apache 1.x or 2.x (new server so I have the option
to choose!!!), that will allow me to see what the cumulative bandwidth
usage is for (a) individual Virtual Hosts and (b) the Apache Server as a
whole? I would like to be able to produce adaily report that includes
this information in a formal bandwidth costing exercise.
What you could do is write a little script that would calculate the size
from the access_log files. I my logs, the last field is the size return
the the users browser. By calculating those you will be able to know what
is the bandwidth usage.

There is probably other ways to do this but this is an easy one !

Thanks,

Jean-Pierre Denis
jp at msfree dot ca




---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Sander Holthaus - Orange XL
2002-11-25 16:10:16 UTC
Permalink
I you want it only on a daily basis, most webloganalyzer will do. If you
want to do it instantly, you could write yourself a small perl-deamon that
does a tail on the accesslogs.

Kind regards,
Sander Holthaus

----- Original Message -----
From: "Jean-Pierre Denis" <***@msfree.ca>
To: <***@httpd.apache.org>
Cc: <***@mi-int.com>
Sent: Monday, November 25, 2002 4:40 PM
Post by Jean-Pierre Denis
Hi,
Post by Steve Leach
Is there a module for Apache 1.x or 2.x (new server so I have the option
to choose!!!), that will allow me to see what the cumulative bandwidth
usage is for (a) individual Virtual Hosts and (b) the Apache Server as a
whole? I would like to be able to produce adaily report that includes
this information in a formal bandwidth costing exercise.
What you could do is write a little script that would calculate the size
from the access_log files. I my logs, the last field is the size return
the the users browser. By calculating those you will be able to know what
is the bandwidth usage.
There is probably other ways to do this but this is an easy one !
Thanks,
Jean-Pierre Denis
jp at msfree dot ca
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
zeno
2003-01-29 21:02:22 UTC
Permalink
Doing authentication by referer is very bad and should never be done. It is very easily faked.
One way you could do this (if I'm properly understanding you) is to do authentication
by hosts with htaccess.

Add something like this inside your htaccess file

allow from 10.0.0.1

This way your other webserver (which I am assuming is passing data to webserver 1) can easily
log in. If you are talking about having 1 user visit 2 sites you can write a script to add and remove
entries from a htaccess file with the allow from option. If both sites are on the same machine then
simply have them use the same htaccess file.
im wondering if there is any way make this work
I have an existing site on an apahce server using a .htacess
authentication
now i have a new site that has its own .htaccess authentication. But i
also want site 2 to beable to access site 1 with out logining into site
1 .
Any body have an idea how to do this?
It Manager
AllTurbo Internet Services Inc
410-213-9388 Office
www.allturbo.com
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Joshua Slive
2003-01-29 21:13:08 UTC
Permalink
Post by zeno
Add something like this inside your htaccess file
allow from 10.0.0.1
This way your other webserver (which I am assuming is passing data to webserver 1) can easily
log in. If you are talking about having 1 user visit 2 sites you can write a script to add and remove
entries from a htaccess file with the allow from option. If both sites are on the same machine then
simply have them use the same htaccess file.
You would also need "satisfy any" if you are combining it with password
auth.

Plus, this only works if server1 is proxying requests through to server2.
It doesn't sound like that was what the original person was suggesting.

Joshua.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Lynn Schaper
2003-04-30 19:04:49 UTC
Permalink
Lynn Schaper
2003-05-09 15:56:09 UTC
Permalink
http_core.c
mod_so.c
suexec: disabled; invalid wrapper /usr/sbin/suexec
That made my CGI work! Yay! Why would suexec fail?
I must have missed the message that said "thank you" to everyone for
their time & suggestions?

Lynn
--
Lynn Schaper ***@colorado.edu
Information Technology Services Central and Unix Services
University of Colorado at Boulder 303-492-3872

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Mac Serve
2003-05-09 16:27:00 UTC
Permalink
Actually, the last email he sent said yay yay it worked yada yada yada,
and he asked another question. He's not done yet. *sigh*


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Cody Harris
2003-05-09 18:51:06 UTC
Permalink
Post by Lynn Schaper
http_core.c
mod_so.c
suexec: disabled; invalid wrapper /usr/sbin/suexec
That made my CGI work! Yay! Why would suexec fail?
I must have missed the message that said "thank you" to everyone for
their time & suggestions?
Yes, and i got my reply, i think. Thank you for your time and patience!

The only other things is i'm getting weird errors on my other cgi-bin, but
i'll save you guys and talk to the ikonboard people.

Catch ya lata!
Post by Lynn Schaper
Lynn
--
Information Technology Services Central and Unix Services
University of Colorado at Boulder 303-492-3872
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Lynn Schaper
2003-06-03 17:48:49 UTC
Permalink
If you're not setting MaxRequestsPerChild on Solaris, you probably
should be. If you are using it, it might be set too high.

- Look at your server-status and see how many requests each busy child
has served when your server slows down; set MaxRequestsPerChild below
that.

- You might also look at the memory footprint of your servers (top is a
good tool) and if they're getting large, kill them before they grow that
big (also with MaxRequestsPerChild).

Lynn
--
Lynn Schaper ***@colorado.edu
Information Technology Services Central and Unix Services
University of Colorado at Boulder 303-492-3872
I have recently added another apache instance on a solaris 2.6 and 2.8 =
servers. We reverse proxy to several servers over SSL. The performance =
seems to degrade over time. I have checked the child processes and the =
count is normally at 26. I am also using the built in SSLRandomSeed. =
So I would not think it had to do with the random device. After =
restarting apache performance picks up again. The first instance of =
apache was compiled the same way and I donot seem to notice the same =
problems. Any help will be greatly appreciated!
=20
=20
BUILDHOME=3D"/export/home/appladm/install"
CFLAGS=3D"${CFLAGS} -DUSE_SYSVSEM_SERIALIZED_ACCEPT"
PATH=3D/usr/bin:/usr/local/bin:/usr/ccs/bin:/usr/sbin:/sbin:.
=20
export CFLAGS PATH
=20
# set build params
=20
APACHEVER=3D"1.3.19"
MODSSLVER=3D"2.8.3"
OPENSSLVER=3D"0.9.6g"
=20
# build files
=20
echo "starting build"
=20
cd $BUILDHOME/mod_ssl-${MODSSLVER}-${APACHEVER}/
./configure \
--with-apache=3D../apache_$APACHEVER \
--with-ssl=3D../openssl-$OPENSSLVER \
--prefix=3D/usr/local/apache-mack \
--enable-module=3Dso \
--enable-module=3Dproxy \
--enable-shared=3Dssl \
--enable-shared=3Dmax
=20
#
echo "modssl prep. work done"
=20
# build apache
cd $BUILDHOME/apache_${APACHEVER}/
make
=20
echo "apache build done"
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Saunders Jack
2003-06-03 18:04:44 UTC
Permalink
The server's memory looks good by looking at the top information below:

CPU states: 95.8% idle, 2.0% user, 2.2% kernel, 0.0% iowait, 0.0% swap
Memory: 1024M real, 63M free, 952K swap in use, 1025M swap free

Also MaxRequestsPerChild is set to 10000

Are you talking about the server-status feature that is not enabled by default. I believe the module is mod_status.

Thanks

_________________________________________________
Jack Saunders
Global Siteminder Operation Resp/Dev.
MiddleWare
Volvo Information Technology
Dept 440
Greensboro, NC 27409, USA

Telephone: 336-393-2334
E-mail: ***@volvo.com


-----Original Message-----
From: Lynn Schaper [mailto:***@Colorado.EDU]
Sent: Tuesday, June 03, 2003 1:49 PM
To: ***@httpd.apache.org
Subject: Re: [***@httpd] Slow performance issues


If you're not setting MaxRequestsPerChild on Solaris, you probably
should be. If you are using it, it might be set too high.

- Look at your server-status and see how many requests each busy child
has served when your server slows down; set MaxRequestsPerChild below
that.

- You might also look at the memory footprint of your servers (top is a
good tool) and if they're getting large, kill them before they grow that
big (also with MaxRequestsPerChild).

Lynn
--
Lynn Schaper ***@colorado.edu
Information Technology Services Central and Unix Services
University of Colorado at Boulder 303-492-3872
I have recently added another apache instance on a solaris 2.6 and 2.8 =
servers. We reverse proxy to several servers over SSL. The performance =
seems to degrade over time. I have checked the child processes and the =
count is normally at 26. I am also using the built in SSLRandomSeed. =
So I would not think it had to do with the random device. After =
restarting apache performance picks up again. The first instance of =
apache was compiled the same way and I donot seem to notice the same =
problems. Any help will be greatly appreciated!
=20
=20
BUILDHOME=3D"/export/home/appladm/install"
CFLAGS=3D"${CFLAGS} -DUSE_SYSVSEM_SERIALIZED_ACCEPT"
PATH=3D/usr/bin:/usr/local/bin:/usr/ccs/bin:/usr/sbin:/sbin:.
=20
export CFLAGS PATH
=20
# set build params
=20
APACHEVER=3D"1.3.19"
MODSSLVER=3D"2.8.3"
OPENSSLVER=3D"0.9.6g"
=20
# build files
=20
echo "starting build"
=20
cd $BUILDHOME/mod_ssl-${MODSSLVER}-${APACHEVER}/
./configure \
--with-apache=3D../apache_$APACHEVER \
--with-ssl=3D../openssl-$OPENSSLVER \
--prefix=3D/usr/local/apache-mack \
--enable-module=3Dso \
--enable-module=3Dproxy \
--enable-shared=3Dssl \
--enable-shared=3Dmax
=20
#
echo "modssl prep. work done"
=20
# build apache
cd $BUILDHOME/apache_${APACHEVER}/
make
=20
echo "apache build done"
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Lynn Schaper
2003-06-03 19:19:09 UTC
Permalink
Check individual httpd's in top. You can sort by size by typing "o"
(order) then "size". See how big the biggest are, especially compared
to the smallest.

server-status is provided in mod_status, and you could add it. Since
you're limiting to 10000, though, you know at which point the children
are being recycled. You might try cutting that in half and see what
happens to performance; then tweak that number till you find your
balance point.

Lynn
--
Lynn Schaper ***@colorado.edu
Information Technology Services Central and Unix Services
University of Colorado at Boulder 303-492-3872
Post by Saunders Jack
CPU states: 95.8% idle, 2.0% user, 2.2% kernel, 0.0% iowait, 0.0% swap
Memory: 1024M real, 63M free, 952K swap in use, 1025M swap free
Also MaxRequestsPerChild is set to 10000
Are you talking about the server-status feature that is not enabled by default. I believe the module is mod_status.
Thanks
_________________________________________________
Jack Saunders
Global Siteminder Operation Resp/Dev.
MiddleWare
Volvo Information Technology
Dept 440
Greensboro, NC 27409, USA
Telephone: 336-393-2334
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
z***@cgisecurity.net
2003-06-20 15:57:26 UTC
Permalink
Do you have caching enabled? It is possible the page was saved in a compressed format and cached and is still being
served.
I am using Apache and IIS to serve my pages. I enabled compression on both
IIS and apache. I used "Ethreal" for sniffing the contents received from
server on the client machine. I accessed a particular page and sniffed
data
using ethreal when compression was enabled on Apache and then disabled
compression and accessed the same page. The page I accessed is a static
text
page. I sniffed data in both the cases (compression enabled and disabled)
I
could not make out whats the difference in both the cases.
Is there any way to determine that the data sent by the http server was
compressed by using a sniffer.
Make sure you are using a large enough sample page. The compress plugins
might be smart enough to realize that some pages will become larger with
compression enabled (because of a certain amount of overhead). Using a page
that only has "test" in it won't help. Try it with a HTML page that is at
least 10k in size.
Also, Ethereal might be intelligent and decode the compressed data? You
could try using telnet to grab the HEAD of the page to see if it 1) lists
the module you are using to compress the page and 2) it is returning the
proper "this page is compressed" headers.
-Jacob
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Bobby Krupczak
2003-10-21 17:44:46 UTC
Permalink
Hi!
I'm using apache 2.0.45 and I'm trying to get snmp monitoring of the number
of processes setup. Is there an OID that will poll the number of threads,
etc? In my older versions of apache we are using this OID,
.1.3.6.1.4.1.2021.2.1.5.1 and it returns the number of processes. Since
apache 2.x is different this particular OID doesn't work anymore. Any help
with this is greatly appreciated.
I think whats happening is that whoever wrote the module for apache
coded it to apache 1.x and has not updated it for 2.x. The OIDs
should not change despite the version of the program (e.g. httpd 1.x
or 2.x). I say this as one who has written/maintained a management
module for apaches 1.x and 2.x. That does not help too much. The
real answer is to stat the developer or group as to when they will
release support for httpd 2.x. Or, get the code and modify it if you
are programmatically inclined.

Bobby



---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Steven Garrett
2003-10-22 16:07:35 UTC
Permalink
Thanks for the info...guess I'll just have to write it myself and/or ping
the developer :(

-----Original Message-----
From: Bobby Krupczak [mailto:***@krupczak.org]
Sent: Tuesday, October 21, 2003 1:45 PM
To: ***@httpd.apache.org
Subject: Re: [***@httpd] snmp monitoring of apache 2.0


Hi!
I'm using apache 2.0.45 and I'm trying to get snmp monitoring of the number
of processes setup. Is there an OID that will poll the number of threads,
etc? In my older versions of apache we are using this OID,
.1.3.6.1.4.1.2021.2.1.5.1 and it returns the number of processes. Since
apache 2.x is different this particular OID doesn't work anymore. Any help
with this is greatly appreciated.
I think whats happening is that whoever wrote the module for apache
coded it to apache 1.x and has not updated it for 2.x. The OIDs
should not change despite the version of the program (e.g. httpd 1.x
or 2.x). I say this as one who has written/maintained a management
module for apaches 1.x and 2.x. That does not help too much. The
real answer is to stat the developer or group as to when they will
release support for httpd 2.x. Or, get the code and modify it if you
are programmatically inclined.

Bobby



---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Lynn Schaper
2003-11-03 22:35:32 UTC
Permalink
Pls help me.I have configured apache in soalris 8 and is working fine.
but after some days the threads increases and finally
the application hangs and is not serving properly.
what configuration shld i check for this problem in httpd.conf
Maxclient values I have given as 100.
Here's a few things to look at:
- What does server-status show in general? How many requests are
served per child? Maybe you need to set MaxRequestsPerChild.
- If you have 'top', what does that show
- Can you set MaxClients to a point where it will not hang?
- How is system memory? Do you have enough?
- Are you swapping?
- You might want to set-up some data collection with vmstat,
mpstat, iostat.

Lynn
--
Lynn Schaper ***@colorado.edu
Information Technology Services Central and Unix Services
University of Colorado at Boulder 303-492-3872

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Lynn Schaper
2003-12-17 19:03:39 UTC
Permalink
Did you resolve this? It seems the script might be calling itself a
second time. Does this problem occur with all CGI's, or just this one?
Have you tried a Hello World script?

Lynn
--
Lynn Schaper ***@colorado.edu
Information Technology Services Central and Unix Services
University of Colorado at Boulder 303-492-3872
OK, now I'm confused. What you are saying is that the above file
(Cart.html) is what your addToCart.pl script reads in, and you changed the
Perl script to prevent that. Now you do not see the extra GET in your
logs, but your output doesn't have all the fancy stuff around it,
right?
Right.
If you didn't change the JavaScript, then it still doesn't make
sense. I see nothing in the existing JavaScript that would cause the page
to reload. What does your Perl script look like?
Well I don't think that is the problem since I get the two entries in
the log by just loading the templet my script was reading as an html
file. But my script can be read here
http://cdw.homelinux.com:8086/addToCart.pl
BTW, when I ran my telnet tests your script still produced the template
around the dynamic output, so you must not have made the changes at that
time. Could you check the log files to see if the were two GET entries at
the time I was testing (Mon, 15 Dec 2003 07:49:03 GMT)? I only sent one
GET request, so the server only got one from me. If there are two, then
most likely the browsers aren't at fault.
Here are the relevant entries around that time period, I removed a bunch
of Gets for gif file in my images dir.
192.75.23.73 - - [15/Dec/2003:07:46:58 -0600] "GET /Cart.html HTTP/1.0"
200 5408
192.75.23.73 - - [15/Dec/2003:07:46:59 -0600] "GET /? HTTP/1.0" 200 5423
192.75.23.73 - - [15/Dec/2003:07:47:00 -0600] "GET /Cart.html? HTTP/1.0"
200 5408
146.109.240.107 - - [15/Dec/2003:07:49:37 -0600] "GET /Cart.html
HTTP/1.1" 200 5408
146.109.240.107 - - [15/Dec/2003:07:49:54 -0600] "GET /Cart.html?
HTTP/1.1" 200 5408
195.129.18.251 - - [15/Dec/2003:07:50:32 -0600] "GET /Cart.html
HTTP/1.1" 200 5408
195.129.18.251 - - [15/Dec/2003:07:50:35 -0600] "GET /Cart.html?
HTTP/1.1" 200 5408
195.129.18.251 - - [15/Dec/2003:07:50:43 -0600] "GET /Cart.html?
HTTP/1.1" 206 3360
66.26.252.107 - - [15/Dec/2003:08:05:07 -0600] "GET /Cart.html HTTP/1.1"
200 5408
66.26.252.107 - - [15/Dec/2003:08:05:08 -0600] "GET /Cart.html?
HTTP/1.1" 200 5408
64.30.129.203 - - [15/Dec/2003:08:13:50 -0600] "GET /song2.html
HTTP/1.1" 200 302
BTWA, your script seems to output a superfluous "Content-Type" header.
I just noticed that myself too, and fixed it.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Robert Andersson
2003-12-18 06:45:20 UTC
Permalink
Post by Lynn Schaper
Did you resolve this? It seems the script might be calling itself a
second time. Does this problem occur with all CGI's, or just this one?
Have you tried a Hello World script?
Other possibilties inproper mod_rewrite rules, Redirect or RedirectMatch
directives, and the like.

Regards,
Robert Andersson


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Chris W
2003-12-18 14:01:14 UTC
Permalink
Post by Lynn Schaper
Did you resolve this?
Yes I did, it ended up being a simple BACKGROUND="?" in my header tag of
the html templet I was reading that caused the problem.
--
Chris Woodhouse
3147 SW 127th St.
Oklahoma City, OK 73170
405-691-5206
N35° 20.492'
W97° 34.342'

"They that can give up essential liberty
to obtain a little temporary safety
deserve neither liberty nor safety."
-- Benjamin Franklin, 1759 Historical Review of Pennsylvania

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Jim Jagielski
2004-05-17 12:55:21 UTC
Permalink
A patch would help...
Hi Kira,
I'm running v1.3.31 on Win32 and that bug is defintely NOT fixed. Further,
as with previous versions, no LogLevel stops the errors filling the log.
Most annoying. Other than that, v1.3.31 is running fine.
Regards,
Martin
----- Original Message -----
Date: Sun, 16 May 2004 19:29:26 -0700
"Yes, this is a bug in 1.3.28/1.3.29 which does a preventative
close on socket fd's. Under Win32 this is unneeded and is not done,
but Apache thinks this is an error.
Bumping up LogLevel past warn will prevent the errors from filling
error_log. This will be fixed in 1.3.30"
Has this bug been fixed or not? Anyone know?
Regards,
Kira
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
--
===========================================================================
Jim Jagielski [|] ***@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 14:08:02 UTC
Permalink
(snipped)

(read thread to learn about near fatal bugs in Apache)
Post by Jim Jagielski
I'm running v1.3.31 on Win32 and that bug is defintely NOT fixed. Further,
as with previous versions, no LogLevel stops the errors filling the log.
Most annoying. Other than that, v1.3.31 is running fine.
A patch would help...
Jim, I am using your article as an excuse to rant.

My previous experience is, when submitting a bug report, is Apache
bugzilla will close a bug report in a matter of an hour or two,
claiming "resolved - invalid." Doesn't matter if a bug report
is valid, is true, is documented. It is instantly closed without
any discussion or debate.

I have engaged a number of people at Apache Org in discussion
of these types of problems and have discovered adamant denial
and excuse making; Redmond Syndrome.

My rant is it is clear Apache does not platform test their
releases. This is, Apache appears to test only on Unix like
platforms and assumes their server will work for all systems.
This is a serious mistake, much like the flaws in Redhat 9
compared to Redhat 8, regarding use of Perl.

Redhat 9 Personal is longer maintained because of all
the bugs; to difficult to fix and release patches. This
is why I was able to buy a brand new Redhat 9 package
off Ebay for only five bucks.

As a programmer specializing in Win32 applications, I maintain
several machines loaded with various versions of Windows, from
Win98 through recent NT5 types. Before I realease any code to
public forums, I test my code on all of my boxes to be sure
there are no bugs, or to afford an ability to document bugs
so others will know.

I also maintain a machine loaded with Linux for testing
and all of my coding and programs are released for free,
just as is Apache.

Apache Org has almost infinite resources, an infinite source
for all types of operating systems, from Unix to Apple. These
resources are available via so many developers and contributors
to Apache development. I should be so lucky to have so many
different platforms available for platform testing. I should
be so lucky to have so many intelligent people to test my
programming methods for me.

This socket closure problem could have been caught in a matter
of minutes by asking developers to platform test and return
observed results, platform specific.

Why is it Apache does not platform test before release?

I would like to read reasons for this lack of exhaustive
platform testing by Apache Org. Any representative of
Apache Org willing to tackle this topic? Doing so will
certainly serve to improve the quality of Apache, the
best server written to date but quickly losing quality,
much like Redhat has.

As an individual, I have purchased a number of machines,
purchased a number of operating system software, so I
can platform test before release. Apache can platform
test for free through a vast audience.

Why is it Apache does not platform test before release?


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Joshua Slive
1970-01-01 00:00:00 UTC
Permalink
Post by Purl Gurl
My previous experience is, when submitting a bug report, is Apache
bugzilla will close a bug report in a matter of an hour or two,
claiming "resolved - invalid." Doesn't matter if a bug report
is valid, is true, is documented. It is instantly closed without
any discussion or debate.
I don't want to pick on you, but you seem to have a bad habit of making
unfounded and inaccurate generalizations based on limited experience.

You have reported one issue to the apache bug database, and that issue was
closed for entirely valid and correct reasons (by me). If anyone else is
interested, see:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28193

Certainly bug reports are occasionally mistakenly closed, but that is not
a common occurrence.

Joshua.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 14:30:14 UTC
Permalink
(snipped)
Post by Joshua Slive
Post by Purl Gurl
My previous experience is, when submitting a bug report, is Apache
bugzilla will close a bug report in a matter of an hour or two,
claiming "resolved - invalid." Doesn't matter if a bug report
is valid, is true, is documented. It is instantly closed without
any discussion or debate.
I don't want to pick on you,
Then why are you doing so?

I could discuss what happened, discuss factual information,
discuss how people at Apache handled my input, but this
would only serve to lessen Apache's reputation. Doing so,
would be highly counterproductive.

Joshua, many have learned, over the years, I am not the
person to subject to this type of "picking." You will
fair better to simply ignore me and allow others to
openly discuss issues without fear of being "picked on"
by a person representing Apache Org.

I am here to research, to learn, to improve my knowledge
and to afford input which will improve the quality of
Apache server software. I am not convinced you are here
for similar reasons.

Regards,

Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Jim Jagielski
2004-05-17 14:25:30 UTC
Permalink
Post by Purl Gurl
Apache Org has almost infinite resources, an infinite source
for all types of operating systems, from Unix to Apple. These
resources are available via so many developers and contributors
to Apache development. I should be so lucky to have so many
different platforms available for platform testing. I should
be so lucky to have so many intelligent people to test my
programming methods for me.
I *wish* we had "almost infinite resources". We depend and
rely on the people within the PMC and development lists
to test the code before we release. If you think that
the ASF has a "team" of platforms and people who
are "assigned" pre-release testing then your perceptions
are very incorrect.

Are you on the dev@ list? If so, have you provided a
patch to the code to fix the problem? Certainly someone
who is a "programmer specializing in Win32 applications"
would be most welcome to the dev@ list.


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 14:38:44 UTC
Permalink
(snipped)
Post by Jim Jagielski
patch to the code to fix the problem? Certainly someone
who is a "programmer specializing in Win32 applications"
I have and am providing input here, in newsgroups and
directly to Apache. I have also indicated I am working
on repairing bugs and, if successful, will share all
information and hacks.

What more could you want?

It has become clear to me, over the years, Apache is
not able to accept constructive criticism. It is clear
there are a few who trip on their egos, not all, but
a few have some ego problems, which ruins it for all.

Jim, I am adamantly pushing in information and feedback
to Apache, and responses, thus far, have been denial
and in some cases, personal insult.

Apache is excellent software developed by excellent
software writers and programmers. I hold only admiration
for Apache, and hold reservations about Apache's public
relations skills.

When a person points out bugs in my programming, I listen,
I learn, I test, I improve. Apache should do the same.

Regards,


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Jim Jagielski
2004-05-17 14:50:55 UTC
Permalink
Post by Purl Gurl
I have and am providing input here, in newsgroups and
directly to Apache. I have also indicated I am working
on repairing bugs and, if successful, will share all
information and hacks.
That is great. If you have a patch for the
"exec not safe" bug, please let me know and
I'll take a look personally.
Post by Purl Gurl
It has become clear to me, over the years, Apache is
not able to accept constructive criticism. It is clear
there are a few who trip on their egos, not all, but
a few have some ego problems, which ruins it for all.
I will admit that there are times when you are
correct; times when we are maybe a bit more impatient
than we should be. There are other times, of course,
when we get frustrated by the sheer audacity of
some people, especially when they don't understand
*collaborative* development or provide such helpful
comments as "This is broke. Please fix it because
it is really messing things up. Let me know when
you've fixed it."


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 15:50:08 UTC
Permalink
Post by Jim Jagielski
Post by Purl Gurl
I have and am providing input here, in newsgroups and
directly to Apache. I have also indicated I am working
on repairing bugs and, if successful, will share all
information and hacks.
That is great. If you have a patch for the
"exec not safe" bug, please let me know and
I'll take a look personally.
I am currently working on the request method bug.
This bug is more serious and appears in all versions
of Apache, 1.3.x and 2.x versions.

This socket closure bug, I have not even taken a
casual glance at this. Eventually I will, but for
now I maintain my priorities; fix the WebDave bug
first then move on.
Post by Jim Jagielski
Post by Purl Gurl
It has become clear to me, over the years, Apache is
not able to accept constructive criticism. It is clear
there are a few who trip on their egos, not all, but
a few have some ego problems, which ruins it for all.
I will admit that there are times when you are
correct; times when we are maybe a bit more impatient
than we should be. There are other times, of course,
when we get frustrated by the sheer audacity of
some people, especially when they don't understand
*collaborative* development or provide such helpful
comments as "This is broke. Please fix it because
it is really messing things up. Let me know when
you've fixed it."
Yes, your personal perception is quite accurate.

Many people tend to be "spoiled" and very demanding.
This is a bug in personal behavior which none of
us can repair; that is a parental problem. As a
retired educator, I am all too well aware of this
annoying quirk in personalities.

Should you tell people like this to F-off, I would
support you on this and chime in.

On the socket closure problem, this bug has been public
knowledge for at least a year.

You have made an admission and I will make one. I am
significantly annoyed Apache allowed this bug into
the latest 1.3.31 version. They knew about it and
elected to not resolve this bug. To find a cure
is relatively simple; what changed between version
1.3.27 and 1.3.28 in handling socket closure? There
in will be discovered the source of this bug.

Fortunately, all have been patient on repair of this
bug, least I believe so. I have not read any articles
in a variety of forums demanding a cure. I have read
a lot of articles in many forums, asking how to cure
this bug. There are no current solutions.

This WebDav bug, I have doubts Apache will ever address
this bug. It is a bug because Apache allows "any" request
method, and should not. Request methods should be limited
to only those actually in use. Other supporting evidence
for this being a bug is ip blocking is disabled for
request methods; Apache hooks this before ip blocking.
Additionally, Apache writes the WebDav garbage to a
log file and does not allow an administrator to parse
before it is written.

In short, WebDav script kiddies have complete control
over Apache. This is inexcusable.

Why this is inexcusable is WebDav idiots can send in this
hack at a rate of one per second, around the clock, and
suffer no consequences. Requests at one per second is not
a sufficient rate to kick in preventative denial of service
functions. A script kiddie can pump log records at a rate
of eight kilobytes per second, with no effort. Apache
claims this is not a problem. I strongly disagree.

This is also inexcusable because most firewall firmware
cannot recognize a WebDav exploit unless linked to SNORT
or SamSnort software. Very few firewall firmware are
capable of SNORT linkage, or those which can, costs
tens of thousands of dollars. Nonetheless, adminstrators
should not be placed in a position of employing externalities
to cure problems caused by Apache.

True problem here is Apache does not allow hooking in a
module to address those request methods which are handled
by Apache's frontend, well before administrative methods.

Based on my reading of limited comments in Apache source
files, it is possible to hook within Apache's frontend,
specifically in the protocol files, however complicated.

In summary, Apache affords no method to deal with request methods
which generate an error return response. This causes serious
problems for administrators, problems which are exceptionally
well documented, despite being denied by Apache Org.

I understand it is very difficult to project ahead, to forecast
what might happen, to know of exploits before they arrive;
none have a working crystal ball. Nevertheless, once known,
a problem should be addressed in a timely fashion.


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Joshua Slive
1970-01-01 00:00:00 UTC
Permalink
[I'm sorry to reply again. I suggest most people simply ignore this
thread. I just can't let false information stand unchallenged.]
Post by Purl Gurl
This WebDav bug, I have doubts Apache will ever address
this bug. It is a bug because Apache allows "any" request
method, and should not. Request methods should be limited
to only those actually in use. Other supporting evidence
for this being a bug is ip blocking is disabled for
request methods; Apache hooks this before ip blocking.
Additionally, Apache writes the WebDav garbage to a
log file and does not allow an administrator to parse
before it is written.
In short, WebDav script kiddies have complete control
over Apache. This is inexcusable.
False. The only thing script kiddies can do is cause log entries to be
written, and they can do that lots of different ways.
Post by Purl Gurl
Why this is inexcusable is WebDav idiots can send in this
hack at a rate of one per second, around the clock, and
suffer no consequences. Requests at one per second is not
a sufficient rate to kick in preventative denial of service
functions. A script kiddie can pump log records at a rate
of eight kilobytes per second, with no effort. Apache
claims this is not a problem. I strongly disagree.
If you were somehow able to magically prevent SEARCH requests, the exact
same attack would be possible with GET requests. There is absolutely
nothing apache can do to prevent people from sending huge requests to the
server. This is part of being on the Internet. What apache can do is
deal with those requests in the most efficient and expedient way: deny
them immediately and do no further processing (other than logging).

If your log file can't handle requests of this size, you better reduce the
value of LimitRequestLine in httpd.conf. That will prevent the
logfile-growing-too-quickly problem.
Post by Purl Gurl
True problem here is Apache does not allow hooking in a
module to address those request methods which are handled
by Apache's frontend, well before administrative methods.
It is true that this is a missing feature. But it is missing by design
choice. If a request is malformed, then it would be a possible security
hazard to let it go through all the normal processing. So it is simply
denied and logged. Now, with the present apache architecture, this means
the only way to prevent the logging is with a piped-log program. But as
I've said, I don't see that as a significant flaw.
Post by Purl Gurl
In summary, Apache affords no method to deal with request methods
which generate an error return response. This causes serious
problems for administrators, problems which are exceptionally
well documented, despite being denied by Apache Org.
False again. It is only very specific error responses that short-circuit
normal processing: those caused by malformed requests. And the only
"problem" this causes is logfile lines, which most people WANT to have
in order to monitor their server.

Joshua.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Ben Chabot
2004-05-17 16:23:54 UTC
Permalink
Sorry to reply to this message, it's really to Kira.

At any rate, Kira, you are logging hack attempts, yet you want to shut
off logging of the IIS webdav exploit (or so it seems). What if one day
there is a similar exploit that works and you aren't logging it? It's a
good idea to log it all, today those logs might be useless, but it's
hard to say what will be useful in the future.

That being said, why don't you grep the SEARCH line out of the logs? Or
rotate your logs? Or link you logs to /dev/null (heh). A google search
will tell you how to do these things.

Or, I'm not sure about this, but perhaps you could install snort, with
an active response rule, intercept and respond to the traffic before it
hits apache? I'm far from an expert, a newbie really, but it seems out
of place for apache to even have an option to not log certain things.
It's job is to log everything, all exploit attempts. If you don't find
some of the information useful, it's your job to filter it out, rather
than implementing some complex filter inside apache... it's a webserver,
not a log filter.

Now... anyone read my "suexec w/chroot + shared ssl" problem? Or do I
need to make a bug report? (Hehehe, kidding.)

Ben
Post by Porter, Mark
-----Original Message-----
Sent: Monday, May 17, 2004 12:11 PM
In 1.3.31 Or Not?
[I'm sorry to reply again. I suggest most people simply ignore this
thread. I just can't let false information stand unchallenged.]
Post by Purl Gurl
This WebDav bug, I have doubts Apache will ever address
this bug. It is a bug because Apache allows "any" request
method, and should not. Request methods should be limited
to only those actually in use. Other supporting evidence
for this being a bug is ip blocking is disabled for
request methods; Apache hooks this before ip blocking.
Additionally, Apache writes the WebDav garbage to a
log file and does not allow an administrator to parse
before it is written.
In short, WebDav script kiddies have complete control
over Apache. This is inexcusable.
False. The only thing script kiddies can do is cause log
entries to be
written, and they can do that lots of different ways.
Post by Purl Gurl
Why this is inexcusable is WebDav idiots can send in this
hack at a rate of one per second, around the clock, and
suffer no consequences. Requests at one per second is not
a sufficient rate to kick in preventative denial of service
functions. A script kiddie can pump log records at a rate
of eight kilobytes per second, with no effort. Apache
claims this is not a problem. I strongly disagree.
If you were somehow able to magically prevent SEARCH
requests, the exact
same attack would be possible with GET requests. There is absolutely
nothing apache can do to prevent people from sending huge
requests to the
server. This is part of being on the Internet. What apache can do is
deal with those requests in the most efficient and expedient way: deny
them immediately and do no further processing (other than logging).
If your log file can't handle requests of this size, you
better reduce the
value of LimitRequestLine in httpd.conf. That will prevent the
logfile-growing-too-quickly problem.
Post by Purl Gurl
True problem here is Apache does not allow hooking in a
module to address those request methods which are handled
by Apache's frontend, well before administrative methods.
It is true that this is a missing feature. But it is missing
by design
choice. If a request is malformed, then it would be a
possible security
hazard to let it go through all the normal processing. So it
is simply
denied and logged. Now, with the present apache
architecture, this means
the only way to prevent the logging is with a piped-log
program. But as
I've said, I don't see that as a significant flaw.
Post by Purl Gurl
In summary, Apache affords no method to deal with request methods
which generate an error return response. This causes serious
problems for administrators, problems which are exceptionally
well documented, despite being denied by Apache Org.
False again. It is only very specific error responses that
short-circuit
normal processing: those caused by malformed requests. And the only
"problem" this causes is logfile lines, which most people WANT to have
in order to monitor their server.
Joshua.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP
Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 17:02:37 UTC
Permalink
Ben Chabot wrote:

(snipped)
Post by Ben Chabot
Sorry to reply to this message, it's really to Kira.
You are casting me as a "bad guy" which is inappropriate.

Use of Ad Hominem, which is so typical of the ignorant,
only serves to annoy me and serves to encourage me to
be more admanant in excercising my freedom of opinion.

I am here to discuss and learn. I am not here to present
myself an easy target for the ignorant.
Post by Ben Chabot
At any rate, Kira, you are logging hack attempts, yet you want to shut
off logging of the IIS webdav exploit (or so it seems).
As disclosed in many discussions, here and elsewhere, it is impossible
to "shut off" logging of Webdav exploits via Apache. This is a well
known bug although denied by many.

I am miffed by selected people who claim this is not a bug,
and in subsequent conversation, labeled this a bug. Some
do not keep track of what they write.

Only cure is piped logging which requires additional system
resources and memory hogging software.

Parsing logs after injury, is possible but presents serious
problems such as having to shut down Apache before parsing
so not to lose current data not yet flushed by Apache.
Post by Ben Chabot
there is a similar exploit that works and you aren't logging it? It's a
good idea to log it all, today those logs might be useless, but it's
hard to say what will be useful in the future.
Log all thrity-thousand bytes of the WebDav entry or the default
eight-thousand plus bytes? Why? I only need to see "SEARCH" in
the request to know it is WebDav and to know this method should
not be allowed. Why log kilobytes of garbage? Why allow request
methods which are not valid?
Post by Ben Chabot
That being said, why don't you grep the SEARCH line out of the logs?
I do this, which is a waste of system resources. Yes, this places
a Band-Aid on the wound but does not cure the source of injury.
Post by Ben Chabot
Or, I'm not sure about this, but perhaps you could install snort,
Yes, I use SNORT. However, SNORT is a passive system and may or may
not intervene, depending on platform, hooking of lan cards and
other factors. For many case examples, SNORT is useless because
Apache does not allow ip blocking for some request methods.

SNORT, like Apache, is excellent software. Do not misunderstand
what I write. I am saying, for some circumstances, both Apache
and SNORT become useless because of bugs or limitations. This
is quite common. Nonetheless, some of these bugs can be fixed.

Again yes, you can capture these exploits via sniffing, via
IDS software, such as SNORT. However, many find nothing can
be done to prevent these problems; you know about the problems
and know you are defenseless.

Hooking lan cards is very challeging and is supported on only
specific platforms, such as Linux and NT5. In most cases, a
person is required to establish a stand-alone machine to act
as a transparent firewall or NAT translating machine. In other
cases, a stand-alone server machine can handle all needed
functions adequately, but at a serious system resource cost.

Our family webserver is currently spread out over three machines.
I really don't want to buy more machines to cure a problem which
could be easily cured by Apache, if those bugs did not exist.

Thanks for your input, it is valuable to all readers. Many will
investigate your suggestions and learn. Once many have learned
the true and factual nature of these problems, then resolution
methods will be presented. While readers adamantly claim these
are not problems, no resolution will ever be offered, a classic
display of the Ostrich Syndrome.


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Ben Chabot
2004-05-17 17:29:02 UTC
Permalink
Why allow request methods which are not valid?
As far as I understand, it does not "allow" these methods. It merely
logs the attempt. Which is the wise thing to do. Not logging hits that
come against your server is not a good idea. I don't see why the option
should even be in apache. Even if you log just a shortened version, you
don't know if it's just the old annoying IIS webdav exploit, or
something new, and you haven't logged it so you can't look and see.

I don't think it's a "bug fix" to mangle httpd so it doesn't log certain
connection attempts according to your personal tastes.

Just filter your logs and stop worrying about system resources. Are you
really topped out to the point that running a script hourly or daily is
going to break you? How about rotating your logs when they get to a
certain size? You are using webalizer anyway, so processing log files
(instead of forcing apache to do it) is the reasonable thing to do, and
can't be any more intensive than some of the log analyzation you are
doing anyway.

And it's not a "band-aid" fix for a broken apache... apache does exactly
what it's supposed to do, afaik, which is log all connection attempts.
Like someone said, if it wasn't SEARCH filling your logs, it would be
tons of long GET requests. Anything can fill the logs, this is not a
bug. I suppose if you get 20M of GET requests in a day, you'll want to
mangle apache so it won't log those either? Bah... filter your logs and
move on.

But I'm done... Just my two cents... a word of advice, rather than
arguing, why don't you patch apache now, and release the patch for
people who want to use it? Or write a perl script to filter your logs.
It would probably be a lot more productive than insulting people who are
only trying to make helpful suggestions. (I'd be ecstatic if someone
gave me a helpful suggestion *hint* HEH).

ben
-----Original Message-----
Sent: Monday, May 17, 2004 1:03 PM
In 1.3.31 Or Not?
(snipped)
Post by Ben Chabot
Sorry to reply to this message, it's really to Kira.
You are casting me as a "bad guy" which is inappropriate.
Use of Ad Hominem, which is so typical of the ignorant,
only serves to annoy me and serves to encourage me to
be more admanant in excercising my freedom of opinion.
I am here to discuss and learn. I am not here to present
myself an easy target for the ignorant.
Post by Ben Chabot
At any rate, Kira, you are logging hack attempts, yet you
want to shut
Post by Ben Chabot
off logging of the IIS webdav exploit (or so it seems).
As disclosed in many discussions, here and elsewhere, it is impossible
to "shut off" logging of Webdav exploits via Apache. This is a well
known bug although denied by many.
I am miffed by selected people who claim this is not a bug,
and in subsequent conversation, labeled this a bug. Some
do not keep track of what they write.
Only cure is piped logging which requires additional system
resources and memory hogging software.
Parsing logs after injury, is possible but presents serious
problems such as having to shut down Apache before parsing
so not to lose current data not yet flushed by Apache.
Post by Ben Chabot
there is a similar exploit that works and you aren't
logging it? It's a
Post by Ben Chabot
good idea to log it all, today those logs might be useless, but it's
hard to say what will be useful in the future.
Log all thrity-thousand bytes of the WebDav entry or the default
eight-thousand plus bytes? Why? I only need to see "SEARCH" in
the request to know it is WebDav and to know this method should
not be allowed. Why log kilobytes of garbage? Why allow request
methods which are not valid?
Post by Ben Chabot
That being said, why don't you grep the SEARCH line out of the logs?
I do this, which is a waste of system resources. Yes, this places
a Band-Aid on the wound but does not cure the source of injury.
Post by Ben Chabot
Or, I'm not sure about this, but perhaps you could install snort,
Yes, I use SNORT. However, SNORT is a passive system and may or may
not intervene, depending on platform, hooking of lan cards and
other factors. For many case examples, SNORT is useless because
Apache does not allow ip blocking for some request methods.
SNORT, like Apache, is excellent software. Do not misunderstand
what I write. I am saying, for some circumstances, both Apache
and SNORT become useless because of bugs or limitations. This
is quite common. Nonetheless, some of these bugs can be fixed.
Again yes, you can capture these exploits via sniffing, via
IDS software, such as SNORT. However, many find nothing can
be done to prevent these problems; you know about the problems
and know you are defenseless.
Hooking lan cards is very challeging and is supported on only
specific platforms, such as Linux and NT5. In most cases, a
person is required to establish a stand-alone machine to act
as a transparent firewall or NAT translating machine. In other
cases, a stand-alone server machine can handle all needed
functions adequately, but at a serious system resource cost.
Our family webserver is currently spread out over three machines.
I really don't want to buy more machines to cure a problem which
could be easily cured by Apache, if those bugs did not exist.
Thanks for your input, it is valuable to all readers. Many will
investigate your suggestions and learn. Once many have learned
the true and factual nature of these problems, then resolution
methods will be presented. While readers adamantly claim these
are not problems, no resolution will ever be offered, a classic
display of the Ostrich Syndrome.
Kira
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP
Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Herb Stein
2004-05-18 02:25:16 UTC
Permalink
Post by Porter, Mark
-----Original Message-----
Sent: Monday, May 17, 2004 12:03 PM
Not?
(snipped)
Post by Ben Chabot
Sorry to reply to this message, it's really to Kira.
You are casting me as a "bad guy" which is inappropriate.
Use of Ad Hominem, which is so typical of the ignorant,
only serves to annoy me and serves to encourage me to
be more admanant in excercising my freedom of opinion.
I am here to discuss and learn. I am not here to present
myself an easy target for the ignorant.
You're married to Fraiser, right?
Post by Porter, Mark
Post by Ben Chabot
At any rate, Kira, you are logging hack attempts, yet you want to shut
off logging of the IIS webdav exploit (or so it seems).
As disclosed in many discussions, here and elsewhere, it is impossible
to "shut off" logging of Webdav exploits via Apache. This is a well
known bug although denied by many.
I am miffed by selected people who claim this is not a bug,
and in subsequent conversation, labeled this a bug. Some
do not keep track of what they write.
Only cure is piped logging which requires additional system
resources and memory hogging software.
Parsing logs after injury, is possible but presents serious
problems such as having to shut down Apache before parsing
so not to lose current data not yet flushed by Apache.
Post by Ben Chabot
there is a similar exploit that works and you aren't logging it? It's a
good idea to log it all, today those logs might be useless, but it's
hard to say what will be useful in the future.
Log all thrity-thousand bytes of the WebDav entry or the default
eight-thousand plus bytes? Why? I only need to see "SEARCH" in
the request to know it is WebDav and to know this method should
not be allowed. Why log kilobytes of garbage? Why allow request
methods which are not valid?
Post by Ben Chabot
That being said, why don't you grep the SEARCH line out of the logs?
I do this, which is a waste of system resources. Yes, this places
a Band-Aid on the wound but does not cure the source of injury.
Post by Ben Chabot
Or, I'm not sure about this, but perhaps you could install snort,
Yes, I use SNORT. However, SNORT is a passive system and may or may
not intervene, depending on platform, hooking of lan cards and
other factors. For many case examples, SNORT is useless because
Apache does not allow ip blocking for some request methods.
SNORT, like Apache, is excellent software. Do not misunderstand
what I write. I am saying, for some circumstances, both Apache
and SNORT become useless because of bugs or limitations. This
is quite common. Nonetheless, some of these bugs can be fixed.
Again yes, you can capture these exploits via sniffing, via
IDS software, such as SNORT. However, many find nothing can
be done to prevent these problems; you know about the problems
and know you are defenseless.
Hooking lan cards is very challeging and is supported on only
specific platforms, such as Linux and NT5. In most cases, a
person is required to establish a stand-alone machine to act
as a transparent firewall or NAT translating machine. In other
cases, a stand-alone server machine can handle all needed
functions adequately, but at a serious system resource cost.
Our family webserver is currently spread out over three machines.
I really don't want to buy more machines to cure a problem which
could be easily cured by Apache, if those bugs did not exist.
Thanks for your input, it is valuable to all readers. Many will
investigate your suggestions and learn. Once many have learned
the true and factual nature of these problems, then resolution
methods will be presented. While readers adamantly claim these
are not problems, no resolution will ever be offered, a classic
display of the Ostrich Syndrome.
Kira
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
--
Herb Stein
The Herb Stein Group, Inc.
www.herbstein.com
***@herbstein.com
314 952-4601



---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Tim Thorburn
2004-05-17 16:46:49 UTC
Permalink
Wow ...

Ok, impartial observer here ... I'm on this list because I'm a web designer
who uses Apache for hosting and local testing, not a sysadmin or someone
who makes their living off of the goodness that is Apache. So far, I'm
seeing someone present a problem that she feels is a problem, and then be
ignored or ridiculed for thinking this is a problem.

Personally, I've asked several questions on this list and other similar
lists wherein those who know (or in many cases those who *think* they know)
dismiss any question to their ways as absurd remarks from those who should
not speak. Now, I'll be the first to admit I'm far from an expert in many
areas, but when a person is publicly chewed out as Kira has been in this
case ... it imposes something of an elitist view over the entire Apache
community - don't you dare ask a question lest we mock you for wasting our
time in asking this question.

Again, this is not something found only on this mailing list - it is quite
frequent on the MySQL and PHP lists as well.

Ok, blah blah, who cares, half of you have deleted this message already,
the other half are prepared your assault weapon words - the point is -
settle boys and girls, you don't like something you see here, let it go -
hit the trash can button extra hard if that does it for you. Yeah, in some
cases Kira's comments could be taken in an abrasive manner - but if you
have 3 or 4 ppl blasting you on a public forum, might you not come off as a
little abrasive too?

Anyways, lunch time - go do whatever it is that you do and come back more
on the happy shiny side and less on the *i hate all who disagree with me* side.



---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Robert Andersson
2004-05-17 18:02:57 UTC
Permalink
Post by Tim Thorburn
but when a person is publicly chewed out as Kira has been in this
case ... it imposes something of an elitist view over the entire
Apache community
The situation usually arise when someone propose a problem/question which is
either badly founded or illformed. This is then, initially kindly, pointed
out, and the original person takes it as an insult and starts to act
unreasonable; unwilling to listen, do not answer counter-questions, do not
take proven fallacies into account, etc. "We" are here to help (and learn
while doing it), and when someone refuse/ignores the help given, "we" get
annoyed.

The problem is: what are "we" to do in such situation? Ignore the person?
Not very nice. Start writing things "we" know are untrue, to make that
someone feel better? Probably not.

This I have observered in many hacker/technical forums. Whether the above
description applies to the current discussion, and to what extent, I do not
say, but leave that to each observer to judge.

Regards,
Robert Andersson


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Joshua Slive
1970-01-01 00:00:00 UTC
Permalink
Post by Tim Thorburn
Ok, impartial observer here ... I'm on this list because I'm a web designer
who uses Apache for hosting and local testing, not a sysadmin or someone
who makes their living off of the goodness that is Apache. So far, I'm
seeing someone present a problem that she feels is a problem, and then be
ignored or ridiculed for thinking this is a problem.
What you perhaps don't realize is that this person has made exactly the
same claims in several different forums. Each time, someone has described
to her/him in detail why these claims are incorrect. But she/he doesn't
seem to understand or accept the explanations and keeps making these false
claims.

Personally, I have not attempted to ridicule Kira. I made one comment
where I pointed out the continued use of overgeneralizations from limited
experience. Other than that, I have simply stated facts.

In general, people (including myself) are sometimes rude on technical
mailing lists, and this is something we should try to avoid. But much
more often what happens is that people who don't understand the tone of a
technical mailing list will interpret a curt, factual response as a rude
response, when no such thing was intended. You need to be very careful
reading tone into email.

Joshua.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Laura Vance
2004-05-17 20:20:23 UTC
Permalink
Hello,

I have an idea that should solve all problems. (yeah, right. ;) )

What I would propose is to allow a directive in the httpd.conf file that
would be something like this:

<methodLogging>
DENY SEARCH etc.
ALLOW ALL
</methodLogging>

or something like that to deny specific request logging and allow all
the others. Since it's been stated that request methods that are not
configured don't actually get "processed", this would just keep them
from showing up in the log. I mean, if they're not processed, there's
no risk of contamination of any kind, right?

The reason I think this might help is that while most of us want to have
our logs so that we can look back to before a problem happened to see
what led up to it, others do not want this function. Just as it's not
one person's place to say what I want, it's not my place to say what
they want either.

With that being said, I personally have no reason to stop any methods
from reaching my log, but who's to say that someone just doesn't care
for it. I guess an example (if one is needed) is that you can tell
someone that the paint is wet, but until they touch it, they don't know
for sure. One thing to think about is if someone does have their logs
set to not log anything, then if they ask for help because someone
hacked their server, the question could be "what's in your logs?" If
the response is "they were turned off" you can feel justified in saying
"why weren't you logging? we can't help you without logs."

Also just to clarify, I don't see detailed logs as a "bug", but the
ability to select what you log would be more of a feature request.
Isn't that partly why we love Linux and the open source movement... the
"man" can't tell us what to do (or log as the case may be).
--
Thanks,
Laura Vance
Systems Engineer
Winfree Academy Charter Schools, Data-Business Office
1711 W. Irving Blvd. Ste 310
Irving, Tx 75061
Web: www.winfreeacademy.com



---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Joshua Slive
1970-01-01 00:00:00 UTC
Permalink
Post by Laura Vance
I have an idea that should solve all problems. (yeah, right. ;) )
What I would propose is to allow a directive in the httpd.conf file that
<methodLogging>
DENY SEARCH etc.
ALLOW ALL
</methodLogging>
The thing is, there is already a flexible conditional logging method using
mod_setenvif and env= on CustomLog. It is just that certain very specific
types of malformed requests will skip the usual mod_setenvif processing.
Is it really worth it to reimpliment an existing feature just to catch
this very specific case? (Surely some people would say yes; but I guess
nobody who is willing to code it up has said so.)

Conditional logging in apache is very flexible, but probably more
complicated than it need be. In my ideal world, you would be able to do
conditional logging based on any of the % directives specified in
LogFormat (including the request method). But again, many developers see
this as a low priority, since most web admins want a complete log file and
can do any necessary processing after-the-fact.

Joshua.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 22:43:30 UTC
Permalink
Post by Laura Vance
I have an idea that should solve all problems. (yeah, right. ;) )
If your quip was only true! Many would grovel before you.

I like this idea you present. Your idea would be a benefit
for Apache servers.
Post by Laura Vance
What I would propose is to allow a directive in the httpd.conf file that
<methodLogging>
DENY SEARCH etc.
ALLOW ALL
</methodLogging>
If you don't mind searching a newsgroup, rummage around in
alt.apache.configuration. You will discover a lot of people,
including me, tossing ideas back and forth trying to resolve
this request method / logging problem. No solutions but a lot
of great ideas. Well, some solutions. All are either expensive
or require adjunct software.

A solution tried is limiting the string length of an URI
as can be done with other request methods. Disallowed methods,
you cannot limit URI string length; you are garbage clobbered.

Another solution tried is much like your idea, use a limit container.
Post by Laura Vance
or something like that to deny specific request logging and allow all
the others. Since it's been stated that request methods that are not
configured don't actually get "processed", this would just keep them
from showing up in the log. I mean, if they're not processed, there's
no risk of contamination of any kind, right?
A module to manipulate http response for specific request methods
would be viable. A module like this would be adaptable and afford
a wide range of options.
Post by Laura Vance
With that being said, I personally have no reason to stop any methods
from reaching my log, but who's to say that someone just doesn't care
for it.
It is not a matter of preventing logging. This is a matter of
logical "clean" logging. Check your internet resources for
an actual transcript of a WebDav exploit. It is thirty-thousand
to fifty-thousand bytes of repeating "binary" like code. That
garbage is of no value for later analysis. That garbage only
serves to bloat logfiles, to break log parsers, to annoy
and to lead me to rants.

"SEARCH /\x90\x02\xb1\x02\xb1\x02\

I only need to see that much to know it is a WebDav exploit.
There is no need to look at the remaining default eight-thousand
bytes to realize what type of exploit this is.

However, you cannot prevent logging of the default eight-thousand
bytes of garbage. You cannot send a method not allowed message.
You cannot ip block offenders. You cannot do anything but eat it.

That is a bug.


Your method logging syntax is a good idea and I would support
this. It is a method similar to limit and limitexcept which
work well, sometimes, if a core hook is allowed.

A very simple solution is simply to allow string length control
as you can do with other request methods.

Yes, completely blocking logging is not a good idea. It is also
not a good idea to allow eight-thousand bytes of garbage into
your logs, without any control.

Ya know, I could wipe out a server's disk storage in a matter
of an hour or two, by sending WebDav at a rate of one-hundred
per second, which would not trigger a DOS response.

Sure, some will argue the same could be done with post data,
for example. GET, yes, potential. Some are arguing this,
most illogically. Those methods and others can be controlled,
especially by ip blocking. I would challenge any reader to
present a method to control WebDav before sunset here on
the left hand coast.

Should a script kiddie decide to wipe out your disk storage,
what would you do? Nothing. You would eat it. That is what
you would do; you are completely naked and defenseless, unless
you have a thirty-thousand dollar Cisco firewall.

* SNORTS *

Got spare change?


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Ben Chabot
2004-05-17 23:15:02 UTC
Permalink
Post by Purl Gurl
It is not a matter of preventing logging. This is a matter of
logical "clean" logging.
Logical logging is to log all connection attempts.
Post by Purl Gurl
Check your internet resources for
an actual transcript of a WebDav exploit. It is thirty-thousand
to fifty-thousand bytes of repeating "binary" like code. That
garbage is of no value for later analysis. That garbage only
serves to bloat logfiles, to break log parsers, to annoy
and to lead me to rants.
It _is_ of value for later analysis. It's called NOPs and shellcode.
And I assure you it is not just garbage. Like I said, today it doesn't
affect apache. But something might at some point and you won't be
logging it. That will be amusing, trying to figure out what happened
with no logs.
Post by Purl Gurl
"SEARCH /\x90\x02\xb1\x02\xb1\x02\
However, you cannot prevent logging of the default eight-thousand
bytes of garbage. You cannot send a method not allowed message.
You cannot ip block offenders. You cannot do anything but eat it.
That is a bug.
I believe it's been posted at least 3 times how you could solve this, in
the way you are so obstinately ranting about.
Post by Purl Gurl
Yes, completely blocking logging is not a good idea. It is also
not a good idea to allow eight-thousand bytes of garbage into
your logs, without any control.
It's called log filtering, there's your control. Or rotating logs.
(Zipping them up periodically, and keeping a few back entries, deleting
the older ones.)
Post by Purl Gurl
Ya know, I could wipe out a server's disk storage in a matter
of an hour or two, by sending WebDav at a rate of one-hundred
per second, which would not trigger a DOS response.
You certainly could not. You think you can send 100G of data in an
hour? Not only that, like I said, most people rotate their logs, so
once it gets to X size, it is backed up, zipped and the log is cleared.
Once there's X many backups the oldest one is deleted. So I find it
curious as to what your problem is. I guess it's because windows
doesn't come with logrotate? Heh.
Post by Purl Gurl
Should a script kiddie decide to wipe out your disk storage,
what would you do? Nothing. You would eat it. That is what
you would do; you are completely naked and defenseless, unless
you have a thirty-thousand dollar Cisco firewall.
Or you log to another machine via syslogd. Or you have any sort of
firewall.
It doesn't take 30k cisco machine to do the job. As I've said, I
believe snort or any number of things, if upstream, could drop the
packets before they hit apache. And most people would restore from
backup, if their data was lost, not that this is going to cause any data
loss whatsoever.

Man, it is time to leave this list. =)
Been fun folks... get me entertained for a day!
Later!
Ben

P.S. Kira, look up the definition of Ad Hominem arguments. Seriously.
It's embarassing.


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 23:26:05 UTC
Permalink
Ben Chabot wrote:

(snipped)
Post by Ben Chabot
It doesn't take 30k cisco machine to do the job. As I've said, I
believe snort or any number of things
Did I not "SNORT" in my article?

You need to pay attention. Your lack of attention, your lack
of comprehension of what is previously written, shows well.

Perhaps I need to lower my language level as I do for students,
but with great hesitation and annoyance.
Post by Ben Chabot
P.S. Kira, look up the definition of Ad Hominem arguments. Seriously.
It's embarassing.
Your comment is a classic example of Ad Hominem, easily
recognized by this English professor and flim flam artist.

Most ironic, yes?


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Ben Chabot
2004-05-17 23:49:54 UTC
Permalink
Post by Porter, Mark
-----Original Message-----
Sent: Monday, May 17, 2004 7:26 PM
In 1.3.31 OrNot?
You need to pay attention. Your lack of attention, your lack
of comprehension of what is previously written, shows well.
I'm glad to see you really are here to, "present the facts." Your,
"firm and fair demeanor," are well displayed as well as your constant
claims to bring nothing but enlightenment to the rest of us.

Insulting the people trying to explain this problem really does nothing
but further impress the idea on the rest of us that you don't understand
what you're talking about and that you haven't spent enough time reading
anyone's replies as you have not comprehended anything that's been
discussed.
Post by Porter, Mark
Perhaps I need to lower my language level as I do for students,
but with great hesitation and annoyance.
I must be really confused, because I thought you already did that when
you started insulting anyone with a dissenting view.
Post by Porter, Mark
Your comment is a classic example of Ad Hominem, easily
recognized by this English professor and flim flam artist.
ad hom.i.nem adj.

Appealing to personal considerations rather than to logic or reason:
Debaters should avoid ad hominem arguments that question their
opponents' motives.
Post by Porter, Mark
Most ironic, yes?
Only as ironic as your continued misuse of the phrase. :-D

Ben


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Stephen Cook
2004-05-18 03:51:03 UTC
Permalink
Post by Purl Gurl
Your comment is a classic example of Ad Hominem, easily
recognized by this English professor and flim flam artist.
...
Post by Purl Gurl
You need to pay attention. Your lack of attention, your lack
of comprehension of what is previously written, shows well.
???


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-18 02:59:07 UTC
Permalink
Post by Ben Chabot
Post by Purl Gurl
It is not a matter of preventing logging. This is a matter of
logical "clean" logging.
Logical logging is to log all connection attempts.
I did not state to not log connections nor hinted at this.

Please pay attention or resist this temptation to twist
my words into something I did not write.

I very clearly state, "...logical clean logging." Your
twisting of my words into what they are not, is deceit.
Post by Ben Chabot
Post by Purl Gurl
Check your internet resources for
an actual transcript of a WebDav exploit. It is thirty-thousand
to fifty-thousand bytes of repeating "binary" like code. That
garbage is of no value for later analysis. That garbage only
serves to bloat logfiles, to break log parsers, to annoy
and to lead me to rants.
It _is_ of value for later analysis. It's called NOPs and shellcode.
And I assure you it is not just garbage. Like I said, today it doesn't
affect apache. But something might at some point and you won't be
logging it. That will be amusing, trying to figure out what happened
with no logs.
I did not state to not log connection requests. This is twice
now you have written this. This prompts me to hold an opinion
you are deliberately practicing deceit. That is inappropriate.

You are not thinking clearly. If a request method exceeds the
set URI length limit, Apache will return a 414 error and there
is absolutely nothing you can do about this. So, if a 414 error
is generated, no hack will be successful. However, your log file
is slobbered with kilobytes of garbage.

Yes, it is garbage. With a 414 response their is no need for
analysis, the data is useless; garbage. It may be of some
entertainment value, might disclose a new exploit but you
will never be able to address whatever is found; 414.
Once Apache cops a 414 error, you are out of the loop.

Doesn't matter if someone sends an extremely long secret
code to the location of Long John Silver's hidden treasure,
you are out of the loop; you cannot respond. Apache will not
allow you to respond.

So you discover a new exploit which turns your Linux
box into a Commodore. What are you going to do? Nada,
zippo, zero, nothing because Apache cops a 414.

Give thought to your words before writing.

With SNORT, this WebDav exploit is fingerprinted using
a depth setting of eight characters and can actually be
fingerprinted in seven characters. Your SNORT reacts,
if you have your rule set for react:block and you never
see the exploit at all; the connection is dropped, this
is, you won't see it in an Apache log.

Using your logic, now SNORT is useless as are firmware
appliances which employ SNORT as an IDS.

So which is it? Am I the blithering idiot for wanting
to capture WebDav, truncate the data and form a response
to deal with it or are high end technogeeks, like those
who developed SNORT or those who manufacture expensive
firewall appliances, are they idiots for not allowing
a capture of exploit data? SNORT and firmware do have
configuration settings for, no log, fast log, packet
log and many other options. You can choose to not log
at all or discard data. A serious blunder, you think?

Apache allows lots of nice parsing of incoming data
which does make it in. You can select to record all
data, disregard host name lookup, record or not record
referer [sic] data, almost anything you like.

So now Apache developers are the idiots for allowing
a user to discard data rather than log every bit of
it for analysis. Your logic is not good.

Your logic is not good because you are performing
a critique of me while deliberately ignoring what
I suggest and would like to do, is very popular
and incorporated by almost all professionals.

Why is this not ok for me but ok all others?

You are not thinking clearly. Not only are you resorting
to a tiresome tactic of word twisting, you are also making
an attempt to critique me for suggesting methods which
are precisely what well known commericial software writers
use most routinely.

So, if I am to be the idiot according to your logic,
then SNORT writers and high end software writers are
the idiots, as well.

What you are really doing is twisting my words around,
employing deceit, concealing known methods, using very
poor logic, to afford yourself a chance to critique.

I am here to share information, to learn, to make suggestions
which might help Apache become a better server.

Why are you here? A rhetorical question begging no answer.

I am very dismayed by this lack of professionalism displayed
by a select few here. I am dismayed because you select few
tend to ruin this mailing list, just as others ruin newsgroups
by engaging in the same or similar inappropriate behavior.

Some readers have shared valuable thoughts and input.
Consider not discouraging those few gentle and polite
participants from joining in, by personal attacks.

I do hope, you the reader, plural, will give thought
to my writings and assess if ad hominem behavior is
beneficial for this mailing list.

Moving back on topic, for those actually interested,
last night I looked at source code for 1.3.29 which is
significantly different than 1.3.27 version.

Within protocol.c for 1.3.27 version, I have discovered
potential for crafting a custom Apache server which
handles a 414 error quite differently. Version 1.3.27
affords a lot of code entry points for white hat hacks.

Changing the wording of a 414 response takes only a
minute, not counting compilation time and copying
in new compiled files.

There is also potential for changing the precedence
order of a 414 error, moving it into an allowed status
enabling an ability to capture WebDav, then work with
it and craft a custom response. A word of caution.
There is a need to defeat URI length to allow this.
Doesn't matter, the data is already in a buffer, it
is there so defeating URI length has no effect on
system resource usage.

A reader might find entertainment is looking at
http_protocol.c from line 2868 downward, or
"CHARSET_EBCDIC" downward, version 1.3.27 tarball.

There is lot of potential there for hooking using
Apache's core export feature. I do find a number
of entry points for direct module hooking, as well.


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Ben Chabot
2004-05-18 06:05:44 UTC
Permalink
Post by Purl Gurl
With SNORT, this WebDav exploit is fingerprinted using
a depth setting of eight characters and can actually be
fingerprinted in seven characters. Your SNORT reacts,
if you have your rule set for react:block and you never
see the exploit at all; the connection is dropped, this
is, you won't see it in an Apache log.
Why don't you just do that then and quit complaining?
Post by Purl Gurl
Using your logic, now SNORT is useless as are firmware
appliances which employ SNORT as an IDS.
Is Apache an IDS?


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-18 13:02:51 UTC
Permalink
Ben Chabot wrote:

(snipped)
Post by Ben Chabot
Post by Purl Gurl
With SNORT, this WebDav exploit is fingerprinted using
a depth setting of eight characters and can actually be
fingerprinted in seven characters. Your SNORT reacts,
if you have your rule set for react:block and you never
see the exploit at all; the connection is dropped, this
is, you won't see it in an Apache log.
Why don't you just do that then and quit complaining?
I have previously discussed SNORT. Pay attention
and stop complaining. Research, read and learn about
SNORT. Although an impressive bit of code, SNORT is
passive and may or may not block transactions along
with being highly platform dependent.

Do you have suggestions for a viable solution for this
lack of an ability to hook some request methods?
Post by Ben Chabot
Post by Purl Gurl
Using your logic, now SNORT is useless as are firmware
appliances which employ SNORT as an IDS.
Is Apache an IDS?
Yes, very much so. Research, read and learn about Apache's
ability to filter incoming transactions then craft an
appropriate response. Apache has wonderful default features
and custom features allowing significant intrusion detection.

You will benefit by researching and reading about a nice
collection of Apache modules which are dedicated solely to
security needs.

Should you look around, should you research, should you
learn, you will discover I have been working on this
Apache WebDav bug for many months, through many different
sources, and just recently presented this problem here.

None of this is new to me. All of this is exceptionally
familiar to me. Specific to this topic, you are a newbie.
Nonetheless, even a newbie may offer a brilliant idea
no others considered. I am looking for solutions not
typical newsgroup acrimonious banter.


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Robert Andersson
2004-05-18 09:49:39 UTC
Permalink
Post by Purl Gurl
Should a script kiddie decide to wipe out your disk storage,
what would you do?
A general advice: do never put your log files on your system partition.

Logging can always eat up disk space, therefor you should configure your box
so it still will run even if the logs cannot be written. This is generally
why we have /var on its own partition.

Regards,
Robert Andersson


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 18:12:27 UTC
Permalink
Tim Thorburn wrote:

(snipped)
Post by Tim Thorburn
Ok, impartial observer here ... I'm on this list because I'm a web designer
who uses Apache for hosting and local testing, not a sysadmin or someone
who makes their living off of the goodness that is Apache. So far, I'm
seeing someone present a problem that she feels is a problem, and then be
ignored or ridiculed for thinking this is a problem.
Personally, I've asked several questions on this list and other similar
lists wherein those who know (or in many cases those who *think* they know)
dismiss any question to their ways as absurd remarks from those who should
not speak. Now, I'll be the first to admit I'm far from an expert in many
areas, but when a person is publicly chewed out as Kira has been in this
case ... it imposes something of an elitist view over the entire Apache
community - don't you dare ask a question lest we mock you for wasting our
time in asking this question.
Very typical behavior you describe!

Many of us have been dealing with the less-than-educated for
literally decades, here on the net. Amuses me to know some of
us have been programming, have been involved with the net, for
more years than some are old.

Cabal Syndrome. Sadly there are those whose only life is a
mailing list, a newsgroup, a forum, programming, whatever.
Once involved, some develop exaggerated self-importance
and believe they are in total charge; a cabal boss.
This is sad because other realize those people truly
have no life, no outside interest, no potential to be
really successful in life, to really enjoy life.

I have two internet stalkers. One faced criminal charges
and restraining orders. Both have been stalking our family
since 1995, on the net, and in "real life." As I write this,
one of them is trying to figure out how to hack our server,
which delights me. This delights me because I am robbing him
of precious time out of his life, with no effort.

Same applies to mailing lists and forums like this. Some
will waste their time, and waste time of readers, through
satuation of their need to feel in control of others. They
would do better to learn to control themselves, not others.

Your thoughts are appreciated by many readers. Almost all
appreciate those who work at bringing logic, intelligence
and goodwill to forums like this.

Easy enough to ignore those who do not appreciate efforts
such as yours. Easy enough to pity those without a life.

Sometimes people mistake my firm but fair demeanor for
being abrasive. Some are not accustomed to those who
are assertive, yet dimplomatic. Some live a fantasy.

Eventually, some will realize these problems I present
are bugs, are problems and need to be addressed. In time,
viable solutions will be offered, after the cabal bosses
finish displaying their true colors, much to my personal
humor and personal entertainment.

Solutions will come forth. All will benefit. Cabal bosses
will be embarrassed. That's reality!


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
John
2004-05-17 16:23:16 UTC
Permalink
Hello everyone,

This is my first post to this list.

I've stayed on the sideline of this issue, but since I'm about to commission
a server running webDAV. Redhat 7.3 + Updates & Apache 1.3.29 or 2.0.49
Post by Porter, Mark
-----Original Message-----
Sent: Monday, May 17, 2004 8:50 AM
Not?
[Snip]
Post by Porter, Mark
This WebDav bug, I have doubts Apache will ever address
this bug. It is a bug because Apache allows "any" request
method, and should not. Request methods should be limited
to only those actually in use. Other supporting evidence
for this being a bug is ip blocking is disabled for
request methods; Apache hooks this before ip blocking.
Additionally, Apache writes the WebDav garbage to a
log file and does not allow an administrator to parse
before it is written.
In short, WebDav script kiddies have complete control
over Apache. This is inexcusable.
Why this is inexcusable is WebDav idiots can send in this
hack at a rate of one per second, around the clock, and
suffer no consequences. Requests at one per second is not
a sufficient rate to kick in preventative denial of service
functions. A script kiddie can pump log records at a rate
of eight kilobytes per second, with no effort. Apache
claims this is not a problem. I strongly disagree.
The idea of filling up a log file is not new, but trying to resolve the
issue as a logging issue is like polishing deck chairs on the titanic.

A better solution would be to make some sort of mod_IDS to check for
attempted hacks of any form, and then drop the connection. An easy way to
spot a script kiddy is change the server signature to an IIS 5 webserver,
then detect any number of hacks for FP extensions, which don't affect
apache.

[Snip]
Post by Porter, Mark
Based on my reading of limited comments in Apache source
files, it is possible to hook within Apache's frontend,
specifically in the protocol files, however complicated.
I'm thinking it would be possible to implement some sort of 'filter'/'proxy'
to avoid such issues. They have them for Win32/IIS based servers (gee I
wonder why :-) )

What does everyone think of having two different definitions of the website
in the httpd.conf, one on port 80/http the other 8080/http. The 8080
version, with webDAV, only allows access from certain IPs.

This is probably the system I'll be implementing myself, unless someone has
any better ideas.

Cheers!
--John


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 16:36:09 UTC
Permalink
(snipped)
Request methods should be limited to only those actually in use.
True problem here is Apache does not allow hooking in a
module to address those request methods which are handled
by Apache's frontend, well before administrative methods.
Jim, here is another example of this problem with not being
able to limit nor manipulate how request methods are handled.

Although Apache contains coding for cross scripting hacks,
an administrator cannot limit a TRACE method, much like HEAD
and other methods, speicifically a SEARCH (WebDav) method.

HEAD can be addressed through mod_security, a wonderful module.
TRACE, SEARCH and CONNECT, others, cannot.

Use of limit and limitexcept, neither can hook Apache frontend.
This leaves Apache wide open for abuse through future hacks.
Sadly, neither your crystal ball nor mine, work well. Most
exasperating, is knowing nothing, currently, can be done
about potential hacks and no modules are available which
have the potential to address future hacks.

TRACE method, this cannot be disabled. Professional level
server surveys will almost always report back TRACE as a
significant vulnerability. With Apache, this is not such
a problem, but could become a serious one, if a crystal
ball is correct in forecasting, "The future is unknown."

This is a short easy to read article on the TRACE method
for those who would like to learn more.

http://archives.neohapsis.com/archives/vulnwatch/2003-q1/0035.html


In closing, Apache needs to allow an easy method of hooking into
the Apache frontend for administrative intervention. This could
be accomplished by use of well written modules. As of this writing,
I have yet to find any modules for this function. All modules I have
found, hook well after the connection and protocol phases.

Taking a proactive stance, is most prudent. Once the horse is out,
closing the barn doors is useless. Software which contains bugs
which render usage impossible is, in fact, useless software.

Apache is not useless but a few select versions, are useless.

My hope is some will be inspired to address these issues, as
I am inspired, and will afford useful information, possibly
some cures, which will benefit all. Apache is the best server
software, but has room for improvement.

Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Robert Andersson
2004-05-17 17:27:31 UTC
Permalink
Post by Purl Gurl
Taking a proactive stance, is most prudent. Once the horse is out,
closing the barn doors is useless. Software which contains bugs
which render usage impossible is, in fact, useless software.
Just noting something that might be a cause for confusion:
Missing feature != bug

A bug is when the software doesn't behave as it is supposed to. Most of your
complaints, except the socket closure issue (of which I am not familiar),
are about lack of convinience features which you would like to have.

To my limited knowledge, Apache 1.3 is not developed anymore, almost only
severe (security) bugs are fixed, so you won't see new features there. Look
to Apache 2.0 or 2.1 for new features; that's where development is
happening.

Regards,
Robert Andersson


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Joshua Slive
1970-01-01 00:00:00 UTC
Permalink
[This is definitely a thread to ignore for anyone interested in solid
information.]
Post by Purl Gurl
Although Apache contains coding for cross scripting hacks,
an administrator cannot limit a TRACE method, much like HEAD
and other methods, speicifically a SEARCH (WebDav) method.
Wrong again.

TRACE cannot be restricted with <Limit> but can be restricted with
mod_rewrite. And in any case, there is no real TRACE vulnerability. See:
http://www.apacheweek.com/issues/03-01-24#news

In <Limit> sections, HEAD is implied by GET (which is necessary to
maintain standards compliance) and SEARCH can certainly be limitted.
Post by Purl Gurl
Use of limit and limitexcept, neither can hook Apache frontend.
This leaves Apache wide open for abuse through future hacks.
I have explained this to you before, but let's try again: It is true that
some requests (malformed requests, in particular) are rejected early in
the process, and therefore are not affected by <Limit>. But even if they
where, the action of
<Limit SEARCH>
Deny from all
</Limit>
Would give you exactly the same effect as what ordinarily happens with
those requests: A rejection response is sent to the client and the request
is logged. The only thing that might change is the status code of the
response.

What you seem to want is for apache to scan incoming requests for a
string, and simply drop the connection if it sees something you don't
like. Apache doesn't do that. It is an http server, and it responds to
http requests with http responses. This is necessary for proper error
handling at the client level: how is a client supposed to know if SEARCH
isn't allowed, or if the network went down? By reading the server's HTTP
response.

And again, as you've been told before, if you want something that simply
cuts off the connection, then what you want is a firewall, not an HTTP
server.

Joshua.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 18:27:22 UTC
Permalink
Post by Joshua Slive
[This is definitely a thread to ignore for anyone interested in solid
information.]
Your constant insulting the intelligence of readers, here and
elsewhere, does not enhance your credibility. Joshua, use of
Ad Hominem is a clear earmark of ignorance. I am certain you
would rather readers not assess you as an ignorant person.
(snipped, context deliberately removed by Sliva)
Post by Joshua Slive
Post by Purl Gurl
Although Apache contains coding for cross scripting hacks,
an administrator cannot limit a TRACE method, much like HEAD
and other methods, speicifically a SEARCH (WebDav) method.
Wrong again.
TRACE cannot be restricted with <Limit>
That is precisely what I indicated. You declare "WRONG!"
then proceed to verify I am correct.

I will close on that notion, Joshua.


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Brent 'Dax' Royal-Gordon
2004-05-17 20:40:20 UTC
Permalink
Post by Purl Gurl
You have made an admission and I will make one. I am
significantly annoyed Apache allowed this bug into
the latest 1.3.31 version. They knew about it and
elected to not resolve this bug. To find a cure
is relatively simple; what changed between version
1.3.27 and 1.3.28 in handling socket closure? There
in will be discovered the source of this bug.
As a programmer, surely you will realize a few things:

1. Seemingly "simple" bugs sometimes aren't. For all we know, the
changes between 1.3.27 and 1.3.28 brought out a subtle bug elsewhere in
Apache.

2. A bug on a relatively minor platform for Apache[1] that fills up log
files is a fairly low-priority issue. Bugs on more common platforms
with more severe effects have to be fixed first.

3. This bug may have just been forgotten. A program as big as Apache
certainly has a lot of problems that need to be investigated, and
missing this one may have been an honest mistake.

Some projects have a policy of "no known bugs in a release". To my
knowledge, Apache does not have such a policy.
Post by Purl Gurl
This WebDav bug, I have doubts Apache will ever address
this bug.
This is not a bug. At worst, it's a missing feature. This is not a
case where Apache is supposed to do something but doesn't--it's one
where Apache doesn't do something you want it to.
Post by Purl Gurl
Why this is inexcusable is WebDav idiots can send in this
hack at a rate of one per second, around the clock, and
suffer no consequences. Requests at one per second is not
a sufficient rate to kick in preventative denial of service
functions. A script kiddie can pump log records at a rate
of eight kilobytes per second, with no effort. Apache
claims this is not a problem. I strongly disagree.
The issue here is that your log files may fill up?

I recommend you do a bit of profiling. Very, very few web servers are
CPU-bound, and most that are host highly dynamic sites. Most sites are
bandwidth-bound; some are I/O-bound.

If you find that the limit on your server's performance is either
bandwidth or I/O, you can solve both of the bugs you complain about by
using a piped log. The only excuse not to pipe your logs into grep -v,
or an equivalent custom program, is that your system is CPU-bound.

There's a saying you may be aware of--"premature optimization is the
root of all evil." I suspect you are trying to optimize your server's
performance without being aware of where your server's performance
problems are. I could be wrong, but I doubt it.


[1] As you know, Apache 1.3 was never designed to run on Windows, and
most Apache servers run Unix. Certainly there are plenty of Windows
systems out there, but
--
Brent "Dax" Royal-Gordon <***@brentdax.com>
Perl and Parrot hacker

Oceania has always been at war with Eastasia.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 21:59:02 UTC
Permalink
Post by Brent 'Dax' Royal-Gordon
Post by Purl Gurl
You have made an admission and I will make one. I am
significantly annoyed Apache allowed this bug into
the latest 1.3.31 version. They knew about it and
elected to not resolve this bug. To find a cure
is relatively simple; what changed between version
1.3.27 and 1.3.28 in handling socket closure? There
in will be discovered the source of this bug.
1. Seemingly "simple" bugs sometimes aren't. For all we know, the
changes between 1.3.27 and 1.3.28 brought out a subtle bug elsewhere in
Apache.
Subtle bugs are always complicated. Curing a bug often leads
to other bugs, much like the Sorcerer's Apprentice chopping
a misbaving broom in two, led to two brooms, to four brooms,
to sixteen brooms....

Looking at changes from 1.3.27 to 1.3.28 seems a logical starting
point for finding this bug; that is where it came about.
Post by Brent 'Dax' Royal-Gordon
3. This bug may have just been forgotten. A program as big as Apache
certainly has a lot of problems that need to be investigated, and
missing this one may have been an honest mistake.
Possibly. I considered this and this is a valid notion. This
is why we take notes and stick them upon our forehead or
pin them to our shirts, yes? I have not ranted about this
bug because there is a possibility all of the developers
simply forgot about it.

There is current discussion of this bug in newsgroups. There
has been discussion of this bug for about a year. Apache
developers participate in those newsgroups. A presumption is
made Apache developers are aware of this bug.
Post by Brent 'Dax' Royal-Gordon
Post by Purl Gurl
This WebDav bug, I have doubts Apache will ever address
this bug.
This is not a bug.
If this appears in one of my programs, I label it a bug.
Bug or not, a problem exists. Argue all you want whether
this is a bug or not. That argument will not resolve
the problem, correct?

Wouldn't you rather discuss possible solutions? Affording
a solution will make Apache an even better server. Is this
not why we discuss, to make improvements?
Post by Brent 'Dax' Royal-Gordon
The issue here is that your log files may fill up?
It is not "may" fill up. They do and others, many others,
are very concerned about this. My opinion is you, like others,
have not given thought to the "snowball" effect of a problem
like this one. This is a very serious problem and has great
potential to become significantly more serious, in the future.

I am not an ostrich. No sand in my eyes. I see clearly.
Post by Brent 'Dax' Royal-Gordon
I recommend you do a bit of profiling. Very, very few web servers are
CPU-bound, and most that are host highly dynamic sites. Most sites are
bandwidth-bound; some are I/O-bound.
Our system resources never fall below eight-five percent available.
I spread out our server and my programs over three machines to
prevent any system resource problems. Routers are wonderful, yes?
Post by Brent 'Dax' Royal-Gordon
If you find that the limit on your server's performance is either
bandwidth or I/O, you can solve both of the bugs you complain about by
using a piped log. The only excuse not to pipe your logs into grep -v,
or an equivalent custom program, is that your system is CPU-bound.
Excuse? I am well known for writing extremely efficient programs
and tossing together extremely efficient systems. Why add a program
as a cure for a problem? Why not fix the problem, instead?

Band-Aid Syndrome.
Post by Brent 'Dax' Royal-Gordon
There's a saying you may be aware of--"premature optimization is the
root of all evil." I suspect you are trying to optimize your server's
performance without being aware of where your server's performance
problems are. I could be wrong, but I doubt it.
You are dead wrong. Now you are aware of this.


(rearranged order here to maintain context - footnotes are annoying)
Post by Brent 'Dax' Royal-Gordon
2. A bug on a relatively minor platform for Apache[1] that fills up log
files is a fairly low-priority issue. Bugs on more common platforms
with more severe effects have to be fixed first.
[1] As you know, Apache 1.3 was never designed to run on Windows, and
most Apache servers run Unix. Certainly there are plenty of Windows
systems out there, but
My guesstimation is ninety to ninety-five percent of machines sold
to average users through common markets, are Windows machines. This
is not a reflection on server machines although Windows is the majority.

You are sending a message to Windows users,

"We couldn't be bothered with you."


Is it logical to send such an offensive message to ninety percent,
or so, of potential Apache customers? Stated earlier, this is
why Bill Gates is filthy rich; he caters to customers openingly,
and does what he wants, privately. He knows when to open his
mouth, and when to keep his mouth shut.

Linux and Apache are great systems. Do those systems appeal
to the vast majority of money out there? No, absolutely not.
This is why Linux Personal is no more, and both Windows and
IIS are wildly popular with people. Bill Gates is great at
public relations and advertisement. Unix, Linux, Apache, BSD,
others, are stuck in an attitude rut and remain richly poor
because of fighting operating system wars with Gates, who
swats his opponents down like flies, with a flick of a finger.

I like Linux. I like Apache. I like Windows. Is that so wrong?


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Robert Andersson
2004-05-18 10:06:17 UTC
Permalink
Post by Purl Gurl
Post by Brent 'Dax' Royal-Gordon
[1] As you know, Apache 1.3 was never designed to run on Windows,
and most Apache servers run Unix. Certainly there are plenty of
Windows systems out there, but
My guesstimation is ninety to ninety-five percent of machines sold
to average users through common markets, are Windows machines. This
is not a reflection on server machines although Windows is the majority.
You are sending a message to Windows users,
"We couldn't be bothered with you."
Apache 1.3 is more-or-less "retro-fitted" for Windows. Windows users should
use Apache 2.0; it performs much better on Windows than Apache 1.3.
Post by Purl Gurl
Is it logical to send such an offensive message to ninety percent,
or so, of potential Apache customers? Stated earlier, this is
why Bill Gates is filthy rich; he caters to customers openingly,
and does what he wants, privately.
Windows/IIS is a comercial product. Microsoft will implement features if the
customers are willing to pay for them; regardless if the features are useful
or not. This is not how Apache works. Apache developers will implement
features they believe to be useful; no more, no less. That is also why
Apache is a better product and suffer less serious bugs.

It is also about priority. I (and many others, I daresay) much rather have a
fully functioning mod_perchild than this logging control feature, which
there are many simple solutions around.

Regards,
Robert Andersson


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-18 13:28:32 UTC
Permalink
(snipped)
Post by Robert Andersson
Post by Purl Gurl
You are sending a message to Windows users,
"We couldn't be bothered with you."
Apache 1.3 is more-or-less "retro-fitted" for Windows. Windows users should
use Apache 2.0; it performs much better on Windows than Apache 1.3.
Yes and no. Of the two, Apache 1.3.x is the more stable, more dependable
version, and in my estimation, is the version which should be used
for high traffic commercial servers.

Apache 2.x is very nice, is a good start on being more compatible with
NT5 type machines. However, being a fairly new release, Apache 2.x is
still buggy and still has stability problems.

I have exhaustively tested both versions and elected to stay
with Apache 1.3.x for stability and a greater number of options.
Post by Robert Andersson
Windows/IIS is a comercial product. Microsoft will implement features if the
customers are willing to pay for them; regardless if the features are useful
or not. This is not how Apache works. Apache developers will implement
features they believe to be useful; no more, no less. That is also why
Apache is a better product and suffer less serious bugs.
An overall viewpoint, yes, Apache is significantly better than
Windows based IIS servers. However, a reader should keep in mind
each system, IIS and Apache, each have strong points and each
have weak points. Which to use is often judged upon needs.

My previous point is Apache simply must appeal to Windows users
if Apache is to grab a larger share of the server market. Apache
is doing a very good job already at holding a large market share,
but more recently, has slipped and is beginning to fall behind.

You commented Apache is less buggy. This is true. Windows IIS is
more buggy, as you allude in your comment about adding a lot of
features to attract customers. Most know, more features lead to
more bugs. This is inherent. Apache 2.x is more buggy than earlier
Apache 1.3.x for the same reason and is the most buggy release
of Apache to date simply because it is in development and these
efforts at adding more features, also add more bugs.

Somewhat off topic, Apache developers, like Perl, Unix, Linux,
BSD and other developers, have little experience with Windows.
My experience is, especially with Apache and Perl, developers
write in bugs which are a direct result of their lack of
experience with Windows systems. This lack of experience is
directly contributable to technological bigotry which is
very frequently observed through operating system wars.

Apache and Perl, both need to attract more Windows specialists
if their respective futures are to be viable. Both also need
to retain and add features which are Windows specific.

Indigo Perl and ActiveState Perl, both have accomplished this,
attracting Windows specialists and users, evidenced by their
wonderful Windows based packages. Linux got off to a good start
on Windows based packages but failed to follow through. Redhat
dropping their Personal edition is a result. Redhat is now a
subscription based software which I believe will eventually
prove to not be a viable market. Chances are good Redhat
will eventually become true vaporware.

Apache has yet to achieve the status of those two companies,
Indigo Perl and Activestate.

Apache developers would be wise to apply as much effort
upon Windows based Apache as they do Unix based Apache.

Stock markets open in a few minutes. I am off to my usual
day trading and making or losing bucks. Money is what it
is all about. Apache should give that some thought.

Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Robert Andersson
2004-05-18 13:47:10 UTC
Permalink
Post by Purl Gurl
Post by Robert Andersson
Apache 1.3 is more-or-less "retro-fitted" for Windows. Windows
users should use Apache 2.0; it performs much better on Windows
than Apache 1.3.
Yes and no. Of the two, Apache 1.3.x is the more stable, more
dependable version, and in my estimation, is the version which should
be used for high traffic commercial servers.
I disagree. Apache 1.3 is more stable than 2.0 in *nix environment, but not
in Windows. You should probably not run Apache 1.3/Windows for "high traffic
commercial" servers at all.
Post by Purl Gurl
Apache 2.x is very nice, is a good start on being more compatible with
NT5 type machines. However, being a fairly new release, Apache 2.x is
still buggy and still has stability problems.
I have had Apache 2.0 on Windows NT5 in production environments for some 3
years without any significant problems.

In my opinion, Apache 2.0.3x+ is as stable is it have to be.
Post by Purl Gurl
I have exhaustively tested both versions and elected to stay
with Apache 1.3.x for stability and a greater number of options.
What problems have you experienced with Apache 2? The only drawback is lack
of modules.

It actually annoys me somewhat that so many unnecessarily stick with Apache
1.3 even when there is no reason to (not saying you don't have a reason).
More should take the step and upgrade to Apache 2, and we will get more
modules ported, more bugs ironed out, and progress will follow. Apache 1.3
is not being developed anymore, no more features will be added. In that
sense it is already dead. (someone more in-the-know correct me if I'm wrong)

Regards,
Robert Andersson


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Heinrich C. Kuhn
2004-05-18 14:18:26 UTC
Permalink
Post by Purl Gurl
My experience is, especially with Apache and Perl, developers
write in bugs which are a direct result of their lack of
experience with Windows systems.
Before a legend becomes persistent: this may be so in some
cases (which I did not hear about). however: in our experience
here both Apache (generation 2) and Perl do run without problems
on MS-Windows servers. We did use IIS4 for a long time, then
switched to IIS6 (for a *very* short time) and now are using
Apache 2 (experiences as above): IMHO Apache 2 had and has con-
figuration advantages over IIS6 and to all our experience it
is anything but slower than IIS6.
My thanks go to the apache developers for having delivered
a product which (at least in our case) runs better on MS servers
than the competing MS product.

Thus I'd suggest: either document your claims by case studies
or cease to claim that the use of Apache2 on Windows servers
is a bad idea for those who have to use Windows servers.

Best regards

Heinrich C. Kuhn

+---------------------------------------------------------
| Dr. Heinrich C. Kuhn
| Seminar fuer Geistesgeschichte der Renaissance
| Ludwig-Maximilians-Universitaet Muenchen
| D-80539 Muenchen / Ludwigstr. 31/IV
| T.: +49-89-2180 2018, F.: +49-89-2180 2907
| inst. URL: http://www.phil-hum-ren.uni-muenchen.de/
+---------------------------------------------------------


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Don Dugger
2004-05-18 15:24:35 UTC
Permalink
Post by Purl Gurl
An overall viewpoint, yes, Apache is significantly better than
Windows based IIS servers. However, a reader should keep in mind
each system, IIS and Apache, each have strong points and each
have weak points. Which to use is often judged upon needs.
My previous point is Apache simply must appeal to Windows users
if Apache is to grab a larger share of the server market. Apache
is doing a very good job already at holding a large market share,
but more recently, has slipped and is beginning to fall behind.
I think this is *NOT* the case, in fact it's MS that lost 15% of there
market in the last two years.
http://news.netcraft.com/archives/web_server_survey.html

Don 8)

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Jim Jagielski
2004-05-18 13:47:55 UTC
Permalink
Post by Purl Gurl
Post by Brent 'Dax' Royal-Gordon
2. A bug on a relatively minor platform for Apache[1] that fills up log
files is a fairly low-priority issue. Bugs on more common platforms
with more severe effects have to be fixed first.
[1] As you know, Apache 1.3 was never designed to run on Windows, and
most Apache servers run Unix. Certainly there are plenty of Windows
systems out there, but
My guesstimation is ninety to ninety-five percent of machines sold
to average users through common markets, are Windows machines. This
is not a reflection on server machines although Windows is the
majority.
You are sending a message to Windows users,
"We couldn't be bothered with you."
Not at all; instead it's saying "There is a bug in the Windows
code for Apache 1.3. If you are a Windows developer, we would
welcome feedback and patches for that."

If people who are native Windows developers can't be bothered
to do that, where does that leave the majority of Apache
developers who are *not* native Windows people?


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Robert Andersson
2004-05-17 15:06:32 UTC
Permalink
Post by Purl Gurl
Jim, I am adamantly pushing in information and feedback
to Apache, and responses, thus far, have been denial
and in some cases, personal insult.
If so, it might be because your "information" is generally incorrect or
unfounded (based on what I've seen from you lately), and you react with
arrogance when people who really know the issues at hand tell you so.

You claim that Apache's detailed logging is a bug; it might be inconvinient,
but *not* a *bug*.
You claim that releases aren't tested. AFAIK, releases are tested on all
"supported" platforms before going public.
Etc. etc.

You also clearly show that you don't have much knowledge in the area you are
complaining about. Saying something like (paraphrased) "why develop Apache
2, when Apache 1.3 still has bugs?", is pretty ignorant. As I understand it,
Apache 2 was developed from scratch partially for that very reason. Apache
1.x wasn't originally developed to run on Windows, Apache 2 was.

You might want to try to be a bit more humble, and consider that those that
disagrees with your assertions just *might* know something you don't (at
least see it as a possibility). It is that kind of arrogance that can enrage
any otherwise good man.

Regards,
Robert Andersson


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
j***@Keane.com
2004-05-17 14:31:12 UTC
Permalink
Post by Purl Gurl
Jim, I am using your article as an excuse to rant.
I believe it was you, just last week, who said these forums where NOT a
place to rant.

My apologies about replying to two posts, but i'm only posting once....
About Apache being 'completely worthless' so downgrade to 1.3.27? huh?

my 1.3.28/29/31 servers are running fine. The world does not run your
speficic
set up with win32 and webdav. So this bug, if it is one, is most likely
affecting a segment of the community, and is not rendering an excellent
product worthless.

Not that i'm saying it should not be fixed, I actually don't have enough
knowledge of the issue to make a statement there. But stating that entire
branches of code are worthless because of this bug, is a bit much.

I hope you get the support/fix you need, but a newbie reading these posts
in Archive, needs to understand, this prodcut is NOT worthless.

Jeff

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org







---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
CUTMAN ~CW~
2004-05-17 16:07:44 UTC
Permalink
Kira,

Are you looking for a solution to your problem? It doesn't appear that you
are... oh, and many "perfectionists" don't.

-this is not the way to find it.

I'd work on this issue termed as a "bug" and then you won't have "your
issue" of a bad attitude so then the result(bad attitude) is fixed through
inadvertant methods(fixing the "bug").

I can't much appreciate this long list of posting in this thread, and if
fact I've yet to see anything like it.. -it doesn't seem useful at all to
me(though hopefully to many others it would). It appears to me to be a long
list of rhetoric in which the only thing, in the end, that it really
revealed to me is that you are pissed off and venting about it... -and not
apparently doing anything to fix the onset of the situation.

Go ahead, respond to me, flame me, cuss me out.. -whatever. I don't care..
-but you are wasting your time with it(and by the way this is all you'll
hear from me). You want to have that attitude with Joshua yet there's
plenty of us that are not amused in the least bit because we clearly know
how helpful, respectful, and straight-forward Joshua is(as opposed to
deceitful, self-centered, blabbermouthy, and underhanded), but so far, in my
opinion, you have not been any of these things..... so STFUB!

Are you needing a solution to logfile monitoring/manipulation, or one to
download the httpd source code and comment out the irrelevant sections?

I'm no use with logfile monitoring/manipulation, but I do know it should be
pretty easy to modify a few lines of code for now until you could do
something so perfectly.. turn a sprintf() into a strcpy(buf, ""), or comment
out a cout << statement.. -not sure there, but it can't be too hard..
either way, I do hope you find a solution for yourself because the bs can't
be getting you that far..


CUTMAN

ps. after you've fixed the big "bug", then let us know.. thanks. :)

_________________________________________________________________
Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage!
http://join.msn.click-url.com/go/onm00200362ave/direct/01/


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 17:20:35 UTC
Permalink
Post by John
I've stayed on the sideline of this issue, but since I'm about to commission
a server running webDAV. Redhat 7.3 + Updates & Apache 1.3.29 or 2.0.49
John, your Redhat installation has wonderful firewall abilities.

Research and read about iptables, SNORT and related topics. There
is much you can do with Linux. There are limitations, though,
with Linux, but far and few between. Keep in mind, Unix, Linux,
Win32, NT5, all are equally buggy and equally vulnerable.
Post by John
What does everyone think of having two different definitions of the website
in the httpd.conf, one on port 80/http the other 8080/http. The 8080
version, with webDAV, only allows access from certain IPs.
You might benefit by researching virtual servers. Apache has great
abilities to virtual host with a single server, even with a single
static ip address. It is possible you will find virtual serving
to be more efficient than trying to listen to multiple ports.

There are many methods to direct your WebDav traffic to specific
directories and functions. Look at virtual hosting, mod_rewrite
and Apache modules designed specifically for WebDav. There are
lots of modules and software for WebDav which work great with
Apache. Just a matter of looking around.
Post by John
I'm thinking it would be possible to implement some sort of
'filter'/'proxy' to avoid such issues. They have them for
Win32/IIS based servers....
A very nice system, actually. Easy to use, powerful, and displays
some limitations as all operating systems do.


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 17:36:19 UTC
Permalink
(snipped)
Post by John
I'm thinking it would be possible to implement some sort of
'filter'/'proxy' to avoid such issues. They have them for
Win32/IIS based servers....
Incidently, John, Microsoft IIS servers have an ability to
block selected request methods where Apache does not. IIS
servers do have a powerful URL scanning feature, which
includes ipsec ability for vpn tunnels.

This is an entertaining example of Microsoft performing
a better job in programming, than Apache. Microsoft,
however, has a lot of bucks for support.

I find this entertaining because of those who engage in
operating system wars, which is pointless. A win for
Window geeks, a loss for Linux geeks. I don't care either
way; I use whatever software works best for me.

Recently, Bill Gates was fined nearly one-million dollars
for whatever. He will pay that fine with accrued interest
earning on his money, in just a single day.


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
John
2004-05-17 19:51:49 UTC
Permalink
Hi Kira,
Post by Porter, Mark
-----Original Message-----
Sent: Monday, May 17, 2004 10:36 AM
1.3.28/29 Fixed In 1.3.31 Or Not?]
Post by John
I'm thinking it would be possible to implement some sort of
'filter'/'proxy' to avoid such issues. They have them for
Win32/IIS based servers....
Incidently, John, Microsoft IIS servers have an ability to
block selected request methods where Apache does not. IIS
servers do have a powerful URL scanning feature, which
includes ipsec ability for vpn tunnels.
Funny should mention this, I noticed in the following URL they make mention
of different apache versions (1.3.31 is the most current release) That LIMIT
is only available on Apache 2.x
http://www.webdav.org/mod_dav/
Post by Porter, Mark
This is an entertaining example of Microsoft performing
a better job in programming, than Apache. Microsoft,
however, has a lot of bucks for support.
I think URL filtering is available on apache, using mod_rewrite and some
other module. The problem is few people use it unless they have a reason,
e.g. webDAV or FrontPage Extensions.

It's a matter of deciding the priorities and working from there.

There are 100s of examples of security flaws, with mitigating factors. They
are not immediately patched because there are workarounds to reduce risk,
and the programmers have to prioritize.

Cheers!
--John


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
r***@xmission.com
2004-05-17 18:41:02 UTC
Permalink
Joshua, I hate to say this but Purl Gurl has the right of this argument and
so as a long-time fan and follower of this forum (and your knowledgable and
articulate responses). For this reason I am going to reach into my deep
pockets and send Purl Gurl a refund of all that she paid for the Apache
HTTP server so she will have the funds to put in Mr. Bill's pocket.

-----BEGIN FUND TRANSFER -----
Version: Genuine Hard Confederate Currency

/dev/null

-----END FUND TRANSFER -----

There, now don't we all feel better.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 18:53:57 UTC
Permalink
Post by r***@xmission.com
Joshua, I hate to say this but Purl Gurl has the right of this argument and
so as a long-time fan and follower of this forum (and your knowledgable and
articulate responses). For this reason I am going to reach into my deep
pockets and send Purl Gurl a refund of all that she paid for the Apache
HTTP server so she will have the funds to put in Mr. Bill's pocket.
You will find my personal information in our NIC registration,
name, mailing address and all that.

Just drop nothing into an envelope and send it. This will cost
you more than I paid for Apache.

I am not here to argue. As stated in multiple manners, I am
here to discuss and learn. Others clearly do not share those
sentiments of mine. A few do.

Strikes me Apache developers would appreciate constructive criticism.
My belief is efforts are directed at making Apache the best and most
popular webserver, if for any reason, to annoy Mr. Gates.

So far, most, not all, but most of what I have read is excuse
making and ad hominem. Bill Gates does not do this which is
why he is filthy rich.

Apache, in general, would do better to accept constructive criticism,
to better Apache and to make Apache a more commericially attractive
package for those vendors who bundle, such as Dell.

Personally, if I were Dell, I would significantly annoyed to read
Apache developers responding, as some have.

Apache is a professional product. Apache developers should conduct
themselves in a professional manner, as Bill Gates does.

I look forward to receiving your envelope filled with nothing,
much like many of the words written here in this group, are nothing.

I also look forward to reading intelligent informative articles
as a few do provide, much to the benefit of all readers.


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Jim Jagielski
2004-05-17 20:02:06 UTC
Permalink
Post by Purl Gurl
Post by Joshua Slive
TRACE cannot be restricted with <Limit>
That is precisely what I indicated.
There was also MUCH discussion on whether we needed to
even provide some sort of mechanism to disable TRACE.
Our opinion was that the vulnerability was not in
TRACE at all, but in the other (required) mechanisms
to exploit that particular path. Without TRACE, there
are still very similar exploitable paths.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 20:59:09 UTC
Permalink
Post by Jim Jagielski
Post by Purl Gurl
Post by Joshua Slive
TRACE cannot be restricted with <Limit>
That is precisely what I indicated.
There was also MUCH discussion on whether we needed to
even provide some sort of mechanism to disable TRACE.
Our opinion was that the vulnerability was not in
TRACE at all, but in the other (required) mechanisms
to exploit that particular path. Without TRACE, there
are still very similar exploitable paths.
This is why I commented TRACE is not a problem for Apache.

Reading of source files yields some mechanisms to protect
against cross site scripting. If I recall correctly, these
are mechanisms which use lookup features, I believe
double reverse lookups to ensure host validity.

TRACE is used as example of this problem of not being
able to hook into Apache's frontend, just as I used
HEAD, SEARCH, whatever. TRACE is still an issue under
debate and it is still unclear if this is a major threat.
Although debated, a person would be exceptionally foolish
to completely dismiss TRACE as a possible exploit, just
as Microsoft dismissed many "things" as non-issues only
to be very surprised, such as the Code Red Worm which
slammed all of us with garbage in our log files. This
one, Red Worm, can be captured and dealt with, however.

Most will cuss when reminded of the SWEN32 virus. If like
us, others experienced tens of thousands of email server
hits because of that spamming virus.

Both of those are classic examples of how we can be
caught with our "pants down" just as WebDav has done.
I am directing my efforts at convincing Apache developers
to not be caught with their pants down, in the future.
Apache is not Microsoft. Apache is much better.

As you know, Jim, there will always be exploits. Variations
on old exploits, new exploits, surprises, this we expect
and does make for a strong market for security devices,
both firmware and software, and makes for us having to
pull our pants back up. That is embarrassing.

This WebDav exploit is a classic example of a surprise
and has brought to our attention a bug in Apache which
previously was not known. Many hold a mistaken notion
a bug is not such unless it is immediately apparent.
This is rarely the case. Murphy's Law has it a bug will
not be discovered until the worst possible time, usually
after software has been marketed to millions of customers.
Microsoft well supports Murphy and bugs.

A bug isn't such until it is discovered. Some may elect
to dogmatically claim a bug is not. Nonetheless, the
problem still exists, bug or not. Claiming a bug is
not will not make a problem vanish.

My personal opinion is Apache needs a hook method to
allow administrators to control results of request
methods. This is a serious need and it is a serious
problem which needs to be resolved. I am not suggesting
dropping a connection, although that would be nice, nor
am I suggesting not responding with a correct http
error message. I am suggesting we need control over
the process to customize responses and to customize
what is logged; get rid of the eight-thousand bytes
of useless garbage. Microsoft does this. So should
an Apache server.

In the case of this annoying WebDav exploit, we only
need an ability to accomplish two things. First is
an ability to instruct Apache to limit the length
of the request URI for logging. We can do this with
other request methods, but not WebDav. Second "thing"
is an ability to block ip addresses BEFORE Apache
responds with an error message and logs, as is the
case with WebDav. Use of ip blocking should be global,
should take precedence over all other functions.

For WebDav, we cannot block the offending ip address
and we cannot parse log data before being written.
Those using Apache are completely defenseless against
this WebDav exploit. That really concerns me. What
other exploits will appear? Being defenseless is
exceptionally illogical and not an accepted practice.

Those are very clear bugs recently forced to surface
because of the WebDav exploit.

I am intensely reading and learning about Apache core
files. This is quite the task! For my personal needs,
a stop-gap measure, I plan to mess around with "r"
in the protocol.c file (1.3.x), with a hope of parsing
out the URI garbage, at that point. Later, as I learn
more about Apache core, I will work on a module to
hook into Apache somewhere in the connect and protocol
phases of processing.

A problem I anticipate already, is a need to write
custom include files, then compile Apache. This would
preclude a widespread fix for all Apache users. Many
want a solution, but few have nor can afford Microsoft
C++ software, specifically version 6 which is now down
to $150 to $180 on Ebay. After purchase, you still have
to spend a lot of time simply learning how to use that
compiler, which is very complicated.

Before someone jumps in about Borland, gcc and others,
for portability, Apache, like Perl, must be compiled
on Microsoft C++ version 5 or version 6.

Bought a lot of Apache books, recently, to supplement
what books I already have and to supplement documentation.
Unfortunately, I have not found any books which discuss
a step-by-step walk through of Apache processing. Best
I have found, so far, is "Maximum Apache Security" by
Anonymous and published under Sams. There is some written
material on core processing and some explanations of
module hooking. However, all of this is AFTER the
connection and protocol phases. I am looking at an
O'Reilly book on writing Apache modules to determine
if the contained information will lead to an ability
to hook into Apache's frontend.

I am looking at Apache::Module to determine if it
will allow "peeking" at frontend processing. Being
an XMS based module, compilation is required for
Win32 systems, presenting some challenges.

An author who writes a technical walk through of Apache
core files, will have a best seller, least in the
Apache community. Trying to trace various headers and
c language include files, is extremely difficult. Took
me several nights to finally find where transaction
data is injected just before logging; protocol.c file.

Mentioned before, my hope is a reader will have addressed
this problem already and be able to offer information, if
not a solution, for all readers. This WebDave exploit is
frequently a hot topic for discussion, and there are many
looking for a solution.

If a viable solution can be found for this WebDav exploit,
should a module appear allowing hooking into the frontend,
this will be very proactive by allowing a facility to deal
with future exploits of this nature. This is dire need.

Microsoft IIS, which I will never use, does have this
feature. Apache needs this as well.

Jim, thanks for your positive responses. I don't participate
here often, but will share any information developed for
the benefit of all readers.


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Joshua Slive
1970-01-01 00:00:00 UTC
Permalink
Post by Purl Gurl
My personal opinion is Apache needs a hook method to
allow administrators to control results of request
methods.
Apache already has a very comprehensive ability to hook into various
request methods. It is just that, as a defensive measure, apache does not
run the full request processing on certain types of malformed requests
(such as the too-long URI in the IIS webdav exploit), but rejects them
immediately.

If you really want to fully process these requests, here's what you do:
recompile apache with DEFAULT_LIMIT_REQUEST_LINE set to a very high value.
Then you can use apache's normal ErrorDocument/SetEnvIf/CustomLog features
to do what you want with these requests. But this isn't a good idea. It
makes your server more vulnerable rather than less.
Post by Purl Gurl
In the case of this annoying WebDav exploit, we only
need an ability to accomplish two things. First is
an ability to instruct Apache to limit the length
of the request URI for logging. We can do this with
other request methods, but not WebDav. Second "thing"
is an ability to block ip addresses BEFORE Apache
responds with an error message and logs, as is the
case with WebDav. Use of ip blocking should be global,
should take precedence over all other functions.
And what should apache do with the requests if they are blocked by IP? As
we both agree, it shouldn't just be dropping the connection. Hence it
needs to go through regular error processing. But if the request is
malformed, this could be dangerous. This is the reason it is better for
malformed request rejection to come before IP rejection. And this has
nothing to do with webdav. Try a GET request with more than 8192
characters and you'll see the exact same thing.
Post by Purl Gurl
Those using Apache are completely defenseless against
this WebDav exploit.
That language is highly inflamatory. This is not an apache "exploit" in
any reasonable sense of the word. It is simply a case of not being able
to restrict certain requests from appearing in the log. Plus it has
nothing to do with webdav, other than that issue is triggered by an IIS
webdav exploit. You would have the same log problems with any HTTP
method.

As I've said, if your server can't handle the length of these requests,
use LimitRequestLine to reduce the accepted length.

Joshua.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-18 14:55:22 UTC
Permalink
Post by Joshua Slive
Post by Purl Gurl
My personal opinion is Apache needs a hook method to
allow administrators to control results of request
methods.
Apache already has a very comprehensive ability to hook
into various request methods.
Yes, and Apache does not have an ability to hook into
many request methods, some industry standard, some
not yet industry standard.

Apache's ability to hook some request methods does not
excuse it lack of ability to hook other request methods.
Not all request methods nor response codes need to be
hooked. However, disallowed request methods do need
to be hooked, specifically a 414 response.

For request methods which are not allowed, Apache should
return a 405, method not allowed, rather than a 414 error.

For WebDav, the first data to hit is "SEARCH" which is a
disallowed method, next kilobytes of garbage. A disallowed
method should take precedence over URI length.
Post by Joshua Slive
And what should apache do with the requests if they are blocked by IP?
What it currently does; 403 Forbidden. Simple, yes?

Use of ip address blocking should be global and take precedence
over all other transaction functions.

Currently Apache allows some ip address blocking and does not
allow ip blocking when it is really needed. That is a bug.
Post by Joshua Slive
As we both agree, it shouldn't just be dropping the connection.
I would rather drop the connection as do high end firewalls.

When a person is trying to hack my server, I don't care if
they are dropped, left hanging for an hour or if his monitor
blows up in his face, which is what I would like to happen.

Hackers, script kiddies, other idiots of the genre, do not
deserve to have an appropriate http transaction response,
they deserve to have their fingers smashed with a hammer.

Although almost all quality firewalls simply drop a connection,
this is not a need for Apache nor would this be logical for
a webserver environment.
Post by Joshua Slive
Post by Purl Gurl
Those using Apache are completely defenseless against
this WebDav exploit.
That language is highly inflamatory.
My statement is absolute truth and is well documented,
historically and by many different people. You are
aware of intense discussion of this problem by many
people for almost a year.
Post by Joshua Slive
This is not an apache "exploit"
I did not state it is. Do not twist my words into something
which I did not write. This causes me to be hostile.

WedDav does exploit an Apache bug. It is actually
an Apache exploit, and Apache is utterly defenseless.
Perhaps you will feel more comfortable to label this,

"Apache URI Length Exploit."

This will remain an Apache exploit up until an ability
to hook and deal with this, is developed. For now,
Apache remains completely defenseless and vulnerable.


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Joshua Slive
1970-01-01 00:00:00 UTC
Permalink
Ok. Enough of that. I'll let Kira have the last word on the subject.

Let's please move on to other topics.

Kira, if you have suggested patches to the apache source code to address
the problems you are seeing, please take them to the development list.
Otherwise, your opinions are well known, so there is no futher need to
discuss them here.

Joshua.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Robert Andersson
2004-05-18 15:21:45 UTC
Permalink
Post by Purl Gurl
Post by Joshua Slive
This is not an apache "exploit"
I did not state it is. Do not twist my words into something
which I did not write. This causes me to be hostile.
WedDav does exploit an Apache bug.
And what bug might that be? Oh, I forgot, that Apache logs everything
exactly as it is supposed to.
Post by Purl Gurl
It is actually an Apache exploit, and Apache is utterly defenseless.
You did not previously state that it was an exploit, but do now. Good, then
we do not need to "twist your words", and you do not need to be hostile.
Post by Purl Gurl
Perhaps you will feel more comfortable to label this,
"Apache URI Length Exploit."
It may be a minor flaw in Apache's design, which may or may not be handled
better, but hardly an exploit or bug.
Post by Purl Gurl
This will remain an Apache exploit up until an ability
to hook and deal with this, is developed.
Apparently, no Apache developer seems to think this is an important feature
to implement (it is not a bug to fix), nor do I. Such features will not be
implemented in the main branch of Apache 1.3. Your best shot is to develop
support for the hooks of your choice in the experimental Apache 2.1 branch,
and perhaps it will be accepted.
Post by Purl Gurl
For now, Apache remains completely defenseless and vulnerable.
In what way is Apache vulnerable in regards to this? Please do not say that
your logs filling up is a vulnerability, the only way to prevent that is to
take your server offline or stop logging. There are people running servers
generating many gigabytes of logs every day, and they manage it; you can
too.

Regards,
Robert Andersson


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-18 15:33:47 UTC
Permalink
(snipped)
Post by Robert Andersson
It may be a minor flaw in Apache's design, which may or may not be handled
better, but hardly an exploit or bug.
If this will help you to avoid popping a handful
of prozac, I will refer to this as a minor flaw
rather than the bug it is.

Clearly, some progress is being made. You boys have
now moved to, "This is a flaw." Give me time, and
you boys will eventually confess this is a bug.
Post by Robert Andersson
There are people running servers generating many gigabytes of logs
every day, and they manage it; you can too.
Your logic is less than Vulcan. Your thoughts are analogous to,

"Many people are murdered everyday, and they manage it; you can too."

What percentage of those "gigabytes" is data which is logged
and should not be logged? You are engaging in excuse making,
not engaging in problem resolution. Ostrich Syndrome.


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Adam Buglass
2004-05-18 15:58:19 UTC
Permalink
As someone with rather less than in depth knowledge of tomcat and as
someone who usually ignores any kind of hostility (which has been coming
from *BOTH* sides in this thread (although not all posters)) on mailing
lists I promised myself I would never get involved in this one.

However I am sick of this thread filling up my inbox. I don't really
mind the posts which are somewhat hostile but are making a good point, I
don't like them but at least they may be interesting.

There are a couple of points I wanted to raise in relation to what has
been written below - please don't bite my head off, I just wish to
contribute a comment and I have had one hell of a bad day.


First of all - by strict dictionary definition - I don't believe this is
actually a "bug" so to speak. It may or may not be bad design, it may or
may not be an omission because someone forgot about it, it may or may
not be an intentional omission, it may or may not be an omission because
nobody wanted to code it (NOTE: I do not want to get involved in those
minor points and idle speculations that begin "may or may not..."! :-)
).
My understanding of a bug is that the software behaves in a way in which
it was never meant to, it "goes wrong". This "feature" of Apache may be
regarded by some people as a bad design, I don't know enough about it to
know or care. However if it was an intended part of (or omission from)
the software then -technically- it isn't actually a bug. This does not
mean that it is a good idea, again I neither know nor care.

My next point is slightly tongue in cheek (I point this out because I
don't want to upset people are argue with them).....
Post by Purl Gurl
"Many people are murdered everyday, and they manage it; you can too."
Err, No they don't.
In fact I would say that if a person is murdered then by definition they
didn't "manage it" at all.... :-)
Post by Purl Gurl
What percentage of those "gigabytes" is data which is logged
and should not be logged? You are engaging in excuse making,
not engaging in problem resolution. Ostrich Syndrome.
Kira
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
--
Adam Buglass, ><>
The Golden Freeway,
Department of Child Health,
University of Newcastle-upon-Tyne.
Royal Victoria Infirmary.

(0191) 2023062

"Democracy is two wolves and a lamb voting on what to have for lunch.
Liberty is a well-armed lamb contesting the vote."
~Benjamin Franklin, 1759


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Robert Andersson
2004-05-18 20:45:04 UTC
Permalink
Post by Purl Gurl
If this will help you to avoid popping a handful
of prozac, I will refer to this as a minor flaw
rather than the bug it is.
You choose to believe whatever you want.

I am, as most others, now convinced you are a troll, and I will not feed you
anymore. Good bye.

Regards,
Robert Andersson


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-18 16:05:43 UTC
Permalink
Post by Robert Andersson
In what way is Apache vulnerable in regards to this? Please do not say that
your logs filling up is a vulnerability, the only way to prevent that is to
take your server offline or stop logging. There are people running servers
generating many gigabytes of logs every day, and they manage it; you can
too.
I have an idea. Robert, you and I, let's work on a project.

I will send you a copy of the WebDav C executable to load
on your machine. I will preconfigure that executable to
send 30,000 bytes of garbage, once per second, which is
highly typical for WebDav. The program will be configured
to socket connect to Apache dot org, a favorite site.

Incidently, the WebDav program can be programmed to send
any amount of data, even streaming without pause. Whatever
amount of data a server can accept, it can be sent.

Both of us will direct our WebDav programs to Apache dot org
and run those executables non-stop for exactly seven days.

At the end of seven days, between the two of us, we will
have sent 36288000000 bytes of data, that is 36.288 gigabytes.

Apache dot org will not be able to do anything. That garbage
will be logged, they will not be able to block our access.
They are completely defenseless. We are in control of
Apache dot org. We own them.

You suppose Apache dot org might view that event as a
rather serious problem? Maybe they will consider this
a serious problem when they realize there are thousands
of infected machines pounding away at the same servers,
day in and day out, for months?

Wait! There is more. Have you looked at your port 135
and port 445 logs lately? Hits on those ports because
of Webdav are an average ten times the amount of its
socket http protocol hits.

We average, between http, port 135 and 445, well over
two-thousands hits per day, and this is only from one
infected machine. Use to be several dozen infected
machines pounding away. This has been reduced to a
single machine because of my contacting servers, then
advising them of this problem. Even talked to the
vice-president of Charter Communications, along
with his secretary and three technicians, in a
conference call, to educate them on this problem
coming out of Charter. Broadband WebDav!

Reducing this problem to one infected machine took
four months. New machines could appear anytime.

Dealing with ports 135 and 445 is a snap.

Dealing with port 80 is impossible because of Apache.


So, you and I pound at Apache dot org and several other
rogue machines start pounding away. Well darn, our friends
over at Apache are enjoying petabytes of data.

That is a problem, even for Star Trek petabyte drives.

Just imagine, two script kiddies can take down Apache dot org
with nothing more than a click of a mouse button because of
this inherent bug in Apache server software. Yeah, sure,
they can do the same with other methods. However, WebDav
is available to them everywhere, is easy to load, and
requires only a mouse click. Script kiddie Heaven!

Eventually, script kiddies will realize this.


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Robert Andersson
2004-05-18 20:58:20 UTC
Permalink
Ok, I said I wouldn't participate in this anymore, but...
Post by Purl Gurl
Just imagine, two script kiddies can take down Apache dot org
with nothing more than a click of a mouse button because of
this inherent bug in Apache server software.
The point is that we (or others) could not "take down" www.apache.org this
way, assuming they have configured their servers as any sensible
administrator would. We might be able to fuck up their logging, but managing
to fill up their /var partition will not take down their web site. I am also
somewhat certain they are rotating their logs daily, and that they already
grow about the rate you suggested.

It would also be a piece of cake for them to block us in a matter of
minutes; it is not hard to see where the traffic is coming from and simply
drop those packages.

Finally, I have not inclination to mess with the good people at ASF, so I
have to decline your invitation.

Regards,
Robert Andersson


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Purl Gurl
2004-05-17 21:15:15 UTC
Permalink
John wrote:

(snipped)
Post by John
Post by Purl Gurl
Post by John
I'm thinking it would be possible to implement some sort of
'filter'/'proxy' to avoid such issues. They have them for
Win32/IIS based servers....
Incidently, John, Microsoft IIS servers have an ability to
block selected request methods where Apache does not. IIS
servers do have a powerful URL scanning feature, which
includes ipsec ability for vpn tunnels.
Funny should mention this, I noticed in the following URL they make mention
of different apache versions (1.3.31 is the most current release) That LIMIT
is only available on Apache 2.x
http://www.webdav.org/mod_dav/
Version numbers are very confusing! They are referring to Apache
versions which date back several years. Versions 1.3.2 , 1.3.3,
1.3.4 and others in that range, I think date back to 1999 or 2000,
might even date back to 1997.

Don't let version numbering systems confuse you! Version 1.3.31
is much newer than version 1.3.3 as cited.

Limit is available in both 1.3.x series (newer) and 2.x versions.
Post by John
I think URL filtering is available on apache, using mod_rewrite and some
other module. The problem is few people use it unless they have a reason,
e.g. webDAV or FrontPage Extensions.
Yes, Apache affords excellent features for filtering a variety
of data, not just URI data. Apache has moved more towards standard
regular expression engines (regex) much like Perl, making this
even more powerful. Previous versions of Apache offer excellent
filtering and this filtering becomes better with new versions,
and especially new modules. Microsoft has nothing quite like this.

Watch those version numbers, John! They will trick you if they can!


Kira

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Gary Smith
2004-05-18 01:49:04 UTC
Permalink
Can't we all just get along and go troll hunting elsewhere?

Do a search for similar threads on google and you'll find countless threads that are at least a hundred deep.

Gary




---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
j***@Keane.com
2004-05-18 15:39:32 UTC
Permalink
Post by Purl Gurl
Your logic is less than Vulcan. Your thoughts are analogous to,
"Many people are murdered everyday, and they manage it; you can too."
OK, you've gone WAY over the edge!

@@@@@@@@@Please __DO_NOT__ equate the loss of human life to log files
filling up!!!! @@@@@@@@@@@@@@

Can someone let someone have the last word and get on other apache issues.

Can this madness end?

Jeff


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org







---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Jim Jagielski
2004-09-08 14:28:17 UTC
Permalink
./re <tests
Segmentation fault
./re -x <tests
....
Segmentation fault
I'll be happy to give more details and run some tests if necessary.
Core dump stack traces would be most helpful! :)
--
===========================================================================
Jim Jagielski [|] ***@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Jim Jagielski
2004-09-09 20:34:18 UTC
Permalink
http://httpd.apache.org/docs/vhosts/name-based.html
Umm... you can't use name-based vhosting with SSL. It's
an IP based vhost issue.
--
===========================================================================
Jim Jagielski [|] ***@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
James Skinner
2004-09-09 20:43:41 UTC
Permalink
I didn't see your whole post. I understand that you can't use
name-based vhosting with SSL, unless you have a wildcard cert and use
canonicals off of the *.servername.cert.

Whatever. You seem to think you know what you're talking about.
Post by Jim Jagielski
http://httpd.apache.org/docs/vhosts/name-based.html
Umm... you can't use name-based vhosting with SSL. It's
an IP based vhost issue.
--
=======================================================================
====
http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Jim Jagielski
2004-09-09 20:57:53 UTC
Permalink
Post by James Skinner
I didn't see your whole post. I understand that you can't use
name-based vhosting with SSL, unless you have a wildcard cert and use
canonicals off of the *.servername.cert.
Whatever. You seem to think you know what you're talking about.
http://httpd.apache.org/contributors/

Yeah... I "seem to think" I know what I'm talking about.

I wonder why?


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Jim Jagielski
2004-09-09 20:59:08 UTC
Permalink
Post by Jim Jagielski
http://httpd.apache.org/contributors/
Yeah... I "seem to think" I know what I'm talking about.
I wonder why?
Just in case, there should be a few ;) s there

Cheers!

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
Jim Jagielski
2004-11-22 16:09:02 UTC
Permalink
This usually happens when you build httpd with SO support but
don't build mod_status or mod_cache* at the same time (there
are other modules as well which kick this). The issue is that
when you build httpd, you don't hit any code which requires
those func's (due to the double and quad var usage) so that
httpd doesn't require them from libgcc. If you then use
apxs to build mod_status, etc, *those* modules require
that function, which isn't automatically loaded by
httpd.
You can use LoadFile to force httpd to load it in.
LoadFile does indeed remedy this - many thanks.
Is there any way to force those functions from libgcc_s.so to be loaded
into HTTPD?
If you know in advance that you will need them, then building
statically and including mod_status (even as a DSO) works
most of the time (varies with gcc version, however).
--
===========================================================================
Jim Jagielski [|] ***@jaguNET.com [|] http://www.jaguNET.com/
"There 10 types of people: those who read binary and everyone else."

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org
John P. Dodge
2004-11-22 17:43:00 UTC
Permalink
Post by Jim Jagielski
You can use LoadFile to force httpd to load it in.
LoadFile does indeed remedy this - many thanks.
Is there any way to force those functions from libgcc_s.so to be loaded
into HTTPD?
If you know in advance that you will need them, then building
statically and including mod_status (even as a DSO) works
most of the time (varies with gcc version, however).
--
You can re-link mod_ststus and specify the static libgcc.a and it will
suck in all the symbols it needs. This has been discussed on this list
several times.

Find libgcc.a:
/usr/local/bin/gcc -print-libgcc-file-name

cd <apache source dir>/modules/generators

ld -G -o mod_status.so mod_status.lo \
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/libgcc.a

cp mod_status.so /opt/apache/modules/

Same thing sometimes shows up in mod_cache (with a similar fix):

cd <apache source dir>/modules/experimental

ld -G -o mod_cache.so mod_cache.lo \
cache_storage.lo \
cache_util.lo \
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/libgcc.a

cp mod_cache.so /opt/apache/modules/


----------------------------------------
"Mon a=E9roglisseur est plein d'anguilles"
John P. Dodge
Boeing Shared Services


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-***@httpd.apache.org
" from the digest: users-digest-***@httpd.apache.org
For additional commands, e-mail: users-***@httpd.apache.org

Continue reading on narkive:
Loading...