Re: Slow http denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Petr, On 3/14/15 3:32 PM, Petr Nemecek wrote: Hello, our webapp, that is deployed in Tomcat 8.0.18, was tested positive as vulnerable to the slow http denial of service: By using a single computer, it is possible to establish thousands of simultaneous connections and keep them open for a long time. During the attack, the server was rendered unavailable. Any idea what to do with this? Using the NIO connector is the best you can do, here. Or, front Tomcat with a web server that has its own mitigation techniques. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVBMEoAAoJEBzwKT+lPKRYKMwP/iKY9W1YkBQ+qgdYWdcjhD55 q7T8ssN2ChzU2xkVgiHh2ISZSchoOF3KcPNOnYomRn6/KPYaiSb/PWUmJ4WL0n/i csSizG6PKV0fj3ZZk6j19QHKvdDNC7ntP6TC2XsK3bxdCG0LGMeZCKJEEihoKO5L AbgWc9n0DVlKR5s9rMgGzNwjfL9aXva5ZWUY6O0bPb4uay0CcdFrouJLOOHMqjG9 U8aVZ6Zpf7zYc8C0CYaKp6J9yRxM+RkHFszBuVuRKXB1FWQpFssLK3FugTP7+9Cp blshbfpmaw6XSLlQcIMpO4uOgdCOg/KX4Dj5nNaXyR64qa4TleHcLy4b21Usaqwb yVO0tnDlZA9qRGNsN3Djt9ABm5GIiJNsMOUsA7cjfGyaLr+NGKq8sLzXff8Nre4F TKMIAgtpUp3RhMM6dRtJ/sFpLdtggNWWA0+zYlMDp20f5N4e3qtUAq2orIK3A7lM FxcUMgajLZKlDoN4NiO26n97MWP0SzkQYj9/IkI5R2Mi9ijsZ+kSSj54pDFnV81C OEzh7Xxb+8UrPLxLPZBttu1uT7hMZUvJwHJZM/nOLOr+J+vemrbFIg9UGFS1qcIR pgWQEvANR1TFku6HhcgktQugfI4bEYzYxUsRvmX+CwlouzErIxkDq3S1qCFvMCwJ jBy234U/r7X4a+P1p8HW =v4ph -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat7: debugging realms - a howto?
On 14 Mar 2015, at 3:43 PM, Graham Leggett minf...@sharp.fm wrote: Changing the auth-type to CLIENT-CERT shows that the username has been replaced by the subject-DN of the cert, which is progress. Reverse engineering tomcat showed that the tomcatAuthentication parameter solved half the problem - when the webserver provided REMOTE_USER, this was used as the principal in the request, but as a side effect the role lookup was bypassed, and any web application using roles stopped working. The attached patches for tomcat v7.0.x, tomcat v8.0.x and tomcat 9.0.x introduce the tomcatAuthorization flag: https://bz.apache.org/bugzilla/show_bug.cgi?id=57708 The tomcatAuthorization flag, when true, takes the REMOTE_USER from the webserver, but ensures that all the role lookups occur as normal. This means you can drop in a webserver in front of a tomcat hosted web application, and automatically the authn of the webserver will replace the authn in the web application, leaving the authz intact and working. This solves my problem. Regards, Graham — - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Slow http denial of service
Hello, our webapp, that is deployed in Tomcat 8.0.18, was tested positive as vulnerable to the slow http denial of service: By using a single computer, it is possible to establish thousands of simultaneous connections and keep them open for a long time. During the attack, the server was rendered unavailable. Any idea what to do with this? Many thanks, Petr Nemecek - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Slow http denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/14/2015 12:32 PM, Petr Nemecek wrote: Hello, our webapp, that is deployed in Tomcat 8.0.18, was tested positive as vulnerable to the slow http denial of service: By using a single computer, it is possible to establish thousands of simultaneous connections and keep them open for a long time. During the attack, the server was rendered unavailable. Any idea what to do with this? Many thanks, Petr Nemecek Google the following: tomcat 7 slow loris mitigation There are several discussions on how to mitigate this. Bugzilla entry for Tomcat 6.0.36: https://bz.apache.org/bugzilla/show_bug.cgi?id=54263 Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2007-6750 It looks like suitably a suitably configured firewall or mod_reqtimeout http://httpd.apache.org/docs/2.2/mod/mod_reqtimeout.html http://httpd.apache.org/docs/2.4/mod/mod_reqtimeout.html are the available solutions. . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJVBJleAAoJEEFGbsYNeTwtODYH/14GPkOUZ8Kt2up6CbhQVQQW nMgZ5dqh9XtsJ/ov+MNuvrf7DQqK0T5Bb/X6Eh1f1yH62efXREnVDumEmjcdFDwu vwucjnRobvRoUPb74/neBm2cMgVX7LwKIQVCHO0oRilO5gn8fPAGgeGTP8Ci7YQS lJcaecWwEBlpPWzTS1SGDpicsYdq1zdg6SbhWM+35Qt4BAoVMYX3cE2y0KmusS9l dFN/V2z6TA5tSv4/mR0Ho9I0t6AcrraVUHnWJbZ6GL7KcLfQeFROQHu0+9SBW1aI l2V1/gQj1my571PaZNGdst/0855A7eRJ4nd/qOo1J4DHWn1i8ockKlAUTULyBi4= =Yyqi -END PGP SIGNATURE- --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat7: debugging realms - a howto?
On 14 Mar 2015, at 1:04 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: You are using JRE's default java.util.logging.LogManager. You need to configure JRE to use the Tomcat JULI implementation of log manager with -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager The JRE class is usable, but its logging.properties format is a bit different. Adding the above to Eclipse’s launcher configuration brought sanity back to the logging. What this revealed was that no realm decisions were being made - we weren’t getting that far. Placing a watchpoint on the “status” variable in the response revealed the point at which we were getting the 403. In my case switching from basic auth to cert meant changing the tomcat protocol from HTTP to AJP, and this in turn caused a org.apache.catalina.valves.RemoteAddrValve configuration to kick in, which now no longer pointed at localhost (address of Apache proxy) but rather the browser IP, thanks to AJP: Valve className=org.apache.catalina.valves.RemoteAddrValve allow=127.0.0.1”/ Stepping through the org.apache.catalina.valves.RemoteAddrValve implementation in the debugger showed that when it returned the 403, it logged nothing in the log, and it returned no explanatory message in the response. Ideally this needs to be fixed: https://bz.apache.org/bugzilla/show_bug.cgi?id=57705 Now I get the basic authentication to hit as normal. Changing the auth-type to CLIENT-CERT shows that the username has been replaced by the subject-DN of the cert, which is progress. Regards, Graham — - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Getting tomcat to honour REMOTE_USER as provided via mod_proxy_ajp
Hi all, I have reached the point where with an auth-method of CLIENT-CERT is returning the Subject DN of the certificate as the username. What I need to achieve is for tomcat to honour the REMOTE_USER environment variable as set by Apache httpd. I have noticed the tomcatAuthentication flag can be used to ask tomcat to respect the authentication decision provided by Apache httpd, but breakpoints set at the point where we check for these values in AbstractAjpProcessor never fire. Is this possible? Regards, Graham — - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Getting tomcat to honour REMOTE_USER as provided via mod_proxy_ajp
On 14 Mar 2015, at 4:15 PM, Graham Leggett minf...@sharp.fm wrote:
I have reached the point where with an auth-method of CLIENT-CERT is
returning the Subject DN of the certificate as the username.
What I need to achieve is for tomcat to honour the REMOTE_USER environment
variable as set by Apache httpd. I have noticed the tomcatAuthentication flag
can be used to ask tomcat to respect the authentication decision provided by
Apache httpd, but breakpoints set at the point where we check for these
values in AbstractAjpProcessor never fire.
Is this possible?
I discovered that the piece of the Apache config that was enforcing the cert
auth had been temporarily disabled. Enabling that brought me to the next wall.
When tomcat passes through httpd's version of REMOTE_USER, tomcat places the
resulting effective userid in a CoyotePrincipal object.
When the realms are being parsed, the DataSourceRealm falls back to the
RealmBase version of hasRole(), which denies access (again, silently with no
log message or explanation) because the principal object is not a
GeneralPrincipal.
if ((principal == null) || (role == null) ||
!(principal instanceof GenericPrincipal))
// BOOM - we fail here and silently return false
return (false);
GenericPrincipal gp = (GenericPrincipal) principal;
boolean result = gp.hasRole(role);
if (log.isDebugEnabled()) {
String name = principal.getName();
if (result)
log.debug(sm.getString(realmBase.hasRoleSuccess, name, role));
else
log.debug(sm.getString(realmBase.hasRoleFailure, name, role));
}
Looking at CoyotePrincipal, this represents a simple username only. In
contrast, GenericPrincipal represents a username/password/list-of-roles triple.
I need to dig further, but it seems that the tomcatAuthentication option
silently disables authorization in the process.
Regards,
Graham
—
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
