Date: Fri, 29 Mar 2024 02:42:34 +0100 (CET) Message-ID: <384696827.1355.1711676554766@nm-docs> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1354_232576437.1711676554766" ------=_Part_1354_232576437.1711676554766 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Scripts
The following are the script files used in this hardening guide:
The default shipping configuration of Teamwork Cloud is not a hardened c= onfiguration.
When hardening an installation, there are variables that can render the = installation inoperative, such as incompatibility of the supported ciphers = in a certificate and the supported ciphers in the hardened configuration.= p>
Furthermore, the default configurations assume that the deployment is be= hind a secure infrastructure, and therefore required ports are globally all= owed.
Since some of Teamwork Cloud's infrastructure relies on available compon= ents, newly discovered vulnerabilities need to be mitigated during the life= -cycle of the installation.
Below, we will cover the potentially exploitable vulnerabilities of the = different components, as well as various steps to mitigate depending on the= policies of the deploying organization.
When installing on Linux using our deployment scripts, all of the ports = required by Cassandra for inter-node communication, as well as for the Team= work Cloud nodes to communicate with Cassandra nodes are opened globally. T= his configuration is deployed mostly to facilitate testing of the environme= nt upon installation, prior to taking any measures to harden the installati= on. If we check the firewall upon installation, we will see an output simil= ar to the one below:
# firewa= ll-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: cassandra lmadmin ssh twcloud ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
In our deployment, we create a firewall service definition to facilitate= the management of the rules. This file is located in /etc/firewal= ld/services/cassandra.xml, and contains the following:
# cat /e= tc/firewalld/services/cassandra.xml <?xml version=3D"1.0" encoding=3D"utf-8"?> <service version=3D"1.0"> <short>cassandra</short> <description>cassandra</description> <port port=3D"7000" protocol=3D"tcp"/> <port port=3D"7001" protocol=3D"tcp"/> <port port=3D"9042" protocol=3D"tcp"/> <port port=3D"9160" protocol=3D"tcp"/> <port port=3D"9142" protocol=3D"tcp"/> </service>
The first step in securing Cassandra is to limit traffic only to Cassand= ra and Teamwork Cloud Nodes. In the example below, we have a single node Ca= ssandra/Teamwork Cloud installation, with its IP address set to 10.254.254.= 56.
As can be seen below, the firewall configuration has been modified to on= ly allow access from itself.
# firewa= ll-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: eth0 sources: services: lmadmin ssh twcloud ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family=3D"ipv4" source address=3D"10.254.254.56" service name= =3D"cassandra" accept
The process to follow is to remove the general firewall allowance to the= Cassandra service. After that, we want to ensure that if direct port rule = assignments were made, they are removed. Finally, we want to create a= set of rich rules which will allow access only to the required nodes.
If your deployment consists of a single-node or multi-node cluster where= both Teamwork Cloud and Cassandra reside on the same nodes, we can automat= e this process by using the following script.
#!/bin/b= ash echo "Hardening Cassandra Ports" echo "Creating Cassandra firewall service profile" cat <<EOF | tee /etc/firewalld/services/cassandra.xml &> /de= v/null <?xml version=3D"1.0" encoding=3D"utf-8"?> <service version=3D"1.0"> <short>cassandra</short> <description>cassandra</description> <port port=3D"7000" protocol=3D"tcp"/> <port port=3D"7001" protocol=3D"tcp"/> <port port=3D"9042" protocol=3D"tcp"/> <port port=3D"9160" protocol=3D"tcp"/> <port port=3D"9142" protocol=3D"tcp"/> </service> EOF echo "Removing existing firewall rules on the cassandra ports or service pr= ofile" sleep 5 zone=3D$(firewall-cmd --get-default) &> /dev/null firewall-cmd --zone=3D$zone --remove-port=3D7000/tcp --permanent &>= /dev/null firewall-cmd --zone=3D$zone --remove-port=3D7001/tcp --permanent &>= /dev/null firewall-cmd --zone=3D$zone --remove-port=3D7199/tcp --permanent &>= /dev/null firewall-cmd --zone=3D$zone --remove-port=3D9042/tcp --permanent &>= /dev/null firewall-cmd --zone=3D$zone --remove-port=3D9160/tcp --permanent &>= /dev/null firewall-cmd --zone=3D$zone --remove-port=3D9142/tcp --permanent &>= /dev/null firewall-cmd --zone=3D$zone --remove-service=3Dcassandra --permanent &= > /dev/null echo "Creating ruch rules for Cassandra nodes discovered via nodetool gossi= pinfo" set -f local_list=3D($(nodetool gossipinfo | grep '/' | cut -f 2 -d /)) set +f for i in "${local_list[@]}" ; do cmd=3D" firewall-cmd --zone=3D$zone --add-rich-rule=3D'rule family= =3D\"ipv4\" source address=3D\"$i\" service name=3D\"cassandra\" accept' --= permanent &> /dev/null" echo $cmd eval $cmd done firewall-cmd --reload &> /dev/null
The above script is structured in such a way that it will output the ric= h rule commands to the screen to facilitate copying and modifying to add no= des, such as would be the case if you have Teamwork Cloud nodes that are no= t part of the Cassandra cluster.
The default installation comes= bundled with AdoptOpenJDK (build 12+33) The above script sho= uld be executed on all nodes of a multi-node Cassandra cluster, with all no= des being in an operational state.
Windows Users: Create firewall rules restricting access on the aforement= ioned ports only to authorized nodes - Cassandra nodes and Teamwork Cloud N= odes.
Teamwork Cloud presently does not support Multi-DC replication strategie= s. As such, the environment must be configured with SimpleStrategy.
By default, Cassandra is deployed with the AllowAllAuthenticator. This a= uthenticator, as the name implies, is an anonymous authenticator which perf= orms no checks.
If you require authenticated connections, you will need to make changes = to your cassandra.yaml and change the authenticator to Pas= swordAuthenticator. If you are running a multi-node Cassandra cluster, you = need to change the replication factor of the system_auth keyspace.
Detailed instructions can be found at https://docs.datastax.com/en/ddacsecuri= ty/doc/ddacsecurity/secureConfigNativeAuth.html.
After making the changes to Cassandra, you will need to update the Teamw= ork Cloud configurations to utilize authentication.
The required changes are as follows:
= # Enable this section to enable the cassandra authenticatio= n. authentication-enabled =3D true username =3D newcassandrauser password =3D newcassandrapassword
cassandr= a.username=3Dnewcassandrauser cassandra.password=3Dnewcassandrapassword
where newcassandrauser and newcassandrapassword corres= pond to the user and credentials which you configured in Cassandra.
To enable SSL authentication for Cassandra
Set the following property in th=
e authserver.properties file:
cassandr= a.ssl.enabled=3Dtrue
Starting from Teamwork Cloud Version 2021x and onwards, encrypted commun= ication with Cassandra is supported. To achieve this, the configuration of secure SSL communication= is needed.
Open source Cassandra does not support encryption at rest. If you requir= e encryption at rest, you need to use a disk encryption layer.
Teamwork Cloud consists of 3 Java-based services - Teamwork Cloud (TWClo= ud), Authserver (authserver), and WebApp (webapp).
TWCloud and Authserver require Java 11 (its location varies depending on=
how it was deployed), whereas WebApp uses a bundled Java 15, located in
Therefore, in order to harden these services, we must begin by hardening= the JVM. The default settings for the JVM are located in java.secu= rity.
The process of hardening the JVM requ=
ires making some changes to the java.security
However, we can place our modifications in our own file, and simply pass= a parameter to the JVM upon invocation so that it will apply our changes.<= /p>
For example, we can create a file /home/twcloud/twc.java.security, and pass a parameter to the JVM in the form of -Djava.security= .properties=3D/home/twcloud/twc.java.security
Our hardened security settings are as shown below:
jdk.tls.= disabledAlgorithms=3DSSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, DH keySiz= e < 2048, \ EC keySize < 224, 3DES_EDE_CBC, anon, RSA keySize < 2048, SHA1, D= HE, NULL jdk.tls.ephemeralDHKeySize=3D2048 jdk.tls.rejectClientInitiatedRenegotiation=3Dtrue
To apply these settings we need to make changes in 3 locations.
For the Teamwork Cloud service, under Linux, you need to edit <in= stall_root>/jvm.options and add a line as shown below:
. . -Dorg.jboss.netty.epollBugWorkaround=3Dtrue -Dio.netty.epollBugWorkaround=3Dtrue -Djava.security.properties=3D/home/twcloud/twc.java.security
On Windows, you need to edit the registry k= ey Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Apache Softwar= e Foundation\Procrun 2.0\TeamworkCloud\Parameters\Java\Options and app= end the setting pointing to your security overrides to the bottom of the se= ttings.
For the Authserver service, you need to edit <install_root>/Au= thServer/authserver-run by inserting the directive before the call to = the authentication-server-XXXXXX.jar as shown below. Pleas= e note that you only need to insert line 6 into the file:
$JAVA -j= ar \ -Duser.home.dir=3D$TWCLOUD_OWNR_HOME \ -Dfile.encoding=3Dutf-8 \ -Dauthentication-config=3D./config \=20 -Dspring.config.additional-location=3D./config/authserver.properties \ -Djava.security.properties=3D/home/twcloud/twc.java.security \ authentication-server-XXXXXX.jar "$@"
On Windows, you need to edit the registry key Computer= \HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Apache Software Foundation\Procrun= 2.0\AuthServer\Parameters\Java\Options and append the setting = pointing to your security overrides to the bottom of the settings.= p>
For the Webapp service, under Linux you need to edit <install_roo=
t>/WebAppPlatform/bin/setenv.sh and add the directive to the
JVM_OPTS= =3D"-server -XX:+UseParallelGC -Xms4096M -Xmx8192M -Djava.security.propert= ies=3D/home/twcloud/twc.java.security"
On Windows, you need to edit the registry k= ey Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Apache Softwar= e Foundation\Procrun 2.0\WebApp\Parameters\Java\Options and append the= setting pointing to your security overrides to the bottom of the settings.=
By default, the TWCloud service activates a JMX remote port to faci= litate application monitoring. The default configuration does not contain a= ny form of authentication.
On Linux, the configuration is located in <install_root>/jvm.o= ptions.
On Windows, it is located in registry key Computer\HKEY_LO= CAL_MACHINE\SOFTWARE\WOW6432Node\Apache Software Foundation\Procrun 2.0\Tea= mworkCloud\Parameters\Java\Options.
-Dcom.su= n.management.jmxremote -Dcom.sun.management.jmxremote.port=3D2468 -Dcom.sun.management.jmxremote.rmi.port=3D2468 -Dcom.sun.management.jmxremote.local.only=3Dfalse -Dcom.sun.management.jmxremote.authenticate=3Dfalse -Dcom.sun.management.jmxremote.ssl=3Dfalse
These settings can be removed, thereby removing JMX remote access.
If you would like to allow remote JMX access but require authentication,= you can do so by adding settings. For complete documentation, please refer= to the Java documentation.
As an example, the below configuration adds password authentication:
-Dcom.su= n.management.jmxremote -Dcom.sun.management.jmxremote.port=3D2468 -Dcom.sun.management.jmxremote.rmi.port=3D2468 -Dcom.sun.management.jmxremote.local.only=3Dfalse -Dcom.sun.management.jmxremote.authenticate=3Dtrue -Dcom.sun.management.jmxremote.password.file=3D/home/twcloud/jmx.password -Dcom.sun.management.jmxremote.access.file=3D/home/twcloud/jmx.access -Dcom.sun.management.jmxremote.ssl=3Dfalse
As can be seen, we are pointing to a set of files (/home/twcloud/jmx= .password and /home/twcloud/jmx.access) that control who= can access these files.
The vulnerability vector is one whereby JMX could be exploited to execut= e code. To prevent this, we allow only an authenticated user (jmx.pas= sword) who has read-only rights (jmx.access).
monitori= ng DqzbksT4ET
monitori= ng readonly
In this example, we created a user (monitoring) with a password (DqzbksT= 4ET), who can only read values via Remote JMX, but cannot write or execute = anything via JMX.
The password and access files have a very stringent ownership requiremen= t. They need to be owned by the user running the process and be accessible = exclusively to that user.
For example, in our default installation, the TWCloud user is running th= e TWCloud service. Therefore, the files need to be owned by TWCloud, and ha= ve full rights (rwx) by TWCloud, and only TWCloud.
# ll jmx.*
-rwx------. 1 twcloud twcloud 20 Mar 16 15:11 jmx.access
-rwx------. 1 twcloud twcloud 26 Apr 21 10:41 jmx.password
The Webapp Platform (webapp), as deployed by our installer, runs on a bu= ndled Apache Tomcat. As such, best practices for hardening Apache Tomcat sh= ould be followed.
Although we have already constrained ciphers and protocols at the JVM le= vel, it is best practice to do so at the Tomcat configuration level. We als= o need to address issues such as secure cookies, disable XSS on foreign sit= es, and also remove default directories published as part of the defau= lt installation. The official Tomcat documentation covers a large portion o= f this (recommended reading) - = https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html. Additiona= lly, there are a plethora of documents online covering all aspects of secur= ing Tomcat to OWASP standards.
There are various changes that can be made to <install_root>/W= ebAppPlatform/conf/server.xml in order to harden the system.
The first step (do not do this if running on Windows) is to disable the = shutdown port.
For this, you need to change:
<Serv= er port=3D"8005" shutdown=3D"SHUTDOWN">
to
<Serv= er port=3D"-1" shutdown=3D"SHUTDOWN">
The next step is to disable the AJP connect= or unless you specifically intend to use it.
For this, you need to change:
<!-- = Define an AJP 1.3 Connector on port 8009 --> <Connector port=3D"8009" protocol=3D"AJP/1.3" redirectPort=3D"8443" = />
to
<!= -- Define an AJP 1.3 Connector on port 8009 --> <!-- <Connector port=3D"8009" protocol=3D"AJP/1.3" redirectPort=3D"8443" /= > -->
The next step is to disable the redirection= on port 8080.
For this, you need to change:
<= Connector executor=3D"tomcatThreadPool" port=3D"8080" protocol=3D"HTTP/1.1" connectionTimeout=3D"20000" redirectPort=3D"8443" />
to
<!= -- <Connector executor=3D"tomcatThreadPool" port=3D"8080" protocol=3D"HTTP/1.1" connectionTimeout=3D"20000" Server=3D" " redirectPort=3D"8443" /> -->
Finally, we want to prevent our instance from advertising what ser= ver is being used in the event that an error is encountered.
For this, you need to go to the very bottom of the file and add the foll= owing, right above the closing </Host> tag.
= <!-- Suppress server name on internal error pages --> <Valve className=3D"org.apache.catalina.valves.ErrorReportValve"= showReport=3D"false" showServerInfo=3D"false" /> </Host>
Having completed the configuration of server.xml, we will now proceed to= configure <install_root>/WebAppPlatform/conf/web.xml.<= /p>
We need to ensure that cookies are constrai= ned to HTTPS.
<!-= - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Default Sess= ion Configuration =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -->= ; <!-- You can set the default session timeout (in minutes) for all newl= y --> <!-- created sessions by modifying the value below. = --> <session-config> <session-timeout>30</session-timeout> =09=09<cookie-config> =09=09<http-only>true</http-only> =09=09<secure>true</secure> =09=09</cookie-config> </session-config>
You only need to insert the following lines:
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>
Having made the necessary changes to the configuration files, we will no= w proceed to remove all of the default applications in the tomcat distribut= ion, which could expose our installation to external vulnerabilities.
If we look at a directory of <install_root>/WebAppPlatform/web= apps, we will see the following:
drwxrwxr= -x. 14 twcloud twcloud 4096 Apr 15 14:39 docs drwxrwxr-x. 6 twcloud twcloud 83 Apr 15 14:39 examples drwxrwxr-x. 5 twcloud twcloud 87 Apr 15 14:39 host-manager drwxrwxr-x. 5 twcloud twcloud 103 Apr 15 14:39 manager drwxrwxr-x. 3 twcloud twcloud 283 Apr 15 14:39 ROOT drwxr-x---. 8 twcloud twcloud 117 Apr 15 14:47 webapp -rwxrwxr-x. 1 twcloud twcloud 67742880 Oct 31 17:56 webapp.war
As you can see, in addition to webapp.w= ar and the webapp directory, there are additional directories= , containing applications, which could potentially be exploited.
You want to remove docs, examples, host-manag= er, manager, and ROOT.
When you remove the ROOT application directory, accessing https://ip_a= ddress:8443 will no longer display the Apache Tomcat default landing pa= ge.
Our installers deploy with a given version of Apache Tomcat. As vulnerab= ilities are exposed in Tomcat, you may be required by your organization to = upgrade to a specific version.
The "code" of tomcat is the compilation of the jar files residing in <instal_dir>/WebAppPlatform/bin and <instal_dir>= /WebAppPlatform/lib.
In order to "slip-stream" an upgrade without having to fully replace the= Tomcat installation, you can replace the existing *.jar files in these dir= ectories with the ones from the new one.
Before doing this, you will want to make copies of these directories so = you can easily revert back in case of an incompatibility with the new versi= on.
Under Linux, assuming that you have access to the internet from the serv= er, you can use the script below to automatically upgrade your instance to = the target version.
#!/bin/b= ash ########################################################## # Upgrade Tomcat Version used by WebApp Platform # CATIA No Magic DevOps Team # ################################ # This script utilizes rsync, so we will install it via yum # If you are offline you need to put required installer file in the same lo= cation with this script # Edit default version if you can't input it during upgrade DEFAULT_VERSION=3D9.0.63 ########################################### # # DO NOT MODIFY ANYTHING BEYOND THIS POINT # ########################################### echo "" echo "---------------------------------------------------------------------= -------" echo "This script utilizes rsync, so we will install it via yum." echo "Please ensure rsync is on the system if thes are no posibility to use= yum package manager" echo "" echo "---------------------------------------------------------------------= -------" read -e -p "Please enter the tomcat version you would like to use. [default= is: $DEFAULT_VERSION] : " TOMCAT_VERSION echo "---------------------------------------------------------------------= -------" echo "" TOMCAT_VERSION=3D"${TOMCAT_VERSION:-$DEFAULT_VERSION}" echo "Tomcat will be upgraded to: "$TOMCAT_VERSION "version." WEBAPP_ROOT=3D$(cat /etc/systemd/system/webapp.service | grep CATALINA_HOME= _WEBAPP | cut -f 3 -d '=3D') WEBAPP_OWNER=3D$(stat -c "%U:%G" $WEBAPP_ROOT) ##################################### # Install rsync yum install rsync -y -q #################################### # Setting up script variables MAJOR_VERSION=3D$(echo $TOMCAT_VERSION | cut -d . -f 1) TOMCAT_DOWNLOAD=3Dhttps://archive.apache.org/dist/tomcat/tomcat-$MAJOR_VERS= ION/v$TOMCAT_VERSION/bin/apache-tomcat-$TOMCAT_VERSION.tar.gz TOMCAT_TAR=3D$(basename $TOMCAT_DOWNLOAD) TOMCAT_DIR=3D$(basename $TOMCAT_TAR .tar.gz) ##################################### # Begin deployment wget $TOMCAT_DOWNLOAD [ ! -e "${TOMCAT_TAR}" ] && echo "File does not exist ! Check the f= ile name or internet connection and try again." && exit|| echo "Fil= e $TOMCAT_TAR exists" tar -xf $TOMCAT_TAR rsync -av $TOMCAT_DIR/bin/*.jar $WEBAPP_ROOT/bin/ rsync -av $TOMCAT_DIR/lib/*.jar $WEBAPP_ROOT/lib/ #################################### # Ensure proper ownership of files chown -R $WEBAPP_OWNER $WEBAPP_ROOT/bin $WEBAPP_ROOT/lib #################################### # Remove foder with extracted files rm -fr $TOMCAT_DIR echo "" echo "Upgrade completed successfully."
The script provided above may stop working if the Apache Tomcat distribu= tion changes the methodology used in storing the tarfiles.
The default installation comes bundled with AdoptOpenJDK (build 15.= 0.2+7).
Webapp can run with Java 15.0.2.
If you wish to use it instead of the bundled version, it is located in <= em><installation_dir>/WebAppPlatform/jre.
#!/bin/b= ash ########################################################## # Upgrade JDK in NoMagic Webapp Platform to a newer OpenJDK # Benjamin Krajmalnik (benjamin.krajmalnik@3ds.com) ########################################################## ### JRE_DOWNLOAD contains the download URL to the target OpenJDK tar archi= ve ### The example below upgrades the JDK to OpenJDK 14.0.1 JRE_DOWNLOAD=3Dhttps://download.java.net/java/GA/jdk14.0.1/664493ef4a6946b1= 86ff29eb326336a2/7/GPL/openjdk-14.0.1_linux-x64_bin.tar.gz ##### Do not modify below this point ###### yum install wget -y -q JRE_HOME=3D$(cat /etc/systemd/system/webapp.service | grep JRE_HOME | cut -= f 3 -d '=3D') JRE_OWNER=3D$(stat -c "%U:%G" $JRE_HOME) JRE_TAR=3D$(basename $JRE_DOWNLOAD) mkdir _tmp cd _tmp ## Download OpenJDK 14.0.1 wget $JRE_DOWNLOAD ## Remove current JRE_HOME rm -fr $JRE_HOME ## Extract OpenJDK mkdir -p $JRE_HOME tar -xf $JRE_TAR -C $JRE_HOME --strip-components=3D1 chown -R $JRE_OWNER $JRE_HOME cd .. rm -fr _tmp