Thanks for the reply. I accept this remedy will clear the issue. But my question is how to verify the root cause of this DOS attack that occurred earlier? What ever steps suggested above is to take a precaution or solve the issue. please help me.
Thanks, Kumar. On Mon, Feb 10, 2014 at 12:06 PM, Daniel Mikusa <dmik...@gopivotal.com>wrote: > On Feb 10, 2014, at 11:56 AM, Kumar Muthuramalingam <kumarkm...@gmail.com> > wrote: > > > Thanks for your reply. I have 3 applications running under the tomcat and > > only one application got a ping.jsp file others don't. And also I could > see > > from the access logs that only the application that has got ping.jsp file > > was pinged others were not. And the sessions are high only for this > > particular application. Now I got something else in my mind. Is ping.jsp > is > > a mandatory file for tomcat. We got nothing in that ping.jsp. It 's an > > empty file with <%="OK"%>. > > Seems like this could be the problem. This JSP file is going to create a > session every time you "ping" it, since JSP files will create a session by > default. If you're client, whatever is requesting this JSP, doesn't > maintain the session then it'll end up creating a new session every time it > requests the JSP page. > > Add this and the JSP won't create a session. > > <%@ page session="false" %> > > > I agree this could be due to DOS attack. > > If so, it would seem to be self inflicted. Fix your JSP file and I bet > this problem will go away. > > Dan > > > Can we ask our network pupil to > > find if there was a network failure or delay happened. Can we find that > is > > my another question? > > > > Please help me. > > > > Thanks, > > Kumar. > > > > > > On Mon, Feb 10, 2014 at 11:28 AM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA256 > >> > >> Kumar, > >> > >> On 2/8/14, 7:08 PM, Kumar Muthuramalingam wrote: > >>> I 'm using tomcat version 6 and 7. One day there was a sudden > >>> increase in number of sessions in both tomcats. And all the > >>> sessions had no username, same lastaccessed time, same created time > >>> and the inactive time was 00:00:00. It is not happening always but > >>> it happens some times on some day. Can't predict. And We have set > >>> the idle timeout as -1 because we have to. > >> > >> I have a suggestion for this: don't set the session timeout to -1 > >> until the user has successfully authenticated. > >> > >> Sessions can be created at any time, including before authentication. > >> You could add a Filter that detects sessions that are authenticated > >> without the -1 timeout and sets them to that value. > >> > >> This would allow login-less sessions to expire naturally while > >> authenticated users would enjoy sessions that never expire. > >> > >> (Honestly, sessions that never expire is probably a bad idea... > >> clients are disappear at any time and never come back. At least set > >> the session timeout to something hugely long like 5 days or something) > >> > >>> When I try to dig the log. It showed that the load balancer IP was > >>> sending many ping requests to our application. Can anybody tell why > >>> this is happening and how can I find the cause? > >> > >> The lb needs to ping your webapp all the time to see if it's up. > >> Perhaps it's using a resource that (stupidly) always creates a session > >> if one does not exist? > >> > >> - -chris > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1 > >> Comment: GPGTools - http://gpgtools.org > >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >> > >> iQIcBAEBCAAGBQJS+P4dAAoJEBzwKT+lPKRYmHUP/1JzT1aYbqq3CWq8bzJsEKtX > >> LTiNknxXUBmhQE1WZ5J+4f2Pq/7spUD0rOGtkvYyuGw37+ruL0AGJSiEzQ2uA6mD > >> rtylt5IzGO4jjW2Yqr4LlDKmXhBr0IDj4+Xz1KT4W7R7XDY6gNIfN1d8CuAAAP0F > >> BKSLj3crNEmDur+hd0SH3m+oNKYpgy/xVfvWN2MohBY4rIAPpGvmS9IJDeKaWyHY > >> +SZYsyN6bKExWCqaQbObL7ZjHwLhC+hLECEDHFNiZje5dCyKMaALVJYNkaB/jzWw > >> ZLv3FNyTpG35hhBM1j760C+37ZkRt34+rER7ZBBEODfgoxQSGb59Fe9uCtX8aVa4 > >> 9ATxQ8RAqJcMaCgJ6ADTiJhf91MGbPtWJ5ABwqzg8iP650gUcF6RiRWPFdpq1k33 > >> 6SCGeEwHoIMuzCvnp1EiaxXaDFQ1NUYhCz5fEkAeYmZlgl/SlTHrvhe5lTyMQ179 > >> CeccAWjrO1UhyJz5bS9pt8l5xzsVAFxlVCk67rLwffAhWxZb6EmrsclTlBaxDyFL > >> jx6+UH7SADWi0xaGk3LdBdCWHaJRT5F9StPsAReUP/mPpJVVWR6u9x/V1i4HrZX6 > >> /06jj3RCUBxGPKMk6OlidZDQj9XcKMR1CuDeq+ItfzXKg8rgj3C5FaZXUsNYCNTV > >> LgJmIZUtom+YKPoikzQB > >> =2HLh > >> -----END PGP SIGNATURE----- > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
