WARNING: Failed to unregister MBean with name

[Wayne Li]

Hi,

I got errors as below. What is wrong please?
I use Tomcat 8.0.36, Ubuntu 16.04 and Eclipse Neon 4.6.
Thanks in advance.



Nov 30, 2016 7:29:51 PM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler ["http-nio-8080"]
Nov 30, 2016 7:29:51 PM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler ["ajp-nio-8009"]
Nov 30, 2016 7:29:51 PM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler ["http-nio-8080"]
Nov 30, 2016 7:29:51 PM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler ["ajp-nio-8009"]
Nov 30, 2016 7:29:51 PM org.apache.catalina.util.LifecycleMBeanBase
unregister
WARNING: Failed to unregister MBean with name
[Catalina:type=NamingResources,host=localhost,context=/] during component
destruction
javax.management.InstanceNotFoundException:
Catalina:type=NamingResources,host=localhost,context=/
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:546)
at
org.apache.catalina.util.LifecycleMBeanBase.unregister(LifecycleMBeanBase.java:197)
at
org.apache.catalina.util.LifecycleMBeanBase.destroyInternal(LifecycleMBeanBase.java:73)
at
org.apache.catalina.deploy.NamingResourcesImpl.destroyInternal(NamingResourcesImpl.java:1091)
at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:297)
at
org.apache.catalina.core.StandardContext.destroyInternal(StandardContext.java:5626)
at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:297)
at
org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:832)
at
org.apache.catalina.core.ContainerBase.destroyInternal(ContainerBase.java:1012)
at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:297)
at
org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:832)
at
org.apache.catalina.core.ContainerBase.destroyInternal(ContainerBase.java:1012)
at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:297)
at
org.apache.catalina.core.StandardService.destroyInternal(StandardService.java:604)
at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:297)
at
org.apache.catalina.core.StandardServer.destroyInternal(StandardServer.java:877)
at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:297)
at org.apache.catalina.startup.Catalina.stop(Catalina.java:703)
at org.apache.catalina.startup.Catalina.start(Catalina.java:664)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:351)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:485)

Nov 30, 2016 7:29:51 PM org.apache.catalina.util.LifecycleMBeanBase
unregister
WARNING: Failed to unregister MBean with name
[Catalina:type=WebResourceRoot,host=localhost,context=/,name=Cache] during
component destruction
javax.management.InstanceNotFoundException:
Catalina:type=WebResourceRoot,host=localhost,context=/,name=Cache
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:546)
at
org.apache.catalina.util.LifecycleMBeanBase.unregister(LifecycleMBeanBase.java:197)
at
org.apache.catalina.webresources.StandardRoot.destroyInternal(StandardRoot.java:779)
at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:297)
at
org.apache.catalina.core.StandardContext.destroyInternal(StandardContext.java:5644)
at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:297)
at
org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:832)
at
org.apache.catalina.core.ContainerBase.destroyInternal(ContainerBase.java:1012)
at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:297)
at
org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:832)
at
org.apache.catalina.core.ContainerBase.destroyInternal(ContainerBase.java:1012)
at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:297)
at
org.apache.catalina.core.StandardService.destroyInternal(StandardService.java:604)
at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:297)
at
org.apache

Re: Unable to get SSL working on Tomcat 8.5

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Todd,

