tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Beckett <paul_beck...@outlook.com>
Subject RE: Security Issue in Tomcat
Date Fri, 12 Jul 2013 08:38:17 GMT
I would second reading the Tomcat security how-to. The OWASP guide to securing tomcat : https://www.owasp.org/index.php/Securing_tomcat
is also worth a look.
You could also consider starting tomcat with the security manager enabled... although intially
finding and configuring all the permissions your app needs can be a world of pain.
In terms of preventing modification of log files, if you are on UNIX you could look at setting
your log files to use append only mode:chattr +a
This is a solution I quite like, and works well for me (although you do need to consider how
you will handle archival / removal of old log files, as you will need to remove the append
only mode from the file first). I don't recall seeing anyone else advocate this approach though,
so if anyone else wants to weigh in on disadvantages or why they think this might be a bad
idea feel free.
Cheers,
Paul

> Date: Fri, 12 Jul 2013 13:53:39 +0530
> Subject: Re: Security Issue in Tomcat
> From: pe.chanaka.ck@gmail.com
> To: users@tomcat.apache.org
> 
> Hi Ognjen,
> 
> On 12.7.2013 6:51, Chanaka Dharmarathna wrote:
> >
> >> I'm using Tomcat 7.0.40 for hosted application. I have not configured any
> >> user accounts for tomcat (admin, manager, user etc.). Recently my deployed
> >> web application was damaged. Restarting tomcat recovered it back.
> >>
> >> But it seems someone tried to access my tomcat and delete some files(I
> >> guess class file of index.jsp as mentioned in the log). I have added my
> >> log
> >> files [0], [1], [2] and [3]. Currently I have my jsp directory outside the
> >> WEB-INF directory (yes, it's bad practice and I'll correct it).
> >>
> >
> > Tomcat is complaining that it is not able to read class files of compiled
> > JSPs (index.jsp, and 401.jsp). It is not clear how are those class files
> > deleted -- was it through application security breach, Tomcat, OS or local
> > user accidentally deleted them, or changed access privileges. From the log
> > files I am unable to tell that.
> >
> > Keep in mind that if the attacker was able to modify Tomcat's work
> > directory he was most certainly able to modify logs directory as well, so
> > there is a possibility that log files are altered.
> >
> >
> >
> >  1. Do you see any issues after looking my log files ? May be due to a bad
> >> configuration/practice etc.
> >>
> >
> > For start, remove ALL web applications you don't need -- probably
> > everything except your own application. If you don't use manager
> > application, remove it. If you do need it, configure manager application to
> > accept connections only from trusted IP addresses, use unexpected username
> > (something different from "manager", "admin" or "tomcat"), and use strong
> > password.
> >
> > Run Tomcat service always as unprivileged user (e.g. tomcat, not root).
> >
> > Start reading and practicing what is written here:
> >
> > http://tomcat.apache.org/**tomcat-7.0-doc/security-howto.**html<http://tomcat.apache.org/tomcat-7.0-doc/security-howto.html>
> >
> >
> >
> >
> >  2. And can someone delete files if there are no user accounts for tomcat ?
> >>
> >
> > Tomcat process must be able to modify work, logs and temp directories, in
> > order to work properly. Therefore, poorly written webapp, or (less likely)
> > bug in Tomcat, may allow remote attacker to modify or delete files at least
> > in those three directories. If other Tomcat directories are writable by
> > user running Tomcat, attacker may also do other nasty things (alter JSPs,
> > install new webapps and so on). In worst case, if you run your Tomcat
> > service as user root, a bug in your webapp might allow attacker to take
> > full control over your server.
> >
> 
> Thanks for your valuable thoughts on this. I'll follow these instructions
> to secure my tomcat.
> 
> Regards !
> -- 
> *Chanaka*
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message