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 namespace [/] and action name
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 fredan...@hotmail.com:
Hello Tomcat-experts!
It is hard to read you message.
I have
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
-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
On Tue, Aug 6, 2013 at 11:34 PM, Christopher Schultz
ch...@christopherschultz.net 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,
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 COMMUNICATION MAY
Greetings,
On Wed, Aug 7, 2013 at 9:58 AM, Caldarale, Charles R
chuck.caldar...@unisys.com 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.
On 07/08/2013 15:46, jieryn wrote:
On Tue, Aug 6, 2013 at 11:34 PM, Christopher Schultz
ch...@christopherschultz.net 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
-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
chuck.caldar...@unisys.com wrote:
To allow Tomcat to work. If we changed the name to
conf/do_not_delete.xml, would that satisfy you?
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:37:52
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 repeat
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.
Remove the ${catalina.home}/conf/web.xml file and restart the server.
With Apache Tomcat 7.x there was no need for this conf
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.
Remove the ${catalina.home}/conf/web.xml file and restart the server.
With Apache Tomcat
Greetings,
On Tue, Aug 6, 2013 at 4:53 PM, Mark Thomas ma...@apache.org 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
-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 ma...@apache.org
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
-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) setting up a bot to perform such a scanning operation has
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 enter
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
-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
derive/develop a list of the popular/frequent URLs
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
derive/develop a list
-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
that
. 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 real time to make the same scan
an average 1 s pause to each 404 response, it would have
taken the bot 36 seconds real time to make the same scan. That
is 100 times more.
Yes, but the attacker has more source ports than you have destination
ports, can run in parallel, and doesn't really care if you delay him.
Your proposal
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: users-unsubscr
, 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 not know of any
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 to know
] 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 detrimental side
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 it could
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
them, and just protecting one's own servers
against them doesn't stop them in a general sense.
2) there is a fundamental asymmetry between how bots access a server (and
most of the responses that they get), and how normal clients access a
server : normal clients receive mostly non-404 responses
On Sat, Apr 20, 2013 at 7:22 AM, André Warnier a...@ice-sa.com 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
On Thu, Apr 18, 2013 at 12:26 PM, André Warnier a...@ice-sa.com 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; Windows NT 6.0; en-US)
I
: 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 detrimental side
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 to know in advance
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
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 delay was implemented
by 50
-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, if the default factory setting was for example 1000
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, and they can use this just as much as a positive
indication.
HTH somebody
Chris
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, if the default
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
André,
On 4/17/13 1:27 PM, André Warnier wrote:
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
-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
-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:
-Original Message-
From: André Warnier
-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/13 8:49 AM, Mark H. Wood wrote:
Yes. But someone *does
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 of nothing or being made
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 a 404, any of the others would, or vice-versa
- - [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
application.
It looks
/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 your server for some
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:
-Original
in the
log:
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
-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 repeated requests of nothing or being made
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 repeated requests
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
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, it will still
stick out, and they can use this just as much
-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 work, then the next place you can take this idea is to the
phone
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 /manager/html
HTTP/1.0 404
People *do* 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'
feature. :)
Also, the 'delay 404' basically requires a possible change or release note
that says
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 all? Seems like the request
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, and that none
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-effects.
Search
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
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 scanning software makes
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
On 16 Apr 2013, at 17:58, chris derham ch...@derham.me.uk 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
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
Pïd stèr wrote:
On 16 Apr 2013, at 17:58, chris derham ch...@derham.me.uk 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
On 16 Apr 2013, at 19:38, André Warnier a...@ice-sa.com wrote:
Pïd stèr wrote:
On 16 Apr 2013, at 17:58, chris derham ch...@derham.me.uk 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
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
referring
-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 be
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 already works with the DOJ
Pïd stèr wrote:
On 16 Apr 2013, at 19:38, André Warnier a...@ice-sa.com wrote:
Pïd stèr wrote:
On 16 Apr 2013, at 17:58, chris derham ch...@derham.me.uk wrote:
Or, another way of looking at this would be that for every 40 servers
scanned without a 404 delay, the same bot infrastructure
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
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 already works
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
ch...@christopherschultz.net wrote:
[...] though I would run Apache httpd and Tomcat on different
hosts, so localhost-binding is not possible unless you
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.
HTTPD doesn't
'
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.0.x for Tomcat protects
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.0.x for Tomcat protects it completely.
No it doesn't!
Obfuscation or indirection != security
On Mon, Apr 15, 2013 at 7:49 AM, Pid p...@pidster.com 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
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
ch...@christopherschultz.net wrote:
[...] though I would run Apache httpd and Tomcat on different
hosts, so
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
ch...@christopherschultz.net wrote:
[...] though I would run Apache httpd and
/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.0.x for Tomcat protects it completely.
No it doesn't!
Obfuscation or indirection != security.
HTTPD
on 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 nevertheless
How about creating a fake manager application :)))
That takes X minutes/seconds to get back a 404 ;)))
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
-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
ch...@christopherschultz.net wrote:
[...] though I would run Apache
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
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
-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
ch...@christopherschultz.net wrote:
[...] though I would run Apache httpd and Tomcat on different
hosts, so localhost-binding is not possible unless you are
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 extra
HTTP/1.0 404
On 11 Apr 2013, at 21:36, Christopher Schultz ch...@christopherschultz.net
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Esmond,
On 4/10/13 8:21 PM, Esmond Pitt wrote:
We had lots of these and finally an attack last year on a Tomcat
where the manager password somehow
: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 -0400] HEAD
/netbeans-tomcat
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
HTTP/1.1 404 -
Also, netbeans IDE and start-stop-tomcat implementation results
On 11 Apr 2013, at 21:36, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Esmond,
On 4/10/13 8:21 PM, Esmond Pitt wrote:
We had lots of these and finally an attack last year on a Tomcat
where the manager password somehow hadn't been
-Original Message-
From: Howard W. Smith, Jr. [mailto:smithh032...@gmail.com]
Sent: Wednesday, April 10, 2013 7:35 PM
To: Esmond Pitt
Cc: Tomcat Users List
Subject: Re: Tomcat access log reveals hack attempt: HEAD
/manager/html HTTP/1.0 404
On Wed, Apr 10, 2013 at 8:21 PM, Esmond
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Esmond,
On 4/10/13 8:21 PM, Esmond Pitt wrote:
We had lots of these and finally an attack last year on a Tomcat
where the manager password somehow hadn't been changed.
Note that the manager webapp has no default passwords, so I wonder
what you
log reveals hack attempt: HEAD /manager/html HTTP/1.0
404
On Wed, Apr 10, 2013 at 8:21 PM, Esmond Pitt
esmond.p...@bigpond.comwrote:
We had lots of these and finally an attack last year on a
Tomcat
where
the manager password somehow hadn't been changed. The attacker
installed a viral
reveals hack attempt: HEAD
/manager/html HTTP/1.0 404
On Wed, Apr 10, 2013 at 8:21 PM, Esmond Pitt
esmond.p...@bigpond.comwrote:
We had lots of these and finally an attack last year on a Tomcat
where
the manager password somehow hadn't been changed. The attacker
installed a viral
: Wednesday, April 10, 2013
7:35 PM To: Esmond Pitt Cc: Tomcat Users List Subject: Re: Tomcat
access log reveals hack attempt: HEAD /manager/html HTTP/1.0
404
On Wed, Apr 10, 2013 at 8:21 PM, Esmond Pitt
esmond.p...@bigpond.comwrote:
We had lots of these and finally an attack last year
2013/4/12 Christopher Schultz ch...@christopherschultz.net:
The attacker installed a viral servlet application that killed the
server completely, we had to rebuild it.
I -- like most people I would guess -- don't run under a
SecurityManager, but doing so can significantly limit the damage
You would have had to intentionally enable the default password.
I had clearly done that.
The attacker installed a viral servlet application that killed the
server completely, we had to rebuild it.
I -- like most people I would guess -- don't run under a SecurityManager,
but doing so can
404 -
This is an unfamiliar ip address to me, and I have already prepared the
app/tomcat for these type of attacks. How? by removing any/all tomee/tomcat
(manager/web) apps. I did that some time ago, when I first migrated from
glassfish to tomee/tomcat, and that was the best/easiest way I knew how
201 - 300 of 992 matches
Mail list logo