On 11/29/16 4:41 PM, Bartlett, Todd wrote:
> The below settings work fine on 6.0 version (no other changes Im 
> aware of)  Error received Failed to initialize component 
> [Connector[HTTP/1.1-443

What's the rest of the error message?

>  maxThreads="150" scheme="https" secure="true" 
> keystoreFile="C:\.pfx" keystorePass="" 
> keystoreType="pkcs12" clientAuth="false" 
> sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" ciphers="..." />

Looks okay so far. You need to post more information.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYP4IrAAoJEBzwKT+lPKRY5hAP/3thD5lk9DDd/PMAN1s+Vche
ghVnzNYryyBaqcFCFOpjUWlocWkaltV8yaWHRpkLpzvvRz1SnXVbKx7IRr5wAP6V
7qr4h8FLLubjukA/g42D8UkUmc/Q64ATPZEdKch8FszlchLqsdf1WSfp2e68k/Gg
KPBB2New3bSc4XVxC90gItOcSgq6qwZlIINEYV+f/jsOJufkjzTPF4NllS0NM9i/
XA0EgRhUQlB1Lo9QfmJquniRmNHJwcIt6A810IISaL/f0o1TxFMpqD0xdBrULD+W
169HkBIdTEvpqa3RG9tIVEEDhkW8xN4KR/Q/+WmjxnUGzffDH4AAfJkYKOxYdMzf
zFKG4ka+A5i2Qi9Z+Y87yi0fDKFsjxpA1ugeCRYpLKfTRnu2dkEGak2QRU4KpaIM
IUdql0gy71ZdyNGHj0XTzen6mUqEm0k3AL0pzTsXK0eSvpHlT0Eh981VfGAZQKlo
hs3gUFEdwNJ5xiWEil0tNtke9j8eNwPVE7jRy0QFguc6HkXmWr89DTDi/3W541Nz
ZH7iONQBPtd1fcAk0PoAxuH7ldZ9LcjxZ1tV7t3KYv4SKcD5WjTe6Cc5eVCwQwxY
47TrkSq4enCGw6BbwX+iBKt9LY4MIugpnEp8o2sxnZ56B3bxwfT29/hWmKYmlRjj
l9lZDcQlY4Q+sZhDFifa
=Op4c
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat listener not coming up - no stuck threads

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John,

On 11/26/16 7:29 PM, John D. Ament wrote:
> Hi,
> 
> Looking for some external input.  I've put together a simple
> tomcat embedded instance designed to deploy an arbitrary set of
> servlets, filters, etc.
> 
> For some reason, when I run tests with Tomcat the server never
> fully launches.  I can see the port in use, but connections to the
> server are not answered by the instance.  When I debug the start
> up, I see what appears to be a loop attempting to start services
> that never returns, in LifecycleBase.

So you see a busy-loop? What's the stack trace?

Tomcat version?

> Easiest way to reproduce it with this project is to clone 
> https://github.com/hammock-project/hammock/ and run a local build
> (to get snapshots) and then run 'mvn clean install -Ptomcat-test'
> from rest-resteasy (or spark or jersey).

Er... sorry, I'm not going to do that, and it doesn't look like anyone
else is going to do that, either.

> I'm sure there's something simple I'm over looking.

I browsed your github repo for about 15 seconds until I realized that
there are like 10k files and I'd never find the embedded driver
without asking. So, where is it?

Can you compare your driver with any of the many Tomcat test cases
that launch an embedded server instance? Those test classes do exactly
what it sounds like you are trying to do.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYP4HoAAoJEBzwKT+lPKRYOL8P/A5MQFuVMK0kbgsAzbYVWx81
yLsIN5BgjMBwPCxr2S2KIg40/P8dq256+VFYkwLI/Y3kKi206IK0KQdRJCTQFEO9
avTOSFTgY3IXCCEEijSh5HeM8ofO7AgFrjcUGYZ6PI5PmnkCx/bN+sCAmbIL4SuE
hpOdA+A6zaV7TFFqjk2b71dVeijCTO3B/nUjkwOY7lP56jOX4bM2YDZoZj1o0SsV
bLsR3hjIlyZX1q83XNGPNYicueMZv9EsoUuZkwN3N/9CwTIbn27ck9xWfs3zOsOr
DLppYHdcKQNByd630cL0xhgYEHShJJcUcRddXWCeuEJOQ0urFYvfiOW2H5Py86lE
jwlA8XqIhvK5nmG5fOjwInSN3v+Fhd5A9rAhZrPZpP4+J1tGK37FvVhPJa9xXFWz
OYgtUxP2y1zwYyq+qs5jCYy628HE3Y++YSUSK+mWSN8Id/jDBqKUzZkZWuc7750B
wRy/8rb6F9L47sAVkg4gj8XqQF/gQ3gbS3ujf+eYuIf4GS4h1pmI4xCmuoZo0LLt
NJo2k4jAfwx2l48BpjO9Ry8MaSft2a9vE0uBQR/jwY5dvn5Y0mYX8Dr2JgdFYpeW
Skxf9+U2U/IzB2qePvdmo5u5QUyl40fu6/ndMjoEk/AXycwfodr6/UG9fLOG7uDR
kLSU4n1jBzwEf+9WMtFA
=7GKl
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Apache/Tomcat vulnerability

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jaaz,

On 11/30/16 1:41 PM, Jaaz Portal wrote:
> no it looks like dos, its dos
> 
> i told you they dosed before bind server until we changed it to
> other vendor, and later was scanning my host for apache
> vulnerabilities

Okay, let's just end this because obviously we've never going to get
to the bottom of it.

$ sudo iptables -A INPUT -s evil.host.pl -p tcp -m tcp -j DROP

If they start coming at you from multiple IPs, use CIDR notation to
block a whole subnet or whatever.

Then when these "attacks" keep happening, you can block-out the whole
world and you're application will never seize-up again.

Review your configuration as Mark has suggested. If things are still
not working, re-post with some actual data instead of just
continuously posting "we are under attack, they dos bind, they dos
mod_jk, they dos mod_proxy, what can we do?".

Post. Logs.

A single log line saying "server reached MaxRequestWorkers setting,
consider raising the MaxRequestWorkers setting" is not an indication
of any problem at all other than (lack of) accurate capacity planning.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYP4D1AAoJEBzwKT+lPKRYM6AP/2H+NEy27YU92ccllLOcnBsA
V8RW+lGUjI/nxYqODw2B1cjE8zhnvtPRokdWIkLu0rQA4mg7p/3iLcBvdkZXMAkc
k16aZZk+wbtTgsqK/2ORQ+5lfn3nd4QTk2tzB/z/jJnb+7vp6/qa7ESpZLXi7p3U
TniCZz0gVrykF7NVS1Ospvw/JcEuuFeo4gMnXIupYOqF9jlI1y0HydVreIOCwgq6
fn/4UA9Ku6iGYuPE+k8AQvgbQ3ILaODVanUPTtLQstjfXpHUVGerakclUoxIOawH
ZkzKledtsFzLByPFdI6/Y9+WXDAVtwCKVEFNWc2lHbogy6FC+5ozubRwC5MP8CO4
vicaCl7X+hDwDfxAZEZp1pbGrAd0G7YGgzTSKz5r61t9opv8k5HjWqGFiB2MFob1
jedbWvE40w/d54kuy+1MUAqjH5wM1Rw4hY7glALHiNVs1z5m83YFPYQhcbGdsi31
PxAA5OTVU8hggsbVcq9P5qjYOIQlLH+b2//K2eZK/4QV6u9u0jMuhMq/eeEy93JW
HPb0Uri/TK+LajrJ3fsMTKhWZDS4VkCB+kkJ3BedKDnq1yQMqckJW5WKx4wgaZHA
lxnDbxPjq4nZLI3odsG1eiU7/7yl32tPTy3b038iTacihl5hMdIFZXM5VkoKvdi8
AGidy4ZhsZ920ZAZQqJS
=dqVz
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: users Digest 30 Nov 2016 19:40:04 -0000 Issue 12825

[tomcat]

On 30.11.2016 23:00, Esmond Pitt wrote:


This is getting out of hand. I am subcribed to what is supposed to be a
daily digest. Today I received *seven.* What is going on?

EJP



Well, for one thing, this is a free user help list, for a free software product, and as 
well the people who create and maintain the product, as the people who create and man the 
list, are doing this for free and on their own time.
I am sure that someone will look into it, but may I suggest that in the future you 
moderate your tone ?




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: users Digest 30 Nov 2016 19:40:04 -0000 Issue 12825

[Esmond Pitt]

This is getting out of hand. I am subcribed to what is supposed to be a
daily digest. Today I received *seven.* What is going on?

EJP 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Apache/Tomcat vulnerability

[tomcat]

Let me ask you a question : if you have nothing in the logs, and there are no connections 
to your (Apache) server on port 80, then *what exactly* makes you think that you are under 
some kind of attack ?
How do you know that it is not simply your application that is freezing up under normal 
usage, as opposed to an "attack" ?


This is a serious question, and please think before you answer. Provide some real 
information that might help us to help you. We really need some data, otherwise we may as 
well consult a crystal ball.

(It has been a long time since we have needed it, and I cannot remember where 
we left it)

Saying that "before, they DoS-ed bind", is not real information that we can do anything 
with. It may not be the same "people", it may not have anything to do with this issue that 
you are having.
Similarly, someone "scanning your server for Apache vulnerabilities" is not real 
information either. That happens to any webserver on the WWW, constantly, and they do not 
crash for that. And they generally do not scan for "Apache vulnerabilities", they scan for 
application vulnerabilities or Apache bad configuration issues.


If I had to make a guess, I would say that there are probably, today, more than 100,000 
webservers active on the WWW with an Apache httpd front-end, and an Apache tomcat 
back-end.  If 0.1% of those was crashing because of some attack, that would be 100 tomcat 
servers crashed today, and this official tomcat users list would be full of messages about it.
And that is not happening : your messages about this have been the only ones for the last 
week or so.
So there must be something special to your webserver, or your web application, or your 
configuration, to make this happen.
But so far, you have not given us much to really get going in finding out what is really 
happening.



P.S.
Having a number of TCP connections established (open), between your Apache front-end 
webserver and your back-and tomcat server, is normal and expected.
Apache httpd + mod_jk communicate with tomcat, via TCP.  The port on tomcat which is 
listening on those connections is 8009 (as you can see in the AJP Connector of your tomcat 
configuration).  When Apache starts, mod_jk will automatically create a number of 
connections to tomcat, and keep them open for better performance.


This is what I see currently on one of my servers (where httpd and tomcat are currently 
alive and well, and not loaded at all) :


 Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address State

tcp0  0 127.0.0.1:43611 127.0.0.1:8009  ESTABLISHED 
20059/apache2
tcp0  0 127.0.0.1:41927 127.0.0.1:8009  ESTABLISHED 
10379/apache2
tcp0  0 127.0.0.1:42416 127.0.0.1:8009  ESTABLISHED 
15167/apache2
tcp0  0 127.0.0.1:40649 127.0.0.1:8009  ESTABLISHED 
5279/apache2
tcp0  0 127.0.0.1:40236 127.0.0.1:8009  ESTABLISHED 
533/apache2
tcp0  0 127.0.0.1:43695 127.0.0.1:8009  ESTABLISHED 
15169/apache2
tcp6   0  0 :::8009 :::*LISTEN  
2940/java
tcp6   0  0 127.0.0.1:8009  127.0.0.1:40649 ESTABLISHED 
2940/java
tcp6   0  0 127.0.0.1:8009  127.0.0.1:42416 ESTABLISHED 
2940/java
tcp6   0  0 127.0.0.1:8009  127.0.0.1:41927 ESTABLISHED 
2940/java
tcp6   0  0 127.0.0.1:8009  127.0.0.1:43695 ESTABLISHED 
2940/java
tcp6   0  0 127.0.0.1:8009  127.0.0.1:40236 ESTABLISHED 
2940/java
tcp6   0  0 127.0.0.1:8009  127.0.0.1:43611 ESTABLISHED 
2940/java

(The java process # 2940 is tomcat. Each Apache process that you see is an Apache "child" 
process running mod_jk. This server is not configured for a heavy load, and actually doing 
almost nothing right now.)


What do you see when you enter this command now ?
# netstat --tcp -pan | grep ":8009"


On 30.11.2016 20:39, Jaaz Portal wrote:

hi mark,
thanks, i have fixed configuration as you pointed out,
maybe this will mitigate the attack

before there was no connection_timeout in configuration
and this things was occurring too


best,
artur

2016-11-30 20:29 GMT+01:00 Mark Eggers :


Artur,

On 11/30/2016 10:41 AM, Jaaz Portal wrote:

no it looks like dos, its dos

i told you they dosed before bind server until we changed it to other
vendor,
and later was scanning my host for apache vulnerabilities

configuration is standard, the only thing i changed (after your guidance)
is connection_timeout
but this does not work for this exploit

workers.properties
worker.list=ajp13_worker

#
#-- ajp13_worker WORKER DEFINITION --
#-
#

#
# Defining a worker named ajp13_worker and of type ajp13
# No

Re: Apache/Tomcat vulnerability

[Jaaz Portal]

hi mark,
thanks, i have fixed configuration as you pointed out,
maybe this will mitigate the attack

before there was no connection_timeout in configuration
and this things was occurring too


best,
artur

2016-11-30 20:29 GMT+01:00 Mark Eggers :

> Artur,
>
> On 11/30/2016 10:41 AM, Jaaz Portal wrote:
> > no it looks like dos, its dos
> >
> > i told you they dosed before bind server until we changed it to other
> > vendor,
> > and later was scanning my host for apache vulnerabilities
> >
> > configuration is standard, the only thing i changed (after your guidance)
> > is connection_timeout
> > but this does not work for this exploit
> >
> > workers.properties
> > worker.list=ajp13_worker
> >
> > #
> > #-- ajp13_worker WORKER DEFINITION --
> > #-
> > #
> >
> > #
> > # Defining a worker named ajp13_worker and of type ajp13
> > # Note that the name and the type do not have to match.
> > #
> > worker.ajp13_worker.port=8009
> > worker.ajp13_worker.host=localhost
> > worker.ajp13_worker.socket_timeout=6
> > worker.ajp13_worker.type=ajp13
> > #
> > # Specifies the load balance factor when used with
> > # a load balancing worker.
> > # Note:
> > #  > lbfactor must be > 0
> > #  > Low lbfactor means less work done by the worker.
> > worker.ajp13_worker.lbfactor=1
> >
> > #
> > # Specify the size of the open connection cache.
> > #worker.ajp13_worker.cachesize
> >
> > #
> > #-- DEFAULT LOAD BALANCER WORKER DEFINITION --
> > #-
> > #
> >
> > #
> > # The loadbalancer (type lb) workers perform wighted round-robin
> > # load balancing with sticky sessions.
> > # Note:
> > #  > If a worker dies, the load balancer will check its state
> > #once in a while. Until then all work is redirected to peer
> > #workers.
> > worker.loadbalancer.type=lb
> > worker.loadbalancer.balance_workers=ajp13_worker
> >
> > 
> > server.xml
> >
> >
> >   > redirectPort="8443" maxConnections="256" keepAliveTimeout="3"/>
> >
> > best,
> > artur
>
> From the following fine documentation (which André has posted before):
>
> http://tomcat.apache.org/connectors-doc/reference/workers.html
>
> connection_pool_timeout (lots of stuff) . . . last paragraph:
>
> You should keep this time interval in sync with the keepAliveTimeout
> attribute (if it is set explicitly) or connectionTimeout attribute of
> your AJP connector in Tomcat's server.xml. Note however, that the value
> for mod_jk is given in seconds, the one in server.xml has to use
> milliseconds.
>
> The last line of the above snippet of the documentation is very important.
>
> Now let's look at your values.
>
> From workers.properties:
> worker.ajp13_worker.socket_timeout=6
>
> From server.xml
> connectionTimeout="6"
>
> So your socket_timeout value from workers.properties is 60,000 seconds
> (16 hours, 40 minutes), while your connectionTimeout value is 60,000
> milliseconds (1 minute).
>
> And your keepAliveTimeout (30,000 = 30 seconds) is not in sync with
> either value.
>
> So . . .
>
> 1. remove keepAliveTimeout from your AJP connector
> 2. change worker.ajp13_worker.socket_timeout to 60
>
> This will at least get you in line with the documentation. You can then
> proceed to diagnose whether you have a DOS (or DDOS) attack, an
> application issue, or if this solved the problem.
>
> . . . just my two cents (if I've done the math right)
> /mde/
>
> >
> > 2016-11-30 19:21 GMT+01:00 Mark Eggers :
> >
> >> Artur,
> >> On 11/30/2016 8:36 AM, Jaaz Portal wrote:
> >>> hi,
> >>> they has tried again with success despite setting connection_timeout
> and
> >>> limiting number of clients by mod_bw
> >>> the tomcat has frozen again.
> >>>
> >>> netstat does not showed any connections on port 80 but plenty of
> >>> connections from apache to localhost:8009
> >>> so it was not an attack that you has described (no slowlaris)
> >>>
> >>> im looking into debug files of mod_jk and forensic for some hints. If
> you
> >>> want i can share them (they have 4mb compressed)
> >>>
> >>> best wishes
> >>> artur
> >>
> >> This is beginning to look like an application or a configuration issue
> >> and not a DOS (or DDOS) attack.
> >>
> >> One the issues that may cause this is a mismatched timeout value between
> >> connection_pool_timeout in workers.properties (mod_jk) and the
> >> connectionTimeout in server.xml (Tomcat) for the AJP connector.
> >>
> >> Also, at least for the mod_jk version that I'm running, there is no
> >> limit for reply_timeout (mod_jk) by default.
> >>
> >> Can you post your workers.properties file and the AJP connector portion
> >> of your server.xml?
> >>
> >> In the conf directory of the mod_jk source code, there is a very nice
> >> workers.properties file that has sensible defaults. If you've not done
> >> so, I suggest that you start with the values 

Save the date: ApacheCon Miami, May 15-19, 2017

[Rich Bowen]

Dear Apache enthusiast,

ApacheCon and Apache Big Data will be held at the Intercontinental in
Miami, Florida, May 16-18, 2017. Submit your talks, and register, at
http://apachecon.com/  Talks aimed at the Big Data section of the event
should go to
http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp
while other talks should go to
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp


ApacheCon is the best place to meet the people that develop the software
that you use and rely on. It’s also a great opportunity to deepen your
involvement in the project, and perhaps make the leap to contributing.
And we find that user case studies, showcasing how you use Apache
projects to solve real world problems, are very popular at this event.
So, do consider whether you have a use case that might make a good
presentation.

ApacheCon will have many different ways that you can participate:

Technical Content: We’ll have three days of technical sessions covering
many of the projects at the ASF. We’ll be publishing a schedule of talks
on March 9th, so that you can plan what you’ll be attending

BarCamp: The Apache BarCamp is a standard feature of ApacheCon - an
un-conference style event, where the schedule is determined on-site by
the attendees, and anything is fair game.

Lightning Talks: Even if you don’t give a full-length talk, the
Lightning Talks are five minute presentations on any topic related to
the ASF, and can be given by any attendee. If there’s something you’re
passionate about, consider giving a Lightning Talk.

Sponsor: It costs money to put on a conference, and this is a great
opportunity for companies involved in Apache projects, or who benefit
from Apache code - your employers - to get their name and products in
front of the community. Sponsors can start any any monetary level, and
can sponsor everything from the conference badge lanyard, through larger
items such as video recordings and evening events. For more information
on sponsoring ApacheCon, see http://apachecon.com/sponsor/

So, get your tickets today at http://apachecon.com/ and submit your
talks. ApacheCon Miami is going to be our best ApacheCon yet, and you,
and your project, can’t afford to miss it.

-- 
Rich Bowen - rbo...@apache.org
VP, Conferences
http://apachecon.com
@apachecon


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Apache/Tomcat vulnerability

[Mark Eggers]

Artur,

On 11/30/2016 10:41 AM, Jaaz Portal wrote:
> no it looks like dos, its dos
> 
> i told you they dosed before bind server until we changed it to other
> vendor,
> and later was scanning my host for apache vulnerabilities
> 
> configuration is standard, the only thing i changed (after your guidance)
> is connection_timeout
> but this does not work for this exploit
> 
> workers.properties
> worker.list=ajp13_worker
> 
> #
> #-- ajp13_worker WORKER DEFINITION --
> #-
> #
> 
> #
> # Defining a worker named ajp13_worker and of type ajp13
> # Note that the name and the type do not have to match.
> #
> worker.ajp13_worker.port=8009
> worker.ajp13_worker.host=localhost
> worker.ajp13_worker.socket_timeout=6
> worker.ajp13_worker.type=ajp13
> #
> # Specifies the load balance factor when used with
> # a load balancing worker.
> # Note:
> #  > lbfactor must be > 0
> #  > Low lbfactor means less work done by the worker.
> worker.ajp13_worker.lbfactor=1
> 
> #
> # Specify the size of the open connection cache.
> #worker.ajp13_worker.cachesize
> 
> #
> #-- DEFAULT LOAD BALANCER WORKER DEFINITION --
> #-
> #
> 
> #
> # The loadbalancer (type lb) workers perform wighted round-robin
> # load balancing with sticky sessions.
> # Note:
> #  > If a worker dies, the load balancer will check its state
> #once in a while. Until then all work is redirected to peer
> #workers.
> worker.loadbalancer.type=lb
> worker.loadbalancer.balance_workers=ajp13_worker
> 
> 
> server.xml
> 
> 
>   redirectPort="8443" maxConnections="256" keepAliveTimeout="3"/>
> 
> best,
> artur

From the following fine documentation (which André has posted before):

http://tomcat.apache.org/connectors-doc/reference/workers.html

connection_pool_timeout (lots of stuff) . . . last paragraph:

You should keep this time interval in sync with the keepAliveTimeout
attribute (if it is set explicitly) or connectionTimeout attribute of
your AJP connector in Tomcat's server.xml. Note however, that the value
for mod_jk is given in seconds, the one in server.xml has to use
milliseconds.

The last line of the above snippet of the documentation is very important.

Now let's look at your values.

From workers.properties:
worker.ajp13_worker.socket_timeout=6

From server.xml
connectionTimeout="6"

So your socket_timeout value from workers.properties is 60,000 seconds
(16 hours, 40 minutes), while your connectionTimeout value is 60,000
milliseconds (1 minute).

And your keepAliveTimeout (30,000 = 30 seconds) is not in sync with
either value.

So . . .

1. remove keepAliveTimeout from your AJP connector
2. change worker.ajp13_worker.socket_timeout to 60

This will at least get you in line with the documentation. You can then
proceed to diagnose whether you have a DOS (or DDOS) attack, an
application issue, or if this solved the problem.

. . . just my two cents (if I've done the math right)
/mde/

> 
> 2016-11-30 19:21 GMT+01:00 Mark Eggers :
> 
>> Artur,
>> On 11/30/2016 8:36 AM, Jaaz Portal wrote:
>>> hi,
>>> they has tried again with success despite setting connection_timeout and
>>> limiting number of clients by mod_bw
>>> the tomcat has frozen again.
>>>
>>> netstat does not showed any connections on port 80 but plenty of
>>> connections from apache to localhost:8009
>>> so it was not an attack that you has described (no slowlaris)
>>>
>>> im looking into debug files of mod_jk and forensic for some hints. If you
>>> want i can share them (they have 4mb compressed)
>>>
>>> best wishes
>>> artur
>>
>> This is beginning to look like an application or a configuration issue
>> and not a DOS (or DDOS) attack.
>>
>> One the issues that may cause this is a mismatched timeout value between
>> connection_pool_timeout in workers.properties (mod_jk) and the
>> connectionTimeout in server.xml (Tomcat) for the AJP connector.
>>
>> Also, at least for the mod_jk version that I'm running, there is no
>> limit for reply_timeout (mod_jk) by default.
>>
>> Can you post your workers.properties file and the AJP connector portion
>> of your server.xml?
>>
>> In the conf directory of the mod_jk source code, there is a very nice
>> workers.properties file that has sensible defaults. If you've not done
>> so, I suggest that you start with the values specified in that file, and
>> make sure that the timeout values match (see my comment above).
>>
>> Also, when you used mod-proxy, did you use mod-proxy-ajp or
>> mod-proxy-http? If you used mod-proxy-ajp, then again there could be a
>> timeout mismatch (or no timeout specified at all).
>>
>> . . . just my two cents
>> /mde/
>>
>>>
>>> 2016-11-29 11:01 GMT+01:00 André Warnier (tomcat) :
>>>
 On 28.11.2016 22:04, Jaaz Portal wrote:

> hi Andre,
> you are wrong. This vulnerability is not 

Re: Apache/Tomcat vulnerability

[Jaaz Portal]

no it looks like dos, its dos

i told you they dosed before bind server until we changed it to other
vendor,
and later was scanning my host for apache vulnerabilities

configuration is standard, the only thing i changed (after your guidance)
is connection_timeout
but this does not work for this exploit

workers.properties
worker.list=ajp13_worker

#
#-- ajp13_worker WORKER DEFINITION --
#-
#

#
# Defining a worker named ajp13_worker and of type ajp13
# Note that the name and the type do not have to match.
#
worker.ajp13_worker.port=8009
worker.ajp13_worker.host=localhost
worker.ajp13_worker.socket_timeout=6
worker.ajp13_worker.type=ajp13
#
# Specifies the load balance factor when used with
# a load balancing worker.
# Note:
#  > lbfactor must be > 0
#  > Low lbfactor means less work done by the worker.
worker.ajp13_worker.lbfactor=1

#
# Specify the size of the open connection cache.
#worker.ajp13_worker.cachesize

#
#-- DEFAULT LOAD BALANCER WORKER DEFINITION --
#-
#

#
# The loadbalancer (type lb) workers perform wighted round-robin
# load balancing with sticky sessions.
# Note:
#  > If a worker dies, the load balancer will check its state
#once in a while. Until then all work is redirected to peer
#workers.
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=ajp13_worker


server.xml


 

best,
artur

2016-11-30 19:21 GMT+01:00 Mark Eggers :

> Artur,
> On 11/30/2016 8:36 AM, Jaaz Portal wrote:
> > hi,
> > they has tried again with success despite setting connection_timeout and
> > limiting number of clients by mod_bw
> > the tomcat has frozen again.
> >
> > netstat does not showed any connections on port 80 but plenty of
> > connections from apache to localhost:8009
> > so it was not an attack that you has described (no slowlaris)
> >
> > im looking into debug files of mod_jk and forensic for some hints. If you
> > want i can share them (they have 4mb compressed)
> >
> > best wishes
> > artur
>
> This is beginning to look like an application or a configuration issue
> and not a DOS (or DDOS) attack.
>
> One the issues that may cause this is a mismatched timeout value between
> connection_pool_timeout in workers.properties (mod_jk) and the
> connectionTimeout in server.xml (Tomcat) for the AJP connector.
>
> Also, at least for the mod_jk version that I'm running, there is no
> limit for reply_timeout (mod_jk) by default.
>
> Can you post your workers.properties file and the AJP connector portion
> of your server.xml?
>
> In the conf directory of the mod_jk source code, there is a very nice
> workers.properties file that has sensible defaults. If you've not done
> so, I suggest that you start with the values specified in that file, and
> make sure that the timeout values match (see my comment above).
>
> Also, when you used mod-proxy, did you use mod-proxy-ajp or
> mod-proxy-http? If you used mod-proxy-ajp, then again there could be a
> timeout mismatch (or no timeout specified at all).
>
> . . . just my two cents
> /mde/
>
> >
> > 2016-11-29 11:01 GMT+01:00 André Warnier (tomcat) :
> >
> >> On 28.11.2016 22:04, Jaaz Portal wrote:
> >>
> >>> hi Andre,
> >>> you are wrong. This vulnerability is not only causing memory leaks, it
> >>> makes also apache workers to hang
> >>>
> >>
> >> Maybe for the last time here :
> >>
> >> - what do you call "apache workers" ?
> >>
> >> , making it easy to exhaust the pool.
> >>
> >> - what do you call "the pool" ?
> >>
> >> what i have in my log files. But it is true also that such exhaustion
> can
> >>> be made by other forms of dos attacks described in this thread.
> >>>
> >>> regarding you suggestion on our application, it does not dos bind
> server
> >>> nether does not scan for various vulnerabilities in apache, what i have
> >>> also in the logs
> >>>
> >>
> >> For your information : I run about 25 Internet-facing Apache webservers
> >> (some with a back-end tomcat, some not).
> >> On every single one of those webservers, there are *hundreds* of such
> >> "scans" every day, as shown by the Apache access logs.  That is just a
> fact
> >> of life on the Internet.
> >> They are annoying, but most of them are harmless (from an "attack" point
> >> of view), because they are scanning for things that we do not run
> >> (phpmyadmin, xmlrpc, vti_bin, etc., etc., the list is almost endless),
> and
> >> thus are responded to by Apache as "404 Not found".
> >> What is annoying with those scans, is
> >> a) that they fill the logfile, and thus make it more difficult to find
> >> really significant things
> >> b) that each of those requires some bandwidth and system resource, if
> only
> >> to return a "404 Not found" (or a "401 Unauthorised"), and that we pay
> for
> >> that bandwidth and resources.
> >>
> >> If I could find a way to c

Re: Apache/Tomcat vulnerability

[Mark Eggers]

Artur,
On 11/30/2016 8:36 AM, Jaaz Portal wrote:
> hi,
> they has tried again with success despite setting connection_timeout and
> limiting number of clients by mod_bw
> the tomcat has frozen again.
> 
> netstat does not showed any connections on port 80 but plenty of
> connections from apache to localhost:8009
> so it was not an attack that you has described (no slowlaris)
> 
> im looking into debug files of mod_jk and forensic for some hints. If you
> want i can share them (they have 4mb compressed)
> 
> best wishes
> artur

This is beginning to look like an application or a configuration issue
and not a DOS (or DDOS) attack.

One the issues that may cause this is a mismatched timeout value between
connection_pool_timeout in workers.properties (mod_jk) and the
connectionTimeout in server.xml (Tomcat) for the AJP connector.

Also, at least for the mod_jk version that I'm running, there is no
limit for reply_timeout (mod_jk) by default.

Can you post your workers.properties file and the AJP connector portion
of your server.xml?

In the conf directory of the mod_jk source code, there is a very nice
workers.properties file that has sensible defaults. If you've not done
so, I suggest that you start with the values specified in that file, and
make sure that the timeout values match (see my comment above).

Also, when you used mod-proxy, did you use mod-proxy-ajp or
mod-proxy-http? If you used mod-proxy-ajp, then again there could be a
timeout mismatch (or no timeout specified at all).

. . . just my two cents
/mde/

> 
> 2016-11-29 11:01 GMT+01:00 André Warnier (tomcat) :
> 
>> On 28.11.2016 22:04, Jaaz Portal wrote:
>>
>>> hi Andre,
>>> you are wrong. This vulnerability is not only causing memory leaks, it
>>> makes also apache workers to hang
>>>
>>
>> Maybe for the last time here :
>>
>> - what do you call "apache workers" ?
>>
>> , making it easy to exhaust the pool.
>>
>> - what do you call "the pool" ?
>>
>> what i have in my log files. But it is true also that such exhaustion can
>>> be made by other forms of dos attacks described in this thread.
>>>
>>> regarding you suggestion on our application, it does not dos bind server
>>> nether does not scan for various vulnerabilities in apache, what i have
>>> also in the logs
>>>
>>
>> For your information : I run about 25 Internet-facing Apache webservers
>> (some with a back-end tomcat, some not).
>> On every single one of those webservers, there are *hundreds* of such
>> "scans" every day, as shown by the Apache access logs.  That is just a fact
>> of life on the Internet.
>> They are annoying, but most of them are harmless (from an "attack" point
>> of view), because they are scanning for things that we do not run
>> (phpmyadmin, xmlrpc, vti_bin, etc., etc., the list is almost endless), and
>> thus are responded to by Apache as "404 Not found".
>> What is annoying with those scans, is
>> a) that they fill the logfile, and thus make it more difficult to find
>> really significant things
>> b) that each of those requires some bandwidth and system resource, if only
>> to return a "404 Not found" (or a "401 Unauthorised"), and that we pay for
>> that bandwidth and resources.
>>
>> If I could find a way to charge 0.1 cent per access to my servers, from
>> the people who wrote or run the programs who are doing this, I could retire
>> in luxury.
>>
>> But they are not a real problem, because they are caught as "invalid" by
>> Apache, and rejected quickly, so they cannot do anything really nasty
>> (except if they were sending several thousand such requests per second to
>> one of my servers for a long time).
>>
>> The ones that are worrying, are the ones
>> - a) which do /not/ end up as a "404 Not found", because they have found
>> an application which responds, and they are not coming from our legitimate
>> customers
>> - b) /the ones which we do not see/, because they either do not send a
>> valid HTTP request, or they have found a way to trigger one of our
>> applications, in such a way that the application misbehaves and, perhaps,
>> even if they do not crash our servers, they may provide the attacker with
>> some entry point to do other things which we do not know and do not control
>>
>> What I am trying to say here, is /do not jump to premature conclusions/.
>> Such "scans" as you mention, happen to everyone, all the time, from
>> ever-changing IP addresses located all over the world. Some of those
>> "scans" may come from the infected PC of your grandmother, and she does not
>> even know about it.
>>
>> There is no guarantee, and no indication or proof so far, that /these/
>> scans are even related to "the other thing" which happens on your
>> webserver, which looked much more focused.
>>
>> So do not just bundle them together as being the same thing, until you
>> have some real data that shows for example that these different things all
>> come from the same IP addresses.
>>
>> And one more thing, also finally until you come back with some real data :

