0

I'm having an issue with the default configuration of tomcat 7 on Debian 8.

Problem: I got the cpu of my server, due to java process, jump to 100% and stay there for hours making the server slow. If I restart tomcat server the cpu goes again to 1%. After some hours the problem starts again.

Java Application status: No custom java applications are installed on tomcat so this is probably a tomcat issue.

Logs: Watching catalina.out I found this error message in corrispondence to the cpu pitch start

Jan 19, 2017 1:03:23 AM org.apache.coyote.http11.AbstractHttp11Processor process INFO: Error parsing HTTP request header

How to replicate: After the server restart I have tried to access the tomcat server home page using https by visiting this url through a web browser

https://domain.com:8080

and voila, the cpu start to go crazy and I get the log as before.

What does it means: This means everyone with a special request can DDOS my server

Question: Is there any way to solve this issue possibily without changing my linux distribution or packaged versions of tomcat used by apt?

I'm using a fresh debian 8 default image from Google Compute Engine. tomcat 7.0.56 Java 1.7.0_111

Marco Brenna
  • 27
  • 8
  • An update: I sent a bug report to Debian team, details are here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854551 . The issue is solved on Tomcat version 7.0.56-3+deb8u8 for Debian 8 and version 7.0.28-4+deb7u10 for Debian 7. An apt-get upgrade now solve this issue. – Marco Brenna Feb 15 '17 at 11:33

3 Answers3

1

In short, apply scientific method.

  • Find out what is listening on port 8080.
  • Find out how it is configured.
  • Understand what it is doing.
  • Take appropriate action
user9517
  • 115,471
  • 20
  • 215
  • 297
  • 1
    As I said, on port 8080 is listening tomcat, is a default installation with default configuration, is doing it's work but in a wrong way, the log are not so informative, this is why I ask. I always apply scientific method as a technician and I tried to be as informative as I could in my question. I thought my question might help other people to solve my same problem and raise a problem detected on a default installation. I ask here for find help from experts and be helpful. Maybe my question is not complete. I will solve my problem on my own. Thanks – Marco Brenna Jan 24 '17 at 09:04
  • There is no evidence of your having carried out any diagnostics in your question. – user9517 Jan 26 '17 at 08:12
1

I have exactly the same problem, and the same system configurations. When I reboot the server, it will be OK for a day or two, then again tomcat7 uses about 99% of the cpu.

This time I did this:

service tomcat7 stop

And it is still working for me. I don't use Java, as you mentioned, so its OK for me.

Zaman
  • 11
  • 2
  • I restart tomcat7 server too but after 2 days the problem happened again, and again, cpu 100%. On my server the problem occours not randomly, it happens because there is some sort of bot that try to bruteforce the password of tomcat manager on my ip every day; when it tries to access tomcat manager using https at the address https://domain.com:8080/manager the 100% cpu begins again... – Marco Brenna Jan 26 '17 at 12:42
1

I had exactly the same problem with Debian 8, tomca7.0.56.

For me uprading to the backport version solved it. I upgraded tomcat7, tomcat7-common, libtomcat7-java and libservlet3.0-java to version =7.0.73-1~bpo8+1 (like this way: apt-get install tomcat7=7.0.73-1~bpo8+1)

I think we have a massive security issue with the current release of tomcat 7.0.56 in Debian 8. With the standard configuration everyone who simply calls https:// domain.tld:8080 causes thes cpu scaling to 100% until you restart the tomcat!

Inna
  • 126
  • 3
  • 1
    Upgrading to the backport version solved the issue to me too and I think this is a massive security issue too. Upgrading to backports is a real solution but it's better to avoid backports in a production enviroment. It could be great if this can be solved on stable. I look for informations about how to report this to Debian team. – Marco Brenna Feb 03 '17 at 08:54