-Original Message-
From: Daniel Ruggeri Sent: Freitag, 8. Juni 2012 00:16
To: dev@httpd.apache.org
Subject: Re: [PATCH] mod_log_forensic security considerations
On 6/7/2012 3:11 PM, Stefan Fritsch wrote:
On Thursday 07 June 2012, Eric Covener wrote:
On Wed, Jun 6, 2012 at 9
enabled by default and is most likely
to be enabled by a user that knows what they are trying to accomplish.
To me, a clear and concise security warning in the documentation should
be all that is needed.
IMO, having unadulterated logging capability is what makes
mod_dumpio/mod_log_forensic some
- Original Message -
From: Daniel Gruno rum...@cord.dk
To: dev@httpd.apache.org
Cc:
Sent: Friday, June 8, 2012 6:24 AM
Subject: Re: [PATCH] mod_log_forensic security considerations
On 06/08/2012 12:13 PM, Graham Leggett wrote:
On 08 Jun 2012, at 12:16 AM, Daniel Ruggeri wrote
On 06/08/2012 05:45 PM, Joe Schaefer wrote:
Well not quite, we'd still have had a problem with storing and
archiving those logs even if we hadn't made them available to
committers, because they violate our password retention policies.
My point was, that it should fall upon us to add a filter
On 08 Jun 2012, at 5:45 PM, Joe Schaefer wrote:
Well not quite, we'd still have had a problem with storing and archiving
those logs even if we hadn't made them available to committers, because
they violate our password retention policies.
Can you clarify if possible what purpose you were
:
Sent: Friday, June 8, 2012 12:51 PM
Subject: Re: [PATCH] mod_log_forensic security considerations
On 08 Jun 2012, at 5:45 PM, Joe Schaefer wrote:
Well not quite, we'd still have had a problem with storing and
archiving
those logs even if we hadn't made them available to committers
On Jun 8, 2012, at 11:51 AM, Graham Leggett wrote:
On 08 Jun 2012, at 5:45 PM, Joe Schaefer wrote:
Well not quite, we'd still have had a problem with storing and archiving
those logs even if we hadn't made them available to committers, because
they violate our password retention policies.
On 6/8/2012 12:52 PM, Jim Riggs wrote:
Having the forensic logs available has proven extremely helpful in this
scenario. Might the full, unfiltered forensic data be valuable? Yes, but I
don't believe the security risk is worth it in my situation. The rare case
where an Authorization header
On 08 Jun 2012, at 7:22 PM, Joe Schaefer wrote:
For several years Graham those logs were rather valuable
in tracking down segfaulting svn requests. Security releases
were made as a result of some of those reports to the
Subversion project.
I'm sure they were, that's exactly what the
mod_log_forensic as 'just a logging tool' is foolish.
.
IMO they shouldn't be logged by default (if at all).
Proxy-Authorization also needs to be handled. (Anything else? My
search query foo is particularly bad today.)
ANY parsing which occurs within mod_log_forensic is going to open that module
itself to suspicion and potential un-captured
excluding those headers
from being logged, too.
IMO they shouldn't be logged by default (if at all).
Proxy-Authorization also needs to be handled. (Anything else? My
search query foo is particularly bad today.)
ANY parsing which occurs within mod_log_forensic is going to open that module
On Thursday 07 June 2012, Eric Covener wrote:
On Wed, Jun 6, 2012 at 9:15 PM, Jeff Trawick traw...@gmail.com
wrote:
On Wed, Jun 6, 2012 at 3:49 PM, Joe Schaefer
joe_schae...@yahoo.com wrote:
Session cookies sometimes pose a security risk as well.
Yeah. That could be any cookie though
On Thu, Jun 7, 2012 at 4:11 PM, Stefan Fritsch s...@sfritsch.de wrote:
On Thursday 07 June 2012, Eric Covener wrote:
On Wed, Jun 6, 2012 at 9:15 PM, Jeff Trawick traw...@gmail.com
wrote:
On Wed, Jun 6, 2012 at 3:49 PM, Joe Schaefer
joe_schae...@yahoo.com wrote:
Session cookies sometimes
On Jun 7, 2012, at 3:11 PM, Stefan Fritsch wrote:
I share Williams concern that this makes mod_forensic potentially less
useful.
Maybe making the forensic log mode 600 by default would be a better
idea?
I have to agree with Jeff. I would rather have a more difficult or even
impossible
.
To me, a clear and concise security warning in the documentation should
be all that is needed.
IMO, having unadulterated logging capability is what makes
mod_dumpio/mod_log_forensic some of the most useful modules for
troubleshooting in a proxy/crashing scenario (respectively).
--
Daniel Ruggeri
On Tue, May 29, 2012 at 1:36 PM, Daniel Shahaf d...@daniel.shahaf.name wrote:
https://blogs.apache.org/infra/entry/apache_org_incident_report_for
Infra got bit by mod_log_forensic logs including Authorization headers
and being world-readable, so in an effort to save someone else from
Session cookies sometimes pose a security risk as well.
- Original Message -
From: Jeff Trawick traw...@gmail.com
To: d...@httpd.apache.org; dev@httpd.apache.org
Cc:
Sent: Wednesday, June 6, 2012 3:46 PM
Subject: Re: [PATCH] mod_log_forensic security considerations
On Tue, May
Authorization headers, but that it should still
be opt-in.
Thoughts, anyone?
- Original Message -
From: Jeff Trawick traw...@gmail.com
To: d...@httpd.apache.org; dev@httpd.apache.org
Cc:
Sent: Wednesday, June 6, 2012 3:46 PM
Subject: Re: [PATCH] mod_log_forensic security
On Wed, Jun 6, 2012 at 9:15 PM, Jeff Trawick traw...@gmail.com wrote:
On Wed, Jun 6, 2012 at 3:49 PM, Joe Schaefer joe_schae...@yahoo.com wrote:
Session cookies sometimes pose a security risk as well.
Yeah. That could be any cookie though although there are a few very
common defaults :( My
Hi there,
Mod_log_forensic is saving my day while debugging a crashing
apache. But matching the right request with the crash and its
corefile is difficult.
Ideally the log would show me only the active requests
at the moment the server died. But in my case things are a bit
more difficult
On 30 Mar 2011, at 3:23 PM, Christian Folini wrote:
Mod_log_forensic is saving my day while debugging a crashing
apache. But matching the right request with the crash and its
corefile is difficult.
Have you taken a look at Jeff's mod_whatkilledus?
http://people.apache.org/~trawick
timestamp patch for
mod_log_forensic for future convenience.
regs,
Christian
--
Christian Folini - christian.fol...@netnea.com
see patch
Index: src/modules/standard/mod_log_forensic.c
===
--- src/modules/standard/mod_log_forensic.c (revision 122969)
+++ src/modules/standard/mod_log_forensic.c (working copy)
@@ -189,7 +189,8 @@
if (!(id =
* Jeff Trawick wrote:
see patch
[...]
+1.
nd
--
Rätselnd, was ein Anthroposoph mit Unterwerfung zu tun hat...
[...] Dieses Wort gibt so viele Stellen für einen Spelling Flame her, und
Du gönnst einem keine einzige.-- Jean Claude und David Kastrup in dtl
On Dec 21, 2004, at 9:27 AM, Jeff Trawick wrote:
see patch
forensicpatch.txt
+1
Forwarded message:
On Sat, 13 Nov 2004 17:23:34 -0800, Wilson Cheung [EMAIL PROTECTED] wrote:
apache-1.3.33: mod_log_forensic module use of assert() vs. ap_assert()
introduces __eprintf() gcc-ism?
Thanks for the detailed diagnosis. There may not be people on the
users list qualified
Jeff Trawick wrote:
pid_t is long on Solaris
+1
Index: src/modules/standard/mod_log_forensic.c
===
RCS file:
pid_t is long on Solaris
Index: src/modules/standard/mod_log_forensic.c
===
RCS file: /home/cvs/apache-1.3/src/modules/standard/mod_log_forensic.c,v
retrieving revision 1.7
diff -u -r1.7 mod_log_forensic.c
---
this patch fixes compilation on Win32 for me since older SDK has no
unistd.h; and btw. I was also able to compile without unistd.h for NetWare
target without warnings about missing prototypes, so maybe its obsolete at
all
archived as BZ #28572:
Arghh!
sorry, hit the wrong button -- this should go deleted instead of sended!
this patch fixes compilation on Win32 for me since older SDK has no
unistd.h; and btw. I was also able to compile without unistd.h for
NetWare
target without warnings about missing prototypes, so maybe its
Hi,
this patch fixes compilation on Win32 for me since older SDK has no unistd.h; and btw.
I was also able to compile without unistd.h for NetWare target without warnings about
missing prototypes, so maybe its obsolete at all
--- mod_log_forensic.c.orig Sat Feb 21 18:15:20 2004
+++
Jeff Trawick wrote:
2) Get approval to commit to stable branch
(no attempt made IIRC; typical action is to propose a vote in STATUS
file of stable branch and await comments or votes)
Done! Votes please...
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to
.
The Win32 implementation of atomics for 0.9 is apr_atomic.h.
- there needs to be done some apr work before porting mod_log_forensic.
What do you want to happen? Add a new increment API to 0.9 that returns
a value?
There would seem to be several solutions, some with APR dependencies
Ben Laurie wrote:
Jeff Trawick wrote:
We could make the 2.0.x version require mod_unique_id.
that seems very reasonable
solution 4: add some suitable API to APR 0.9 and implement on all
platforms
Surely not returning the value from the inc is broken anyway? And a
harmless change even if you
At 06:49 AM 3/29/2004, Jeff Trawick wrote:
Ben Laurie wrote:
Jeff Trawick wrote:
solution 4: add some suitable API to APR 0.9 and implement on all platforms
Surely not returning the value from the inc is broken anyway? And a harmless change
even if you don't consider it broken?
a) agreed
Let
* Jeff Trawick [EMAIL PROTECTED] wrote:
somehow I doubt there will be any problems at all getting it approved, but
nobody acted as a champion thus far and asked for approval themselves
In fact, I've thought it was by intention, because of the APR 1.0 atomic
calls ;-)
nd
André Malo wrote:
* Jeff Trawick [EMAIL PROTECTED] wrote:
somehow I doubt there will be any problems at all getting it approved, but
nobody acted as a champion thus far and asked for approval themselves
In fact, I've thought it was by intention, because of the APR 1.0 atomic
calls ;-)
the interface of the latter is not thread safe.
Additionally there's no Win32 section in apr/atomic in 0.9.
- there needs to be done some apr work before porting mod_log_forensic.
[cc [EMAIL PROTECTED]
nd
of atomics for 0.9 is apr_atomic.h.
- there needs to be done some apr work before porting mod_log_forensic.
What do you want to happen? Add a new increment API to 0.9 that returns a value?
There would seem to be several solutions, some with APR dependencies and some
without.
solution 1: do what
--On Tuesday, December 30, 2003 3:41 PM + Ben Laurie [EMAIL PROTECTED]
wrote:
For review - or shall I just commit?
I'd say commit to HEAD (aka 2.1) right now. We can deal with merging back
into 2.0 once it has the 3 +1s (which imply it has been reviewed)... -- justin
For review - or shall I just commit?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
/*
42 matches
Mail list logo