Re: Apache/Tomcat vulnerability

[Jaaz Portal]

yes,
i was in hurry and pasted wrong ip
but i talked with my mate, this one that
had open connection was his host checking our webpage

so beside our connections there was no open http connections
but plenty of that between apache and tomcat

it was no slowlaris guys and with the forensics logs and debug of mod_jk
we are no step closer to find out the cause

any idea what to do next?

best
artur

2016-11-30 18:58 GMT+01:00 Mark Eggers :

> Artur,
>
> On 11/30/2016 9:02 AM, Jaaz Portal wrote:
> > hi,
> > sorry, there was two open connection on port 80
> > from 194.135.88.32 that is somwhere on epix.net.pl
> > an association of internet traffick exchange (some pirate hub)
> >
> > best,
> > artur
>
> 194.135.88.32 appears to be your web site, no?
>
> . . . just my two cents
> /mde/
>
> >
> > 2016-11-30 17:52 GMT+01:00 Jaaz Portal :
> >
> >> hi,
> >> i looked at the logs but there are no strange things,
> >> traffic as usual, no errors despite this one:
> >> [Wed Nov 30 17:10:13.375912 2016] [mpm_event:error] [pid 12870:tid
> >> 139906329666752] AH00484: server reached MaxRequestWorkers setting,
> >> consider raising the MaxRequestWorkers setting
> >>
> >> any idea what to do next?
> >>
> >> best,
> >> artur
> >>
> >> 2016-11-30 17:36 GMT+01:00 Jaaz Portal :
> >>
> >>> hi,
> >>> they has tried again with success despite setting connection_timeout
> and
> >>> limiting number of clients by mod_bw
> >>> the tomcat has frozen again.
> >>>
> >>> netstat does not showed any connections on port 80 but plenty of
> >>> connections from apache to localhost:8009
> >>> so it was not an attack that you has described (no slowlaris)
> >>>
> >>> im looking into debug files of mod_jk and forensic for some hints. If
> you
> >>> want i can share them (they have 4mb compressed)
> >>>
> >>> best wishes
> >>> artur
> >>>
> >>> 2016-11-29 11:01 GMT+01:00 André Warnier (tomcat) :
> >>>
>  On 28.11.2016 22:04, Jaaz Portal wrote:
> 
> > hi Andre,
> > you are wrong. This vulnerability is not only causing memory leaks,
> it
> > makes also apache workers to hang
> >
> 
>  Maybe for the last time here :
> 
>  - what do you call "apache workers" ?
> 
>  , making it easy to exhaust the pool.
> 
>  - what do you call "the pool" ?
> 
>  what i have in my log files. But it is true also that such exhaustion
> can
> > be made by other forms of dos attacks described in this thread.
> >
> > regarding you suggestion on our application, it does not dos bind
> server
> > nether does not scan for various vulnerabilities in apache, what i
> have
> > also in the logs
> >
> 
>  For your information : I run about 25 Internet-facing Apache
> webservers
>  (some with a back-end tomcat, some not).
>  On every single one of those webservers, there are *hundreds* of such
>  "scans" every day, as shown by the Apache access logs.  That is just
> a fact
>  of life on the Internet.
>  They are annoying, but most of them are harmless (from an "attack"
> point
>  of view), because they are scanning for things that we do not run
>  (phpmyadmin, xmlrpc, vti_bin, etc., etc., the list is almost
> endless), and
>  thus are responded to by Apache as "404 Not found".
>  What is annoying with those scans, is
>  a) that they fill the logfile, and thus make it more difficult to find
>  really significant things
>  b) that each of those requires some bandwidth and system resource, if
>  only to return a "404 Not found" (or a "401 Unauthorised"), and that
> we pay
>  for that bandwidth and resources.
> 
>  If I could find a way to charge 0.1 cent per access to my servers,
> from
>  the people who wrote or run the programs who are doing this, I could
> retire
>  in luxury.
> 
>  But they are not a real problem, because they are caught as "invalid"
> by
>  Apache, and rejected quickly, so they cannot do anything really nasty
>  (except if they were sending several thousand such requests per
> second to
>  one of my servers for a long time).
> 
>  The ones that are worrying, are the ones
>  - a) which do /not/ end up as a "404 Not found", because they have
> found
>  an application which responds, and they are not coming from our
> legitimate
>  customers
>  - b) /the ones which we do not see/, because they either do not send a
>  valid HTTP request, or they have found a way to trigger one of our
>  applications, in such a way that the application misbehaves and,
> perhaps,
>  even if they do not crash our servers, they may provide the attacker
> with
>  some entry point to do other things which we do not know and do not
> control
> 
>  What I am trying to say here, is /do not jump to premature
> conclusions/.
>  Such "scans" as you mention, happen to everyone, all the time, from
>  ever-changing IP addresses located all over the world. Some 

