es R wrote:
From: August Kleimo [mailto:aug...@kleimo.com]
Subject: "exception-message" header reveals path to document root in 404
response.
I'm failing a PCI compliance scan because my Tomcat Version 7.0.20 server
is revealing the path to the document web root in an "exc
hink this header
>> is coming from Tomcat.
>>
>> $ curl -I http://mydomain.com/this-page-does-not-exist.html
>>
>> HTTP/1.1 404 Not Found
>> Date: Fri, 10 Jan 2014 23:23:22 GMT
>> Server: Apache-Coyote/1.1
>> exception-message: Page
>> /t
> From: August Kleimo [mailto:aug...@kleimo.com]
> Subject: "exception-message" header reveals path to document root in 404
> response.
> I'm failing a PCI compliance scan because my Tomcat Version 7.0.20 server
> is revealing the path to the document web root in a
header from the response?
Note: I'm running Railo 4.1.2 on top of Tomcat ... but I think this header
is coming from Tomcat.
$ curl -I http://mydomain.com/this-page-does-not-exist.html
HTTP/1.1 404 Not Found
Date: Fri, 10 Jan 2014 23:23:22 GMT
Server: Apache-Coyote/1.1
exception-message: Page
ailo 4.1.2 on top of Tomcat ... but I think this header
is coming from Tomcat.
$ curl -I http://mydomain.com/this-page-does-not-exist.html
HTTP/1.1 404 Not Found
Date: Fri, 10 Jan 2014 23:23:22 GMT
Server: Apache-Coyote/1.1
exception-message: Page
/this-page-does-not-exist.html [/var/www/htm
I tried with 7.0.47 and I still get 404 regardless of the the state of
bindOnInit.
//
On 01/10/2014 01:38 PM, Caldarale, Charles R wrote:
From: Adrian Tarau [mailto:mailingl...@adrian.tarau.org]
Subject: Re: Getting 404 before the container starts all servlets
I tried with bindOnInit=false
> From: Adrian Tarau [mailto:mailingl...@adrian.tarau.org]
> Subject: Re: Getting 404 before the container starts all servlets
> I tried with bindOnInit=false and bindOnInit=true, it makes no
> difference. I'm using tomcat 7.0.34, would this option be available in
> 7
tting 404 before the container starts all servlets
After upgrading Tomcat from 6.X to 7.X, our AJAX client receives 404 for
10-15 seconds right after startup. I presume the request is accepted and
processed before all servlet are initialized, which is not what you
would expect.
Is this behavior normal
> From: Adrian Tarau [mailto:mailingl...@adrian.tarau.org]
> Subject: Getting 404 before the container starts all servlets
> After upgrading Tomcat from 6.X to 7.X, our AJAX client receives 404 for
> 10-15 seconds right after startup. I presume the request is accepted and
> p
Hello,
After upgrading Tomcat from 6.X to 7.X, our AJAX client receives 404 for
10-15 seconds right after startup. I presume the request is accepted and
processed before all servlet are initialized, which is not what you
would expect.
Is this behavior normal for 7.X? Is there a way to
h as a ROOT-app and as a
> MYAPP-webapp-1.0.0.war-file
> Now I have stripped the app down to just a struts2-hello-world-app.
> But at the webhotel I just keep getting this when I try to access the
> ActionClass through struts.xml:
> HTTP Status 404 - There is no Action mapped for na
Hello guys!
I started my tomcat at home with catalina.bat start -security.
During startup I at once got a lot of exceptions, please see this
pastie:http://pastie.org/8499210
When I try to access the webapp I get 404 right away.At the production server I
at least could access the jsp:s direct
> Date: Thu, 21 Nov 2013 17:10:58 +0400
> Subject: Re: 404 - Might there be something wrong with my permissions?
> From: knst.koli...@gmail.com
> To: users@tomcat.apache.org
>
> 2013/11/21 Fredrik Andersson :
> > Hello Tomcat-experts!
>
> It is hard to read you m
-world-app.
But at the webhotel I just keep getting this when I try to access the
ActionClass through struts.xml:
HTTP Status 404 - There is no Action mapped for namespace [/] and action name
[welcome] associated with context path [/MYAPP-webapp-1.0.0].type Status
reportmessage There is no Action
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jieryn,
On 8/7/13 10:02 AM, jieryn wrote:
> Greetings,
>
> On Wed, Aug 7, 2013 at 9:58 AM, Caldarale, Charles R
> wrote:
>> To allow Tomcat to work. If we changed the name to
>> conf/do_not_delete.xml, would that satisfy you?
>
> I think you've
On 07/08/2013 15:46, jieryn wrote:
> On Tue, Aug 6, 2013 at 11:34 PM, Christopher Schultz
> wrote:
>> The servlet specification requires that certain services be provided
>> by the container. Among them are a) a default servlet to serve content
>> for which no other servlet mapping exists (e.g. st
Greetings,
On Wed, Aug 7, 2013 at 9:58 AM, Caldarale, Charles R
wrote:
> To allow Tomcat to work. If we changed the name to conf/do_not_delete.xml,
> would that satisfy you?
I think you've quite severely missed the point of the entire
discussion which I've raised.
> From: jieryn [mailto:jie...@gmail.com]
> Subject: Re: apache tomcat 8.0.0-rc1; /manager 404; NPE
> so what is the point of keeping the global conf/web.xml..
To allow Tomcat to work. If we changed the name to conf/do_not_delete.xml,
would that satisfy you?
- Chuck
THIS COMMUNIC
On Tue, Aug 6, 2013 at 11:34 PM, Christopher Schultz
wrote:
> The servlet specification requires that certain services be provided
> by the container. Among them are a) a default servlet to serve content
> for which no other servlet mapping exists (e.g. static files, etc.)
> and b) a servlet calle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jieryn,
On 8/6/13 10:00 PM, jieryn wrote:
> Greetings,
>
> On Tue, Aug 6, 2013 at 4:53 PM, Mark Thomas
> wrote:
>> The Tomcat 7.0.x behaviour is identical to Tomcat 8.0.x. The root
>> cause of the stack trace in both versions is the missing
>> co
Greetings,
On Tue, Aug 6, 2013 at 4:53 PM, Mark Thomas wrote:
> The Tomcat 7.0.x behaviour is identical to Tomcat 8.0.x.
> The root cause of the stack trace in both versions is the missing
> configuration for the JSP servlet.
Ok, since the manager application already provides a web.xml file,
sho
the log, but the
>>> browser sees what appears to be a typical tomcat 404 error page
>>> without exposing the full trace:
>>
>> I can't repeat this with a clean installation. Please provide the steps
>> to reproduce from a clean 8.0.0-RC1 install.
>
&
Greetings,
On Tue, Aug 6, 2013 at 2:56 PM, Mark Thomas wrote:
> On 06/08/2013 20:46, jieryn wrote:
>> When I try to hit the /manager application from a browser without
>> specifying /html, the following NPE ends up in the log, but the
>> browser sees what appears to be a typ
On 06/08/2013 20:46, jieryn wrote:
> When I try to hit the /manager application from a browser without
> specifying /html, the following NPE ends up in the log, but the
> browser sees what appears to be a typical tomcat 404 error page
> without exposing the full trace:
I can't r
When I try to hit the /manager application from a browser without
specifying /html, the following NPE ends up in the log, but the
browser sees what appears to be a typical tomcat 404 error page
without exposing the full trace:
==> logs/access_log.2013-08-06 <==
a.b.c.d - - [06/Aug/2013:14
equests in less
> that 10 ms. Excluding the pauses thus, it took this bot 36 x 10 ms
> = 0.36 s "real time" to scan the 36 URLs (excluding network
> latency, which is probably about 50 ms per URL). If the server
> added an average 1 s pause to each 404 response, it would have
&
in less that 10
ms. Excluding the pauses thus, it took this bot 36 x 10 ms = 0.36 s "real time" to scan
the 36 URLs (excluding network latency, which is probably about 50 ms per URL).
If the server added an average 1 s pause to each 404 response, it would have taken the bot
36 seconds &qu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chris,
On 4/20/13 6:08 PM, chris derham wrote:
> I think that you have articulated your suggestion very well. I
> think you have weighed the pros well and been open to debate.
> Personally I just don't think what you propose will have the effect
> t
Leo Donahue - RDSA IT wrote:
-Original Message-
From: Howard W. Smith, Jr. [mailto:smithh032...@gmail.com]
Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
also, if an 'ANN' email was sent, where /expert tomcat/ users can
deri
>-Original Message-
>From: Howard W. Smith, Jr. [mailto:smithh032...@gmail.com]
>Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
>HTTP/1.0" 404
>
>
>also, if an 'ANN' email was sent, where /expert tomcat/ users can
>d
chris derham wrote:
But honestly, I am also a bit at a loss now as to how to continue. There is
of course no way for me to prove the validity of the scheme by installing it
on 31 million (20%) of webservers on the Internet and looking at the
resulting bot activity patterns to confirm my suspicio
> But honestly, I am also a bit at a loss now as to how to continue. There is
> of course no way for me to prove the validity of the scheme by installing it
> on 31 million (20%) of webservers on the Internet and looking at the
> resulting bot activity patterns to confirm my suspicions.
Try to en
normal" clients receive mostly non-404 responses, while bots - by
the very nature of what they are looking for - receive many 404 responses.
So anything that would in some way "penalise" 404 responses with respect to
other ones, should impact bots much more than normal clients
3
omcat, that's like using a
B-52 to kill a mouse. Why not just properly shielding the manager application at the
Tomcat level ?
Apache HTTPD doesn't give
a 404, it just closes the connection.
Would you kindly explain how you got Apache httpd to do that ?
Off the top of my head, I do
nt IP addresses
can even connect to /manager, let alone access it. Apache HTTPD doesn't give
a 404, it just closes the connection. No exposure, no wasted threads, no
wasted sockets, nothing.
EJP
-
To unsubscribe, e-mail: user
On Sat, Apr 20, 2013 at 7:22 AM, André Warnier wrote:
>
> 5) if the scheme works, and it does the effect of making this type of
> server-scanning uneconomical, bot developers will look for other ways to
> find vulnerable targets.
>
IMHO, I don't see why bots will get 'turned off' by having to wa
a
> server : "normal" clients receive mostly non-404 responses, while bots - by
> the very nature of what they are looking for - receive many 404 responses.
> So anything that would in some way "penalise" 404 responses with respect to
> other ones, should impact bo
On 4/20/2013 7:29 AM, André Warnier wrote:
...
Addendum : actually, as far as 4xx codes go, a bit more discrimination
is needed. A 401 response (Auth required) for example, should not be
slowed down, as it is part of a normal authentication cycle. There may
be others like that.
Well, Java SE
André Warnier wrote:
Mark H. Wood wrote:
On Wed, Apr 17, 2013 at 01:24:04PM -0500, Caldarale, Charles R wrote:
From: Leo Donahue - RDSA IT [mailto:leodona...@mail.maricopa.gov]
Subject: RE: Tomcat access log reveals hack attempt: "HEAD
/manager/html HTTP/1.0" 404
So you are saying i
] Subject: Re: Tomcat access log reveals
hack attempt: "HEAD /manager/html HTTP/1.0" 404
That's the idea. That is one reason why I brought this
discussion here : to check if, if the default factory setting
was for example 1000 ms delay for each 404 answer, could anyone
think of a severe d
Mark H. Wood wrote:
On Wed, Apr 17, 2013 at 01:24:04PM -0500, Caldarale, Charles R wrote:
From: Leo Donahue - RDSA IT [mailto:leodona...@mail.maricopa.gov]
Subject: RE: Tomcat access log reveals hack attempt: "HEAD /manager/html HTTP/1.0" 404
So you are saying it could be possible
On Wed, Apr 17, 2013 at 01:24:04PM -0500, Caldarale, Charles R wrote:
> > From: Leo Donahue - RDSA IT [mailto:leodona...@mail.maricopa.gov]
> > Subject: RE: Tomcat access log reveals hack attempt: "HEAD /manager/html
> > HTTP/1.0" 404
>
> > So you are s
arnier
> >>> [mailto:a...@ice-sa.com] Subject: Re: Tomcat access log reveals
> >>> hack attempt: "HEAD /manager/html HTTP/1.0" 404
> >>>
> >>>
> >>> That's the idea. That is one reason why I brought this
> >>> d
On Thu, Apr 18, 2013 at 12:26 PM, André Warnier wrote:
>
> My contention is that this would be self-defeating for the bots.
>
>
> 91.121.172.164 - - [03/Apr/2013:08:19:50 +0200] "GET /robots.txt HTTP/1.1"
> 404 360 "-" "Mozilla/5.0 (Windows; U; MSIE 7.0
related to eachother; each one of them probes for some
known vulnerability, but it is not so that if one URL results in a 404, any
of the others would, or vice-versa.
So this is 3,000,000 URLs to try, no matter what.
And say that by a stroke of bad luck, all of these 100,000 hosts have been
well-configured
ed to eachother; each one of them probes for some
> known vulnerability, but it is not so that if one URL results in a 404, any
> of the others would, or vice-versa.
> So this is 3,000,000 URLs to try, no matter what.
> And say that by a stroke of bad luck, all of these 100,000 hosts
On Wed, Apr 17, 2013 at 3:45 PM, Leo Donahue - RDSA IT <
leodona...@mail.maricopa.gov> wrote:
>
> Not knowing anything about the history of the HTTP 404 method, if a server
> does not find a matching request URI, why was it decided that the protocol
> would even respond at al
omcat
version for security reasons, how many of them do their best to 'always'
have the latest-n-greatest version of tomcat.
So, even if 'delay 404' was added, I don't think many of the
already-existing apache/tomcat websites will have this new 'delay 404'
f
On Wed, Apr 17, 2013 at 1:59 PM, Leo Donahue - RDSA IT <
leodona...@mail.maricopa.gov> wrote:
> >-Original Message-
> >From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> >Subject: Re: Tomcat access log reveals hack attempt: "HEAD /
>-Original Message-
>From: André Warnier [mailto:a...@ice-sa.com]
>Subject: Re: [OT] Tomcat access log reveals hack attempt: "HEAD
>/manager/html HTTP/1.0" 404
>
>Leo Donahue - RDSA IT wrote:
>...
>
>>
>> [Way OT...]
>> If you get this to
not read the tomcat documentation on how to do it. :)
Trying to catch up on all the responses. I wanted to respond to a few other
posts, but thought I might keep reading. Now, I will go back to reading
more of the responses.
> If you deliberately delay 404 by a known amount of time, i
Leo Donahue - RDSA IT wrote:
...
[Way OT...]
If you get this to work, then the next place you can take this idea is to the
phone company. Why should my phone even ring at all if I know the caller is
from an 800 number... or from some other list of people I don't care to talk to
... I would
Leo Donahue - RDSA IT wrote:
-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
So you are saying it could be possible to know in advance that certain
requests are for repeate
>-Original Message-
>From: André Warnier [mailto:a...@ice-sa.com]
>Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
>HTTP/1.0" 404
>
>>
>> So you are saying it could be possible to know in advance that certain
>requests are f
:
113.11.200.30 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
HTTP/1.0" 404 -
By the way
1) I think just feeding the default ROOT webapp to a Google bot or
Baidu will result in such requests coming from search bots for
awhile. That is because ROOT/index.jsp has links to the Manager
applic
Leo Donahue - RDSA IT wrote:
-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Wednesday, April 17, 2013 10:28 AM
To: Tomcat Users List
Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
Leo Donahue - RDSA IT wrote:
---
nager/html HTTP/1.0" 404
That's the idea. That is one reason why I brought this
discussion here : to check if, if the default factory setting
was for example 1000 ms delay for each 404 answer, could anyone
think of a severe detrimental side-effect ?
What if I send 10,000 requests to
0 - - [09/Apr/2013:19:26:58 -0400] "HEAD /manager/html
> HTTP/1.0" 404 -
>
By the way
1) I think just feeding the default ROOT webapp to a Google bot or
Baidu will result in such requests coming from search bots for
awhile. That is because ROOT/index.jsp has links to the Manager
you have a botnet composed of 100 bots, and you want (collectively) to have them scan
100,000 hosts in total, each one for 30 known "buggy" URLs. These 30 URLs are unrelated to
eachother; each one of them probes for some known vulnerability, but it is not so that if
one URL results in
> From: Leo Donahue - RDSA IT [mailto:leodona...@mail.maricopa.gov]
> Subject: RE: Tomcat access log reveals hack attempt: "HEAD /manager/html
> HTTP/1.0" 404
> So you are saying it could be possible to know in advance that certain
> requests are for repeated requests
>-Original Message-
>From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
>HTTP/1.0" 404
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>Mark,
>
>On 4/17/1
>-Original Message-
>From: André Warnier [mailto:a...@ice-sa.com]
>Sent: Wednesday, April 17, 2013 10:28 AM
>To: Tomcat Users List
>Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
>HTTP/1.0" 404
>
>Leo Donahue - RDSA I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 4/17/13 8:49 AM, Mark H. Wood wrote:
> Yes. But someone *does* own the botted computers, and their own
> operations are slightly affected. I have wondered if there is
> some way to make a bot so intrusive that many more owners will ask
: "HEAD /manager/html HTTP/1.0" 404
>>>
>>>
>>> That's the idea. That is one reason why I brought this
>>> discussion here : to check if, if the default factory setting
>>> was for example 1000 ms delay for each 404 answer, could anyone
>
Leo Donahue - RDSA IT wrote:
-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
That's the idea. That is one reason why I brought this discussion here : to
check if,
ly not against a real db
:-)), I have used manged to download the whole contents of a db after
a little scripting of a sql injection and some perusal of the results.
If you deliberately delay 404 by a known amount of time, it will still
stick out, a
>-Original Message-
>From: André Warnier [mailto:a...@ice-sa.com]
>Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
>HTTP/1.0" 404
>
>
>That's the idea. That is one reason why I brought this discussion here : to
>check if,
On Tue, Apr 16, 2013 at 01:57:55PM -0300, chris derham wrote:
> > Or, another way of looking at this would be that for every 40 servers
> > scanned without a 404 delay, the same bot infrastructure within the same
> > time would only be able to scan 1 server if a 1 s 404 del
proportion
of "vaccinated servers" to make the virus statistically
ineffective. Maybe if we find a simple patch to Tomcat to
introduce this 404-delay, we could hire a botnet to distribute
the patch ?
Mmmm, maybe there is another idea there : how about an
anti-botnet botnet ?
Microsoft alr
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
André,
On 4/16/13 2:37 PM, André Warnier wrote:
Say that it would be easy to implement this in Tomcat, and that we
do not collectively find good reasons not to do so, and that it
does get implemented.
Then I pledge tha
Pïd stèr wrote:
On 16 Apr 2013, at 19:38, "André Warnier" wrote:
Pïd stèr wrote:
On 16 Apr 2013, at 17:58, chris derham wrote:
Or, another way of looking at this would be that for every 40 servers
scanned without a 404 delay, the same bot infrastructure within the same
time wou
enough proportion
>> of "vaccinated servers" to make the virus statistically
>> ineffective. Maybe if we find a simple patch to Tomcat to
>> introduce this 404-delay, we could hire a botnet to distribute
>> the patch ?
>>
>> Mmmm, maybe there is an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
André,
On 4/16/13 2:37 PM, André Warnier wrote:
> Say that it would be easy to implement this in Tomcat, and that we
> do not collectively find good reasons not to do so, and that it
> does get implemented.
>
> Then I pledge that my next move would
Tomcat to introduce this 404-delay,
we could hire a botnet to distribute the patch ?
Mmmm, maybe there is another idea there : how about an anti-botnet botnet ?
Microsoft already works with the DOJ and DHS occasionally doing
something like this. It has been a while, but I have seen articles
re
On 16 Apr 2013, at 19:38, "André Warnier" wrote:
> Pïd stèr wrote:
>> On 16 Apr 2013, at 17:58, chris derham wrote:
>>
>>>> Or, another way of looking at this would be that for every 40 servers
>>>> scanned without a 404 delay, the same bot infra
Pïd stèr wrote:
On 16 Apr 2013, at 17:58, chris derham wrote:
Or, another way of looking at this would be that for every 40 servers
scanned without a 404 delay, the same bot infrastructure within the same
time would only be able to scan 1 server if a 1 s 404 delay was implemented
by 50% of
chris derham wrote:
Or, another way of looking at this would be that for every 40 servers
scanned without a 404 delay, the same bot infrastructure within the same
time would only be able to scan 1 server if a 1 s 404 delay was implemented
by 50% of the webservers.
This assumes that the
On 16 Apr 2013, at 17:58, chris derham wrote:
>> Or, another way of looking at this would be that for every 40 servers
>> scanned without a 404 delay, the same bot infrastructure within the same
>> time would only be able to scan 1 server if a 1 s 404 delay was implemente
On 4/16/2013 12:57 PM, chris derham wrote:
Or, another way of looking at this would be that for every 40 servers
scanned without a 404 delay, the same bot infrastructure within the same
time would only be able to scan 1 server if a 1 s 404 delay was implemented
by 50% of the webservers.
This
> Or, another way of looking at this would be that for every 40 servers
> scanned without a 404 delay, the same bot infrastructure within the same
> time would only be able to scan 1 server if a 1 s 404 delay was implemented
> by 50% of the webservers.
This assumes that the scann
Mark H. Wood wrote:
On Mon, Apr 15, 2013 at 07:15:11PM +0200, André Warnier wrote:
Neven Cvetkovic wrote:
How about creating a fake manager application :)))
That takes X minutes/seconds to get back a 404 ;)))
[snip]
Of course at the moment I am just fishing here for potential negative
side
On Mon, Apr 15, 2013 at 07:15:11PM +0200, André Warnier wrote:
> Neven Cvetkovic wrote:
> > How about creating a fake manager application :)))
> >
> > That takes X minutes/seconds to get back a 404 ;)))
[snip]
> Of course at the moment I am just fishing here for potential
On 4/15/2013 10:15 AM, André Warnier wrote:
Neven Cvetkovic wrote:
How about creating a fake manager application :)))
That takes X minutes/seconds to get back a 404 ;)))
Just for the sake of the discussion :
- a fake manager application would apply to just the /manager webapp,
not to other
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Pid,
On 4/15/13 6:19 AM, Pid wrote:
> On 15/04/2013 00:03, Christopher Schultz wrote:
>> Pid,
>>
>> On 4/12/13 1:54 PM, Pïd stèr wrote:
>>> On 11 Apr 2013, at 21:36, Christopher Schultz
>>> wrote:
[...] though I would run Apache httpd and To
Neven Cvetkovic wrote:
How about creating a fake manager application :)))
That takes X minutes/seconds to get back a 404 ;)))
Just for the sake of the discussion :
- a fake manager application would apply to just the /manager webapp, not to other
potential hacking targets, no ? (or you
How about creating a fake manager application :)))
That takes X minutes/seconds to get back a 404 ;)))
properly-configured servers, and thus ultimately
result in a "404 Not Found" response.
It is also the interest of these annoying tools to be able to scan as many IP addresses
and ports as possible, within as short a time as possible, in order to locate vulnerable
targets faster.
But ne
omcat Users List'
Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
On 15/04/2013 03:51, Esmond Pitt wrote:
I agree with your comment. Adding a second box for Tomcat only means
I also have to configure a firewall between them, whereas using
127.0.
On 15/04/2013 16:11, Mark Eggers wrote:
> On 4/15/2013 3:19 AM, Pid wrote:
>> On 15/04/2013 00:03, Christopher Schultz wrote:
>>> Pid,
>>>
>>> On 4/12/13 1:54 PM, Pïd stèr wrote:
On 11 Apr 2013, at 21:36, Christopher Schultz
wrote:
> [...] though I would run Apache httpd and Tomcat o
On 4/15/2013 3:19 AM, Pid wrote:
On 15/04/2013 00:03, Christopher Schultz wrote:
Pid,
On 4/12/13 1:54 PM, Pïd stèr wrote:
On 11 Apr 2013, at 21:36, Christopher Schultz
wrote:
[...] though I would run Apache httpd and Tomcat on different
hosts, so localhost-binding is not possible unless you
On Mon, Apr 15, 2013 at 7:49 AM, Pid wrote:
>
> I'm persisting in this point because I don't want other users to
> continue believing the fallacy that 'hiding' Tomcat behind Apache HTTPD
> alone improves their security.
>
>
And your persistence is appreciated, and I definitely appreciate all the
013 8:25 PM
> To: Esmond Pitt
> Cc: 'Tomcat Users List'
> Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
> HTTP/1.0" 404
>
> On 15/04/2013 03:51, Esmond Pitt wrote:
>>
>>>> I agree with your comment. Adding a se
: 'Tomcat Users List'
Subject: Re: Tomcat access log reveals hack attempt: "HEAD /manager/html
HTTP/1.0" 404
On 15/04/2013 03:51, Esmond Pitt wrote:
>
>>> I agree with your comment. Adding a second box for Tomcat only means
>>> I also have to configure a f
On 15/04/2013 03:51, Esmond Pitt wrote:
>
>>> I agree with your comment. Adding a second box for Tomcat only means I
>>> also have to configure a firewall between them, whereas using
>>> 127.0.0.x for Tomcat protects it completely.
>
>> No it doesn't!
>> Obfuscation or indirection != security.
On 15/04/2013 00:03, Christopher Schultz wrote:
> Pid,
>
> On 4/12/13 1:54 PM, Pïd stèr wrote:
>> On 11 Apr 2013, at 21:36, Christopher Schultz
>> wrote:
>>> [...] though I would run Apache httpd and Tomcat on different
>>> hosts, so localhost-binding is not possible unless you are doing
>>> som
>> I agree with your comment. Adding a second box for Tomcat only means I
>> also have to configure a firewall between them, whereas using
>> 127.0.0.x for Tomcat protects it completely.
> No it doesn't!
> Obfuscation or indirection != security.
> HTTPD doesn't magically provide you with some e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Pid,
On 4/12/13 1:54 PM, Pïd stèr wrote:
> On 11 Apr 2013, at 21:36, Christopher Schultz
> wrote:
>> [...] though I would run Apache httpd and Tomcat on different
>> hosts, so localhost-binding is not possible unless you are doing
>> something lik
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Esmond,
On 4/11/13 8:43 PM, Esmond Pitt wrote:
> I referred to the OpenLDAP lockout mechanism, which is not at all
> primitive.
How does OpenLDAP do better than Tomcat? If I make repeated (failed)
login attempts against a single user, can I cause
t;> the JAR file, and I just reported this in their Issue Tracker.
>>
>> 127.0.0.1 - - [10/Apr/2013:20:00:54 -0400] "GET
>> /apple-touch-icon-precomposed.png HTTP/1.1" 404 -
>> 127.0.0.1 - - [10/Apr/2013:20:00:54 -0400] "GET /apple-touch-icon.png
>> HTT
:54 -0400] "GET
/apple-touch-icon-precomposed.png HTTP/1.1" 404 -
127.0.0.1 - - [10/Apr/2013:20:00:54 -0400] "GET /apple-touch-icon.png
HTTP/1.1" 404 -
Also, netbeans IDE and start-stop-tomcat implementation results in the
following:
127.0.0.1 - - [10/Apr/2013:20:11:05 -0
201 - 300 of 1037 matches
Mail list logo
