On Mon, 26 Jan 2004, Aaron Bannert wrote:
> I think one should have to change the source code in order to
> have this level of control over the Server: header.
I strongly agree.
--Cliff
On Tue, Jan 13, 2004 at 02:04:06PM +, Ivan Ristic wrote:
> Jim Jagielski wrote:
>
> >I'd like to get some sort of feedback concerning the idea
> >of having ServerTokens not only "adjust" what Apache
> >sends in the Server header, but also allow the directive
> >to fully set that info.
> >
> >F
> It's from various admins, using open source and commercial
> versions of Apache that I've rec'd the "request" from. One
> request from an admin was to make it *easier* to audit his
> network, by allowing each machine to have a slightly different
> "real" name.
So add an individual X-Server-Ident
On Tue, Jan 13, 2004 at 09:35:15AM -0500, Jim Jagielski wrote:
> I didn't propose this to create (yet another) heated discussion,
> simply to suggest that we take ServerTokens to its logical
> conclusion based on some requests I've seen. :)
Yes. I agree with Lars that "security by obscurity" is no
On Tue, Jan 13, 2004 at 03:28:24PM +, Ivan Ristic wrote:
> Also, imagine I have a PHP application (I chose PHP because
> it runs on Windows and on Unix), and that someone is trying
> to find a hole in the app. If they think I'm running Windows
> they'll try to run Windows-specific attem
I recently changed the signature of the Apache running on
modsecurity.org (to pretend to be IIS5). As a result, I've started
getting more IIS-related attacks than before. So, the signature
does matter.
And what was the security advantage?
Smaller number of attack attempts made specifical
Mads Toftum wrote:
>
> On Tue, Jan 13, 2004 at 09:35:15AM -0500, Jim Jagielski wrote:
> >
> > Without a doubt. Look at how many exploits grep on not only
> > the "name" of the server but also the version.
> >
> So it is ok to be vulnerable - as long as it isn't obvious?
Of course not.
--
==
Lars Eilebrecht wrote:
>
> According to Jim Jagielski:
>
> > I didn't propose this to create (yet another) heated discussion,
>
> too late ;)
>
>
> > simply to suggest that we take ServerTokens to its logical
> > conclusion based on some requests I've seen. :)
>
> Sorry, but I don't see this
On Tue, Jan 13, 2004 at 09:35:15AM -0500, Jim Jagielski wrote:
>
> Without a doubt. Look at how many exploits grep on not only
> the "name" of the server but also the version.
>
So it is ok to be vulnerable - as long as it isn't obvious?
I must say that I don't buy that argument - it will just l
According to Jim Jagielski:
> I didn't propose this to create (yet another) heated discussion,
too late ;)
> simply to suggest that we take ServerTokens to its logical
> conclusion based on some requests I've seen. :)
Sorry, but I don't see this as the logical conclusion of
the ServerTokens di
* On Tue, Jan 13, 2004 at 02:25:36PM +, Ivan Ristic wrote:
> Because I believe that changing the signature prevents some
> automated tools from attacking the server.
This is a valid point.
> I recently changed the signature of the Apache running on
> modsecurity.org (to pretend to be
According to Ivan Ristic:
> I recently changed the signature of the Apache running on
> modsecurity.org (to pretend to be IIS5). As a result, I've started
> getting more IIS-related attacks than before. So, the signature
> does matter.
I'm getting IIS-related attacks on my servers even wi
Ivan Ristic wrote:
>
>
> > As Lars said (and I agree), it has nothing to do with security. Why do you
> > provide such a "feature" then?
>
>Because I believe that changing the signature prevents some
>automated tools from attacking the server.
>
>So, the signature
>does matter.
* Ivan Ristic <[EMAIL PROTECTED]> wrote:
>
> >> I like the idea. Right now you either have to
> >> change the source code or use mod_security to achieve
> >> this, but I think the feature belongs to the server core.
> >>
> >> But I think a new server directive is a better solution.
> >
>
I like the idea. Right now you either have to
change the source code or use mod_security to achieve
this, but I think the feature belongs to the server core.
But I think a new server directive is a better solution.
As Lars said (and I agree), it has nothing to do with security. Why do you
Colm MacCarthaigh wrote:
>
> On Tue, Jan 13, 2004 at 03:04:30PM +0100, Lars Eilebrecht wrote:
> > - It's only security by obscurity and providing such a
> > "security feature" may be misleading for our users.
> > - We don't want people to obfuscate the server name, do we?
>
> It's a terrible te
* Ivan Ristic <[EMAIL PROTECTED]> wrote:
>I like the idea. Right now you either have to
>change the source code or use mod_security to achieve
>this, but I think the feature belongs to the server core.
>
>But I think a new server directive is a better solution.
As Lars said (and
On Tue, Jan 13, 2004 at 08:53:38AM -0500, Jim Jagielski wrote:
> I'd like to get some sort of feedback concerning the idea
> of having ServerTokens not only "adjust" what Apache
> sends in the Server header, but also allow the directive
> to fully set that info.
>
> For example: ServerTokens Set A
On Tue, Jan 13, 2004 at 03:04:30PM +0100, Lars Eilebrecht wrote:
> - It's only security by obscurity and providing such a
> "security feature" may be misleading for our users.
> - We don't want people to obfuscate the server name, do we?
It's a terrible terrible terrible idea, and makes auditing
Jim Jagielski wrote:
I'd like to get some sort of feedback concerning the idea
of having ServerTokens not only "adjust" what Apache
sends in the Server header, but also allow the directive
to fully set that info.
For example: ServerTokens Set Aporche/3.5
would cause Apache to send Aporche/3.5 as t
According to Jim Jagielski:
> I'd like to get some sort of feedback concerning the idea
> of having ServerTokens not only "adjust" what Apache
> sends in the Server header, but also allow the directive
> to fully set that info.
I tend to be -1 on this for the following reasons:
- It's only secur
I'd like to get some sort of feedback concerning the idea
of having ServerTokens not only "adjust" what Apache
sends in the Server header, but also allow the directive
to fully set that info.
For example: ServerTokens Set Aporche/3.5
would cause Apache to send Aporche/3.5 as the
Server header. Some
22 matches
Mail list logo