Re: Apache/Tomcat vulnerability

[Mark Eggers]

Artur,

On 11/30/2016 9:02 AM, Jaaz Portal wrote:
> hi,
> sorry, there was two open connection on port 80
> from 194.135.88.32 that is somwhere on epix.net.pl
> an association of internet traffick exchange (some pirate hub)
> 
> best,
> artur

194.135.88.32 appears to be your web site, no?

. . . just my two cents
/mde/

> 
> 2016-11-30 17:52 GMT+01:00 Jaaz Portal :
> 
>> hi,
>> i looked at the logs but there are no strange things,
>> traffic as usual, no errors despite this one:
>> [Wed Nov 30 17:10:13.375912 2016] [mpm_event:error] [pid 12870:tid
>> 139906329666752] AH00484: server reached MaxRequestWorkers setting,
>> consider raising the MaxRequestWorkers setting
>>
>> any idea what to do next?
>>
>> best,
>> artur
>>
>> 2016-11-30 17:36 GMT+01:00 Jaaz Portal :
>>
>>> hi,
>>> they has tried again with success despite setting connection_timeout and
>>> limiting number of clients by mod_bw
>>> the tomcat has frozen again.
>>>
>>> netstat does not showed any connections on port 80 but plenty of
>>> connections from apache to localhost:8009
>>> so it was not an attack that you has described (no slowlaris)
>>>
>>> im looking into debug files of mod_jk and forensic for some hints. If you
>>> want i can share them (they have 4mb compressed)
>>>
>>> best wishes
>>> artur
>>>
>>> 2016-11-29 11:01 GMT+01:00 André Warnier (tomcat) :
>>>
 On 28.11.2016 22:04, Jaaz Portal wrote:

