IT-weblog

All der tägliche Frust und Schweiß der IT-Branche

Kategorie: /dev/elop/java

Tomcat Versionsnummer verstecken

Findet sich an zwei Stellen wieder: Im HTTP-Header und in Fußzeilen bei Fehlermeldungen und muß auch an zwei Stellen angepasst werden.

Im server.xml bei dem Tag Connector ein neues Attribut

server=“Tomcat/9.99″

und für die Inhalte bei Fußzeilen etwas mehr Arbeit:

mkdir -p $CATALINA_HOME/lib/org/apache/catalina/util
cd $CATALINA_HOME/lib/org/apache/catalina/util
vi ServerInfo.properties
server.info=Apache Tomcat 9.99

Gerne auch abweichende Nummern zum obigen Tag um den Angreifer komplett zu vereumeln.

Schön so.

Tomcat mit SSL bestücken

Da mir OpenSSL irgendwie näher ist und mit dem Tomcat native Dingens das auch unterstützt ist, also mal eben ein Zertifikat erstellen lassen und mit ein paar Zeilen im server.xml eingebaut.

<Connector port=“443″ maxHttpHeaderSize=“8192″
maxThreads=“150″
enableLookups=“false“ disableUploadTimeout=“true“
acceptCount=“100″ scheme=“https“ secure=“true“
SSLEnabled=“true“
SSLCertificateChainFile=“${catalina.base}/conf/ssl/sub.class1.server.ca.pem“
SSLCertificateFile=“${catalina.base}/conf/ssl/cert.pem“
SSLCertificateKeyFile=“${catalina.base}/conf/ssl/key.pem“ />

Allerdings dürfte das nicht alles gewesen sein. Denn ein schneller Test bei SSLlabs vergibt die Note F und man ist sicherheits-technisch durchgefallen:

This server supports anonymous (insecure) suites (see below for details). Grade set to F.

Wer auch immer die Default-Werte beim Tomcat zu verantworten hat, darf sich die high5 bei mir persönlich abholen.

Also zwei Zeilen mehr rein in das Connector-Tag im server.xml:

SSLHonorCipherOrder=“true“
SSLCipherSuite=“ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW“

Das ergibt im Test schon mal Note B, aber es ist immernoch Compression aktiviert, die auch nicht gut tut. Also noch eine Zeile mehr hinein:

SSLDisableCompression=“true“

Nun gibt es Note A (100,90,80,90 für Eingeweihte) und auch die ForwardSecrecy wird angeboten.

Also alles nicht mal eben zu realisieren, man muß schon jeden Schritt testen.

Schade drum.

Tomcat 7 native interface

Bei debian 7 in etwa so:

root@j1:~#apt-get install libapr1 libaprutil1 libapr1-dev libssl-dev
root@j1:~# cd src
root@j1:~/src# cp /opt/tomcat/bin/tomcat-native.tar.gz .
root@j1:~/src# tar xzf tomcat-native.tar.gz
root@j1:~/src# cd tomcat-native-1.1.29-src/jni/native/
root@j1:~/src/tomcat-native-1.1.29-src/jni/native# JAVA_HOME=/opt/java
root@j1:~/src/tomcat-native-1.1.29-src/jni/native# export JAVA_HOME
root@j1:~/src# ./configure –with-apr=/usr/bin/apr-1-config
root@j1:~/src# make
root@j1:~/src# make install
root@j1:~/src# ln -s /usr/local/apr/lib/libtcnative-1.so /usr/lib/libtcnative-1.so

Und wenn dann Tomcat neu hochfährt, steht im catalina.out logfile hoffenlich:

INFO: Loaded APR based Apache Tomcat Native library 1.1.29 using APR version 1.4.6.

Schön so.

Tomcat AJP bind auf localhost

Warum sollte der Port 8009 im Normalfall für die Welt offen stehen, wenn es auch anders geht?

Also einfach dort wo auf Port 8009 gehört wird das Attribut address=“::1″ ergänzt und den Dienst neu gestartet, schon klappt es.

Schön so.

java, tomcat, authbind und IPv6

Entgegen den meisten ergooglebaren Gerüchten ist das inzwischen kein Problem mehr. Authbind beherrscht bei einer normalen Debian 7.3 Installation von sich aus IPv6, eben selbst probiert.

Schön so.

JaStaCry – Stapelbare Verschlüsselung

Eine erste Version von JaStaCry liegt ab heute bereit.

Verschlüsselung‬ für technisch versierte, die einzelnen Algorithmen nicht mehr trauen. Quellen liegen u.a. auf sourceforge rum.

Tomcat und SSL-Qualität

Wenn der Standard Tomcat in der SSL-Kontrolle schlecht abschneidet, dann muß man anscheinend erst mal das APR dazunehmen und dieses auch noch um einen Aufruf erweitern.

In tomcat-native-1.1.24-src/jni/native/src/sslcontext.c gibg es dazu diese Ergänzung in der Funktion setCipherSuite ab etwa Zeile 278:

sslcontext.c

270a271,278

>
> if (!SSL_CTX_set_options(c->ctx, SSL_OP_CIPHER_SERVER_PREFERENCE)) {
> char err[256];
> ERR_error_string(ERR_get_error(), err);
> tcn_Throw(e, „Unable to configure permitted cipher order (%s)“, err);
> rv = JNI_FALSE;
> }
>

und der passende Aufruf im server.xml dazu lautet auszugsweise:

<Listener className=“org.apache.catalina.core.AprLifecycleListener“ SSLEngine=“on“ />

<Connector port=“443″ protocol=“HTTP/1.1″ SSLEnabled=“true“
SSLCertificateFile=“${catalina.base}/conf/ssl/ssl.crt“
SSLCertificateKeyFile=“${catalina.base}/conf/ssl/ssl.key“
SSLCACertificateFile=“${catalina.base}/conf/ssl/ca.pem“
SSLCertificateChainFile=“${catalina.base}/conf/ssl/sub.class1.server.ca.pem“
maxThreads=“150″ scheme=“https“ secure=“true“
SSLCipherSuite=“RC4-SHA:HIGH:!ADH“
clientAuth=“false“ sslProtocol=“TLS“ />

Damit kriege ich nun die gleiche gute Punktzahl (A85) wie ein normaler Apache für PHP und das alles.

Läuft unter debian mit Tomcat 7 und Java 7 nun problemlos.

© 2017 IT-weblog

Theme von Anders NorénHoch ↑