|
|
| Line 1: |
Line 1: |
| − | == Installation ==
| |
| − | * Choose an installation directory (referenced as '''TOMCAT_DIR''' from now on), preferably on a different drive to the OS.
| |
| − |
| |
| − | :do we get many advantages separating application and webapps? - Darren Edmonds
| |
| − | ::it could prevent path traversal under windows, but not unix. Separating apps from OS is common good practice anyway. [[User:Stephendv|Stephendv]] 02:32, 9 October 2006 (EDT)
| |
| − |
| |
| | == Network Security == | | == Network Security == |
| | | | |
| Line 12: |
Line 6: |
| | ::I was thinking of a firewall discussion in relation to protecting the server. Perhaps this should be changed to only mention the shutdown port needs protecting in tomcat [[User:dledmonds|dledmonds]] | | ::I was thinking of a firewall discussion in relation to protecting the server. Perhaps this should be changed to only mention the shutdown port needs protecting in tomcat [[User:dledmonds|dledmonds]] |
| | :::Ah, gotcha! Yeah that would definitely be something worthwhile adding. [[User:Stephendv|Stephendv]] 06:53, 23 October 2006 (EDT) | | :::Ah, gotcha! Yeah that would definitely be something worthwhile adding. [[User:Stephendv|Stephendv]] 06:53, 23 October 2006 (EDT) |
| − |
| |
| − | == User Input ==
| |
| − |
| |
| − | User data, whether it be HTTP headers or parameters, should '"never"' be trusted. It is usually the responsibility of the application to validate data, but it is important that one poorly written application doesn't compromise Tomcat as a whole.
| |
| − |
| |
| − | * global filters
| |
| − | * global error pages (see above)
| |
| − | * permission lockdown (see below)
| |
| − |
| |
| − | :I think this section would be more appropriate for apps themselves, rather than applying to the server as a whole. [[User:Stephendv|Stephendv]] 04:24, 16 October 2006 (EDT)
| |
| − | :Agree the section doesn't seem relevant to Tomcat as it is, but I wanted to focus on preventing one webapp ruining it for everyone. Perhaps a full rundown on java security is out of scope, but how could we prevent a poorly written download webapp from using path traversal exploits to download files of other webapps? [[User:dledmonds|dledmonds]]
| |
| − |
| |
| − | == Securing Manager WebApp ==
| |
| − |
| |
| − | * By default there are no users with the manager role. To make use of the manager webapp you need to add a new user into the '''CATALINA_HOME'''/conf/tomcat-users.xml file.
| |
| − | <user username="darren" password="ReallyComplexPassword" roles="manager"/>
| |
| − |
| |
| − | * Using a [http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html valve] to filter by IP or hostname to only allow a subset of machines to connect (i.e. LAN machines). Add one of the following within the Context tag in '''CATALINA_HOME'''/conf/Catalina/localhost/manager.xml
| |
| − | <!-- allow only LAN IPs to connect to the manager webapp -->
| |
| − | <!-- contrary to the current Tomcat 5.5 documation the value for '''allow''' is not a regular expression -->
| |
| − | <!-- future versions may have to be specificed as 192\.168\.1\.* -->
| |
| − | <Valve className="org.apache.catalina.valves.RemoteAddrValve"
| |
| − | allow="192.168.1.*" />
| |
| − |
| |
| − | <!-- allow only LAN hosts to connect to the manager webapp -->
| |
| − | <!-- contrary to the current Tomcat 5.5 documation the value for '''allow''' is not a regular expression -->
| |
| − | <!-- future versions may have to be specificed as *\.localdomain\.com -->
| |
| − | <Valve className="org.apache.catalina.valves.RemoteHostValve"
| |
| − | allow="*.localdomain.com" />
| |
| − |
| |
| − | * You can rename the manager webapp to something else, e.g. ''foobar'' (''confirm nothing breaks in this move'')
| |
| − | ** Move '''CATALINA_HOME'''/conf/Catalina/localhost/'''manager.xml''' to '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml'''
| |
| − | ** Update the '''docBase''' attribute within '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml''' to ${catalina.home}/server/webapps/foobar
| |
| − | ** Move '''CATALINA_HOME'''/server/webapps/'''manager''' to '''CATALINA_HOME'''/server/webapps/'''foobar'''
| |
| − |
| |
| − | :Darren, this section looks good as it is! I think you could merge it with the main article whenever you're happy with it.[[User:Stephendv|Stephendv]] 06:57, 23 October 2006 (EDT)
| |
| − |
| |
| − | == Miscellaneous ==
| |
| − |
| |
| − | * [http://tomcat.apache.org/faq/security.html Tomcat Security FAQ]
| |
| − |
| |
| − | === Using Port 80 ===
| |
| − |
| |
| − | If you are on a Windows machine you will be able to change the port attribute of the connector within the ''Catalina'' service from 8080 to 80. This allows you to use tomcat directly to serve all requests. Depending on your requirements it may not be good enough to serve directly from Tomcat so you may like to consider;
| |
| − | * Use IIS / Apache running on port 80 and mod_jk to proxy requests to Tomcat
| |
| − |
| |
| − | On a UNIX machine only root is allowed to run services on ports below 1024 (kernel recompilation can overcome this). It is a very bad idea to run Tomcat as root, so the options are;
| |
| − | * Use Apache running on port 80 and mod_jk to proxy requests to Tomcat (''is mod_jk the correct version?'')
| |
| − | * Run Tomcat as root, but in a chroot jail
| |
| − | * Use a tool like authbind to enable a non root user to bind to ports below 1024
| |
| − | * Use a port forwarder such as [http://www.netfilter.org/projects/iptables/index.html Iptables] to redirect incoming requests from 8080 to 80. This has the disadvantage that internal redirects still need to use 8080.
| |
| − | * Run [http://www.squid-cache.org/ Squid] as a web accelerator in front of Tomcat
| |
| − | * Use JSVC/procrun
| |
| − |
| |
| − | === Cleartext Passwords in CATALINA_HOME/conf/server.xml ===
| |
| − |
| |
| − | When configuring a resource, such as a JDBC pool, it is necessary to include clear text username and password in CATALINA_HOME/conf/server.xml Best practices advice us never to store clear text passwords, but the following paragraphs highlight it is very difficult to avoid.
| |
| − |
| |
| − | If one way encryption was used on the password it must be possible for a database connection to be established using a username and encrypted password - so the encrypted password is just as valuable as the clear text one to an attacker.
| |
| − |
| |
| − | If two way encryption was used a keyfile is needed which must also live on the filesystem. To make it more secure a passphase is added to the keyfile which then has to be stored in the configuration as clear text - no improvement.
| |
| − |
| |
| − | Encoding is security by obscurity and offers no form of protection (algorithms can be reverse engineered). What encoding does do is make huge amounts of overhead work - you need to customise Tomcat and the commons digester it uses to parse the config files. You'd also need a way to create encoded passwords.
| |
| − |
| |
| − | In the case of a JDBC pool what you can do is;
| |
| − | * make sure the database user only has access to the databases and tables they need (also limit rights as necessary).
| |
| − | * make sure the raw database files are only accessible to the user running the database services (e.g. mysql/postgresql user)
| |
| − | * make sure the Tomcat configuration files are only accessible to the tomcat user
| |
| − |
| |
| − | :Same above, merge at any time [[User:Stephendv|Stephendv]] 06:59, 23 October 2006 (EDT)
| |