> hi Andre,
> you are wrong. This vulnerability is not only causing memory leaks, it
> makes also apache workers to hang
>

 Maybe for the last time here :

 - what do you call "apache workers" ?

 , making it easy to exhaust the pool.

 - what do you call "the pool" ?

 what i have in my log files. But it is true also that such exhaustion can
> be made by other forms of dos attacks described in this thread.
>
> regarding you suggestion on our application, it does not dos bind server
> nether does not scan for various vulnerabilities in apache, what i have
> also in the logs
>

 For your information : I run about 25 Internet-facing Apache webservers
 (some with a back-end tomcat, some not).
 On every single one of those webservers, there are *hundreds* of such
 "scans" every day, as shown by the Apache access logs.  That is just a fact
 of life on the Internet.
 They are annoying, but most of them are harmless (from an "attack" point
 of view), because they are scanning for things that we do not run
 (phpmyadmin, xmlrpc, vti_bin, etc., etc., the list is almost endless), and
 thus are responded to by Apache as "404 Not found".
 What is annoying with those scans, is
 a) that they fill the logfile, and thus make it more difficult to find
 really significant things
 b) that each of those requires some bandwidth and system resource, if
 only to return a "404 Not found" (or a "401 Unauthorised"), and that we pay
 for that bandwidth and resources.

 If I could find a way to charge 0.1 cent per access to my servers, from
 the people who wrote or run the programs who are doing this, I could retire
 in luxury.

 But they are not a real problem, because they are caught as "invalid" by
 Apache, and rejected quickly, so they cannot do anything really nasty
 (except if they were sending several thousand such requests per second to
 one of my servers for a long time).

 The ones that are worrying, are the ones
 - a) which do /not/ end up as a "404 Not found", because they have found
 an application which responds, and they are not coming from our legitimate
 customers
 - b) /the ones which we do not see/, because they either do not send a
 valid HTTP request, or they have found a way to trigger one of our
 applications, in such a way that the application misbehaves and, perhaps,
 even if they do not crash our servers, they may provide the attacker with
 some entry point to do other things which we do not know and do not control

 What I am trying to say here, is /do not jump to premature conclusions/.
 Such "scans" as you mention, happen to everyone, all the time, from
 ever-changing IP addresses located all over the world. Some of those
 "scans" may come from the infected PC of your grandmother, and she does not
 even know about it.

 There is no guarantee, and no indication or proof so far, that /these/
 scans are even related to "the other thing" which happens on your
 webserver, which looked much more focused.

 So do not just bundle them together as being the same thing, until you
 have some real data that shows for example that these different things all
 come from the same IP addresses.

 And one more thing, also finally until you come back with some real data
 : I am not saying that your application "scans your server".  What I am
 saying is that, mayb

