The application installed on Tomcat (9.0.36.B.RELEASE) connects to an external source using SSL (in this case, IBM MQ). I therefore need to specify a truststore, and password for this truststore.
I got it to work adding this to the JVM_OPTS in setenv.sh:
-Djavax.net.ssl.trustStore=/opt/apps/certs/myapplication.truststore
-Djavax.net.ssl.trustStorePassword=TRUSTSTORE-PASSWORD
-Djavax.net.ssl.keyStore=/opt/apps/certs/myapplication.keystore
-Djavax.net.ssl.keyStorePassword=KEYSTORE-PASSWORD
Classic issue with this, the passwords are visible when I do ps -ef|grep java (runs on RHEL).
I have seen a couple suggestions on how to do this (like Hiding plain text password in JVM startup argumnets. " ps -ef | grep 'javax.net.ssl.keyStorePassword'"). But these change/add code or configuration in the WAR file.
I am looking for a "tomcat" solution. Is there a way to to this within the confines of Tomcat. Changes to the WAR file are difficult to implement, as the application comes from a vendor.
Note: this is not for a connector configuration in web.xml since that would only setup SSL for incoming connections. Here the application is making connections to an external system (so outbound from Tomcat's perspective).
You can add additional properties to $CATALINA_BASE/conf/catalina.properties and they will be sourced during Tomcat's startup. As you are certainly aware, system properties are global to the JVM, so there is no way to restrict this configuration to a single application only: the entire Tomcat server will be affected.
Almost all Java system properties can by set this way, with a few exceptions:
catalina.base and catalina.home (obviously),
the configuration for Tomcat logging,
the configuration for JMX and other tools that start before user code.
Attention: You must check whether the VersionLoggerListener (defined in server.xml) does not have logProps="true", otherwise the values of system properties will be logged. By default only the JVM arguments are logged.
Related
Our application server (Apache Tomcat Plume) that use jta-managed data source through tomee.xml file should access database server just in secure (HTTPS) mode with two way ssl or client authentication.
So we have to put keystore and truststore plain passwords into setenv.sh or other places in row format. (I m not sure that is the first and last method to do that?) and what happens is tomcat logging mechanism log all these secret information in plain format into log files like catalina.out.
That what (locating raw passwords in config files) is we do not want. Actually we must ( although it s not appear a big threaten while user have access to files, could find real password atleast), encrypt password and use it in environment variables.
Central Question
In other word, how can we set jvm properties and environment variables in encrypted mode?
Re: Hide or disable Tomcat command line arguments logging (the title of this question)
This logging is done by VersionLoggerListener it is possible to configure it, or just remove it from configuration (server.xml).
Re: plaintext passwords handling
This is covered in Tomcat FAQ.
A Vault can be used to store secrets.
My understanding is that you can add:
-Dhttps.protocols=TLSv1.1,TLSv1.2
to the java options, but I am not sure where this specifically gets added (e.g. what file and where in that file, and where that file might be located).
I'm not a developer and don't have experience with SSL, though I do have access to the server.
That flag is a Java option, and must be fed to Tomcat when it starts. The specific way to do it will depend upon your operating system. If you are running Tomcat as a Windows service, you must modify the service. See Tomcat Windows Service How-To. I recommend using Tomcat7w.exe in the Tomcat bin subdirectory as that gives you a nice GUI. Then go to the Java tab and put that fragment at the end of Java Options.
For Unix, you will need to edit the relevant batch file. There is more than one way to do this, but as a non-developer the simplest option is to add that fragment to catalina.sh in the Tomcat bin subdirectory, as part of JAVA_OPTS.
We are using Apache Tomcat 7 for my web applications and we have decided to go on production stage.
So now is the time to think about how to secure the Tomcat and the machine. After reading "Apache tomcat security considerations" we decided to go on run tomcat process on dedicated user with minimum scenario.
From what I understand the best option is to configure it in a way that the running tomcat process has only read privilege to all the tomcat files.
I figured I would do it in this way:
I would create 2 users:
-tomcat_process - only for running tomcat
-admin - this is the one all the files belong to
tomcat_process will have access to conf directory, and also will be able to run scripts from tomcat/bin/
My main problem is that Tomcat needs to write to some files in $CATALINA_HOME/$CATALINA_BASE. I know I can change the location of logs and work directory and I thought I would point them to tomcat_process home dir (is this even a good idea?).
But I can't find any information if I can change the path to /conf/Catalina dir. Is it possible?
I would like to avoid adding write access to conf directory, as the whole configurations sits in there.
Or do you think that I should live those directories where their are and just add write privileges to them for tomcat_process?
I was wondering if you could please tell me if this is a correct approach or can I do it better?
I'm so confused with all those security guides which are telling me to restrict privileges but not telling how to do it :(
Keeping it simple I think is the key:
Create a new tomcat for each (set of) web application(s) with their own user.
Limit the tomcat resources to only the tomcat user. In linux you can use the chmod/chown command for this.
Place the tomcat behind a reverse proxy: Internet (https) <- external Firewall -> Apache Reverse Proxy <- Internal Firewall (block all unless whitelisted) --> Tomcat
Delete all standard webapps 'manager', 'root', 'docs'
Disable the shutdown command in server.xml
As for java web applications try to contain them in their own sandbox, meaning own database, own users.
To safe maintenance effort, you could run multiple instances using one tomcat binary and a single tomcat user.
http://www.openlogic.com/wazi/bid/188102/How-to-Run-Multiple-Instances-of-Tomcat-on-a-Single-Server
I currently have a server.xml configuration which has the following in it
<Resource auth="Container"
description="DB Connection"
driverClass="oracle.jdbc.driver.OracleDriver"
maxPoolSize="40"
minPoolSize="2"
aquireIncrement="1"
name="jdbc/FOOBAR"
user="foo"
password="bar"
factory="org.apache.naming.factory.BeanFactory"
type="com.mchange.v2.c3p0.ComboPooledDataSource"
jdbcUrl="path:to:db:port:db" />
I have a requirement to no longer allow the username/password to be in clear text in the server.xml file for obvious reasons.
I've read a bit online and came across How to Secure Tomcat Database Passwords for Java
Encrypt username and password for JNDI in Tomcat Server.xml and many other pages; however, I'm a bit stuck.
I first looked at extendind the BasicDataSourceFactory - but it seems that can't occur due to my using c3p0 CombinedPooledDataSource. I then looked at trying to create a c3p0 datasource wrapper by implementing PooledDataSource, Serializable and Referenceable but that didn't work either.
I read I could move the authentication to the server side by making auth="Container" => auth="Application". However, I'm not sure of how to implemet the rest of the pieces with my using Hibernate.
Any help would be great.
So, this will not be a high-security solution.
But an easy way around this is to make use of the fact that c3p0's "password" property is just a configurable c3p0 property, which can be set in a wide-variety of ways. So, you could create a c3p0.properties file and/or a c3p0-config.xml file, and set the password there. Alternatively, you could make sure that a System property c3p0.password is set when you run the JVM.
If you'll have multiple DataSources with different passwords, you'll need to use c3p0's named config feature, which means a c3p0-config.xml file.
c3p0 config (both c3p0.properties and c3p0-config.xml) files can be stuck at the top-level of a jar file in your application's effective CLASSPATH. (With tomcat, you have to be careful about distinctions between the web-app specific ClassLoader and more widely shared locations.) So, you can have your password embedded in a compressed jar file rather than a plain text file. Obviously, this is not secure: plaintext is just an "unzip" away. But it would prevent the password from being casually greppable and such.
Please see http://www.mchange.com/projects/c3p0/#configuration_files
Good luck!
This question is related to Weblogic 12c.
I have an EAR file that I want to deploy in various environments (dev, QA, pre-prod and prod). However, my application requires a username and a password (to connect to another server) and they're not the same across the four environments. I don't want to package 4 different property files in 4 different EAR files. I want a single generic EAR file. Beside, I don't want to handle the prod password during packaging.
Ideally, I'd like the admin of each environment to provide the appropriate username nad password for the environment. Unlike Tomcat, Jetty or JBoss(?), I think it's not possible for a WebLogic Admin to specify this information in a way that it will become available under the java:comp/env JNDI context.
How can an application obtain some admin-defined configuration strings from Weblogic?
BTW, it's not a username/password for a JDBC connection.
From what I understand, you need to change parameters based on the environment you are using right?
If you would like to override parameterss on the fly you can use WebLogic deployment plan concept.
Did you mean that you need to provide username/password to start-up the application?
If so, you may accomplish that by creating a script with WLST http://docs.oracle.com/cd/E15051_01/wls/docs103/config_scripting/using_WLST.html
As far as I know, the WebLogic way is to
Define your username/password as env-entry in the deployment descriptor
Deploy your application together with the plan.mxl whereas each environment admin maintains his own envrionemnt-specific version of the plan.xml
That way you get them into /comp/env/config
More details here: http://docs.oracle.com/cd/E11035_01/wls100/deployment/config.html
Only drawback known to me: plan.xml will always contain the unencrypted password but as the admin knows the password anyway and this is "his" file on "his" maschine that should be fine.