Re: Apache/Tomcat vulnerability

[Jaaz Portal]

hi,
sorry, there was two open connection on port 80
from 194.135.88.32 that is somwhere on epix.net.pl
an association of internet traffick exchange (some pirate hub)

best,
artur

2016-11-30 17:52 GMT+01:00 Jaaz Portal :

> hi,
> i looked at the logs but there are no strange things,
> traffic as usual, no errors despite this one:
> [Wed Nov 30 17:10:13.375912 2016] [mpm_event:error] [pid 12870:tid
> 139906329666752] AH00484: server reached MaxRequestWorkers setting,
> consider raising the MaxRequestWorkers setting
>
> any idea what to do next?
>
> best,
> artur
>
> 2016-11-30 17:36 GMT+01:00 Jaaz Portal :
>
>> hi,
>> they has tried again with success despite setting connection_timeout and
>> limiting number of clients by mod_bw
>> the tomcat has frozen again.
>>
>> netstat does not showed any connections on port 80 but plenty of
>> connections from apache to localhost:8009
>> so it was not an attack that you has described (no slowlaris)
>>
>> im looking into debug files of mod_jk and forensic for some hints. If you
>> want i can share them (they have 4mb compressed)
>>
>> best wishes
>> artur
>>
>> 2016-11-29 11:01 GMT+01:00 André Warnier (tomcat) :
>>
>>> On 28.11.2016 22:04, Jaaz Portal wrote:
>>>
 hi Andre,
 you are wrong. This vulnerability is not only causing memory leaks, it
 makes also apache workers to hang

>>>
>>> Maybe for the last time here :
>>>
>>> - what do you call "apache workers" ?
>>>
>>> , making it easy to exhaust the pool.
>>>
>>> - what do you call "the pool" ?
>>>
>>> what i have in my log files. But it is true also that such exhaustion can
 be made by other forms of dos attacks described in this thread.

 regarding you suggestion on our application, it does not dos bind server
 nether does not scan for various vulnerabilities in apache, what i have
 also in the logs

>>>
>>> For your information : I run about 25 Internet-facing Apache webservers
>>> (some with a back-end tomcat, some not).
>>> On every single one of those webservers, there are *hundreds* of such
>>> "scans" every day, as shown by the Apache access logs.  That is just a fact
>>> of life on the Internet.
>>> They are annoying, but most of them are harmless (from an "attack" point
>>> of view), because they are scanning for things that we do not run
>>> (phpmyadmin, xmlrpc, vti_bin, etc., etc., the list is almost endless), and
>>> thus are responded to by Apache as "404 Not found".
>>> What is annoying with those scans, is
>>> a) that they fill the logfile, and thus make it more difficult to find
>>> really significant things
>>> b) that each of those requires some bandwidth and system resource, if
>>> only to return a "404 Not found" (or a "401 Unauthorised"), and that we pay
>>> for that bandwidth and resources.
>>>
>>> If I could find a way to charge 0.1 cent per access to my servers, from
>>> the people who wrote or run the programs who are doing this, I could retire
>>> in luxury.
>>>
>>> But they are not a real problem, because they are caught as "invalid" by
>>> Apache, and rejected quickly, so they cannot do anything really nasty
>>> (except if they were sending several thousand such requests per second to
>>> one of my servers for a long time).
>>>
>>> The ones that are worrying, are the ones
>>> - a) which do /not/ end up as a "404 Not found", because they have found
>>> an application which responds, and they are not coming from our legitimate
>>> customers
>>> - b) /the ones which we do not see/, because they either do not send a
>>> valid HTTP request, or they have found a way to trigger one of our
>>> applications, in such a way that the application misbehaves and, perhaps,
>>> even if they do not crash our servers, they may provide the attacker with
>>> some entry point to do other things which we do not know and do not control
>>>
>>> What I am trying to say here, is /do not jump to premature conclusions/.
>>> Such "scans" as you mention, happen to everyone, all the time, from
>>> ever-changing IP addresses located all over the world. Some of those
>>> "scans" may come from the infected PC of your grandmother, and she does not
>>> even know about it.
>>>
>>> There is no guarantee, and no indication or proof so far, that /these/
>>> scans are even related to "the other thing" which happens on your
>>> webserver, which looked much more focused.
>>>
>>> So do not just bundle them together as being the same thing, until you
>>> have some real data that shows for example that these different things all
>>> come from the same IP addresses.
>>>
>>> And one more thing, also finally until you come back with some real data
>>> : I am not saying that your application "scans your server".  What I am
>>> saying is that, maybe, by chance or by design, the attackers have found a
>>> URL which goes to your application, and which causes your application to
>>> keep tomcat and/or Apache busy for a long time.
>>> And that maybe /that/ is the problem you should be looking for, and n

Re: Apache/Tomcat vulnerability

[Jaaz Portal]

hi,
i looked at the logs but there are no strange things,
traffic as usual, no errors despite this one:
[Wed Nov 30 17:10:13.375912 2016] [mpm_event:error] [pid 12870:tid
139906329666752] AH00484: server reached MaxRequestWorkers setting,
consider raising the MaxRequestWorkers setting

any idea what to do next?

best,
artur

2016-11-30 17:36 GMT+01:00 Jaaz Portal :

> hi,
> they has tried again with success despite setting connection_timeout and
> limiting number of clients by mod_bw
> the tomcat has frozen again.
>
> netstat does not showed any connections on port 80 but plenty of
> connections from apache to localhost:8009
> so it was not an attack that you has described (no slowlaris)
>
> im looking into debug files of mod_jk and forensic for some hints. If you
> want i can share them (they have 4mb compressed)
>
> best wishes
> artur
>
> 2016-11-29 11:01 GMT+01:00 André Warnier (tomcat) :
>
>> On 28.11.2016 22:04, Jaaz Portal wrote:
>>
>>> hi Andre,
>>> you are wrong. This vulnerability is not only causing memory leaks, it
>>> makes also apache workers to hang
>>>
>>
>> Maybe for the last time here :
>>
>> - what do you call "apache workers" ?
>>
>> , making it easy to exhaust the pool.
>>
>> - what do you call "the pool" ?
>>
>> what i have in my log files. But it is true also that such exhaustion can
>>> be made by other forms of dos attacks described in this thread.
>>>
>>> regarding you suggestion on our application, it does not dos bind server
>>> nether does not scan for various vulnerabilities in apache, what i have
>>> also in the logs
>>>
>>
>> For your information : I run about 25 Internet-facing Apache webservers
>> (some with a back-end tomcat, some not).
>> On every single one of those webservers, there are *hundreds* of such
>> "scans" every day, as shown by the Apache access logs.  That is just a fact
>> of life on the Internet.
>> They are annoying, but most of them are harmless (from an "attack" point
>> of view), because they are scanning for things that we do not run
>> (phpmyadmin, xmlrpc, vti_bin, etc., etc., the list is almost endless), and
>> thus are responded to by Apache as "404 Not found".
>> What is annoying with those scans, is
>> a) that they fill the logfile, and thus make it more difficult to find
>> really significant things
>> b) that each of those requires some bandwidth and system resource, if
>> only to return a "404 Not found" (or a "401 Unauthorised"), and that we pay
>> for that bandwidth and resources.
>>
>> If I could find a way to charge 0.1 cent per access to my servers, from
>> the people who wrote or run the programs who are doing this, I could retire
>> in luxury.
>>
>> But they are not a real problem, because they are caught as "invalid" by
>> Apache, and rejected quickly, so they cannot do anything really nasty
>> (except if they were sending several thousand such requests per second to
>> one of my servers for a long time).
>>
>> The ones that are worrying, are the ones
>> - a) which do /not/ end up as a "404 Not found", because they have found
>> an application which responds, and they are not coming from our legitimate
>> customers
>> - b) /the ones which we do not see/, because they either do not send a
>> valid HTTP request, or they have found a way to trigger one of our
>> applications, in such a way that the application misbehaves and, perhaps,
>> even if they do not crash our servers, they may provide the attacker with
>> some entry point to do other things which we do not know and do not control
>>
>> What I am trying to say here, is /do not jump to premature conclusions/.
>> Such "scans" as you mention, happen to everyone, all the time, from
>> ever-changing IP addresses located all over the world. Some of those
>> "scans" may come from the infected PC of your grandmother, and she does not
>> even know about it.
>>
>> There is no guarantee, and no indication or proof so far, that /these/
>> scans are even related to "the other thing" which happens on your
>> webserver, which looked much more focused.
>>
>> So do not just bundle them together as being the same thing, until you
>> have some real data that shows for example that these different things all
>> come from the same IP addresses.
>>
>> And one more thing, also finally until you come back with some real data
>> : I am not saying that your application "scans your server".  What I am
>> saying is that, maybe, by chance or by design, the attackers have found a
>> URL which goes to your application, and which causes your application to
>> keep tomcat and/or Apache busy for a long time.
>> And that maybe /that/ is the problem you should be looking for, and not
>> some hypothetical bug in Apache httpd or tomcat.
>>
>>
>>
>>> kindly regards,
>>> artur
>>>
>>> 2016-11-28 21:33 GMT+01:00 André Warnier (tomcat) :
>>>
>>> On 28.11.2016 20:34, Jaaz Portal wrote:

 hi mark,
> yes, i understand now what slowloris attack is.
> maybe it was this maybe *this one based on * * mod_proxy den

Re: Apache/Tomcat vulnerability

[Jaaz Portal]

hi,
they has tried again with success despite setting connection_timeout and
limiting number of clients by mod_bw
the tomcat has frozen again.

netstat does not showed any connections on port 80 but plenty of
connections from apache to localhost:8009
so it was not an attack that you has described (no slowlaris)

im looking into debug files of mod_jk and forensic for some hints. If you
want i can share them (they have 4mb compressed)

best wishes
artur

2016-11-29 11:01 GMT+01:00 André Warnier (tomcat) :

> On 28.11.2016 22:04, Jaaz Portal wrote:
>
>> hi Andre,
>> you are wrong. This vulnerability is not only causing memory leaks, it
>> makes also apache workers to hang
>>
>
> Maybe for the last time here :
>
> - what do you call "apache workers" ?
>
> , making it easy to exhaust the pool.
>
> - what do you call "the pool" ?
>
> what i have in my log files. But it is true also that such exhaustion can
>> be made by other forms of dos attacks described in this thread.
>>
>> regarding you suggestion on our application, it does not dos bind server
>> nether does not scan for various vulnerabilities in apache, what i have
>> also in the logs
>>
>
> For your information : I run about 25 Internet-facing Apache webservers
> (some with a back-end tomcat, some not).
> On every single one of those webservers, there are *hundreds* of such
> "scans" every day, as shown by the Apache access logs.  That is just a fact
> of life on the Internet.
> They are annoying, but most of them are harmless (from an "attack" point
> of view), because they are scanning for things that we do not run
> (phpmyadmin, xmlrpc, vti_bin, etc., etc., the list is almost endless), and
> thus are responded to by Apache as "404 Not found".
> What is annoying with those scans, is
> a) that they fill the logfile, and thus make it more difficult to find
> really significant things
> b) that each of those requires some bandwidth and system resource, if only
> to return a "404 Not found" (or a "401 Unauthorised"), and that we pay for
> that bandwidth and resources.
>
> If I could find a way to charge 0.1 cent per access to my servers, from
> the people who wrote or run the programs who are doing this, I could retire
> in luxury.
>
> But they are not a real problem, because they are caught as "invalid" by
> Apache, and rejected quickly, so they cannot do anything really nasty
> (except if they were sending several thousand such requests per second to
> one of my servers for a long time).
>
> The ones that are worrying, are the ones
> - a) which do /not/ end up as a "404 Not found", because they have found
> an application which responds, and they are not coming from our legitimate
> customers
> - b) /the ones which we do not see/, because they either do not send a
> valid HTTP request, or they have found a way to trigger one of our
> applications, in such a way that the application misbehaves and, perhaps,
> even if they do not crash our servers, they may provide the attacker with
> some entry point to do other things which we do not know and do not control
>
> What I am trying to say here, is /do not jump to premature conclusions/.
> Such "scans" as you mention, happen to everyone, all the time, from
> ever-changing IP addresses located all over the world. Some of those
> "scans" may come from the infected PC of your grandmother, and she does not
> even know about it.
>
> There is no guarantee, and no indication or proof so far, that /these/
> scans are even related to "the other thing" which happens on your
> webserver, which looked much more focused.
>
> So do not just bundle them together as being the same thing, until you
> have some real data that shows for example that these different things all
> come from the same IP addresses.
>
> And one more thing, also finally until you come back with some real data :
> I am not saying that your application "scans your server".  What I am
> saying is that, maybe, by chance or by design, the attackers have found a
> URL which goes to your application, and which causes your application to
> keep tomcat and/or Apache busy for a long time.
> And that maybe /that/ is the problem you should be looking for, and not
> some hypothetical bug in Apache httpd or tomcat.
>
>
>
>> kindly regards,
>> artur
>>
>> 2016-11-28 21:33 GMT+01:00 André Warnier (tomcat) :
>>
>> On 28.11.2016 20:34, Jaaz Portal wrote:
>>>
>>> hi mark,
 yes, i understand now what slowloris attack is.
 maybe it was this maybe *this one based on * * mod_proxy denial of
 service *
 CVE-2014-0117 


>>> You keep on saying this, but the description of that vulnerability of
>>> *Apache httpd*, and the symptoms which you described, *do not match*.
>>> You described the problem as ocurring in Apache tomcat, which in your
>>> case
>>> is sitting as a back-end, *behind* Apache httpd. And restarting tomcat
>>> cured the problem.
>>>
>>> The CVE above applies to Apache ht

AW: Mounting WebDAV in Tomcat 7.0.45

[Arno Schäfer]

So, many thanks for your comments,

> The general recommendation is to use a 3rd party WebDAV client. Check
> the archives details (I think it is Chris that uses one).

At least I found a product, what we actually use in our company and what I can 
take also for our project.
The WebDAV Client is based on AJAX and JQuery and it should be possible to 
integrate this in our web application.
Because the actual project didn't use AJAX and JQuery can you give me a short 
hint,
what are the requirements to use it and where are the pitfalls, when I use it.

Thanks
Arno

Re: tomcat stopped with a fatal error by jvm

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Vijay,

On 11/30/16 1:49 AM, Vijay Kumar wrote:
> We have an application which is running on Tomcat 7.0.33 and this
> is using Java 6.

You need to upgrade.

> Recently, Tomcat got stopped with a Fatal Error and the error
> logged in catalina.out file is below.
> 
> I have attached the hs_err_pid7711.log also to the mail.

The attachment was stripped. Please only include relevant portions if
you re-post.

> Can one of you please suggest what might be the reason to crash the
> Tomcat. Is it related to JVM or Tomcat?

The crash is n libjvm.so. That's the JVM. It's possible that another
component has broken some internal data structure and that the crash
just happens to occur in the JVM's code.

> If its related to JVM then does the cause is by changing any of
> the Tomcat attributes? or is it completely due to some other system
> files?

Are you using libtcnative?

> I need to figure it out the root cause, please help me.
> 
> # # A fatal error has been detected by the Java Runtime
> Environment: # #  SIGSEGV (0xb) at pc=0x2ae04e2b01b1, pid=7711,
> tid=47143071070528 # # JRE version: 6.0_36-b36 # Java VM: OpenJDK
> 64-Bit Server VM (23.25-b01 mixed mode linux-amd64 compressed
> oops) # Derivative: IcedTea6 1.13.8 # Distribution: Red Hat
> Enterprise Linux Server release 5.11 (Tikanga), package
> rhel-1.13.8.1.el5_11-x86_64 # Problematic frame: # V
> [libjvm.so+0x75e1b1]  JVM_RaiseSignal+0x176841 # # Failed to write
> core dump. Core dumps have been disabled. To enable core dumping,
> try "ulimit -c unlimited" before starting Java again # # An error
> report file with more information is saved as: #
> /home/AASCPROD/hs_err_pid7711.log # # If you would like to submit a
> bug report, please include # instructions how to reproduce the bug
> and visit: #   http://icedtea.classpath.org/bugzilla

This is amd64 Linux, so you should be able to run a memtest on it. Is
this bare hardware or a Virtual Machine? If it's bare hardware, I'd
run memtest86+ on it to be sure the hardware is good before trying to
debug a JVM crash.

I'd also upgrade the JVM.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYPuzyAAoJEBzwKT+lPKRYi+sP/3Cc/TmJWZtPy9QXb5CzCJ1V
Hq2rJhGrYm5qU8Rkj7TW2gn625cxvawaX85PW88Dqkw96jDpgIuQ6x4CFg9A4N9S
lT8Bk2MtIOkbUrDYly/Ihs/r41yCPdv95zCMzRnYPuTHAIklQB1q3qMpy/QfHpYX
ik04Dg8pZ9JS5Y6FTef6ETh5VZcRPCbN29KdgavOJIIkp8Ev5s6ChUz4KOjjEmAE
8shPE7d87jqGkHx0nKrQl+TgUkWrxLLSKaj6xQqBYe3YNW5bPxBNYMhEDJ2EBzuB
PxVBvaAJTvaCPKpoHrak4N47YfFrrYxtwsWlUDMpa6XHUgGi9W2+ExpjcCKPhwD2
pcJAZfwxfuMzN22PRDIj8DtrksusR4/nHjh5ssvYXsZhUFeId7g5ErlVx+z2GwS5
fqUBJ9RWAySh/5M5zY9ihGTgQp2mzVVUXH4TudNn5Oc6/oMDnfsk9SAVy02LP9uz
t7opYJ1EAfFZmm7VcIwZatOS4ybGtY0YrODO1e1pe1pLEGBTUzjT65epxScRQ4s1
h7pvAS/KeAYnhMwnJMyb4u2qUnEq9NHmigvr+8J4eCdLAkrfGxZ+K8fTiV9o6vqg
VWLTfN0PRcaGGc6SknBEywKKbIHOQvQQNIcOYZ0nf255LuJclMmn+MVj6x5zXWnQ
GdYWRJ4O2+omMfe66x2P
=BDeJ
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org