IT-weblog

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

Schlagwort: tomcat

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.

Reload-feste Webnavigation

Klar, der Fehler sitzt immer vor der Tastatur. Aber man kann es auch unnötig gefährlich machen. Schließlich soll die Technik dem Menschen das Leben vereinfachen und nicht umverkehrt.

Gerade wieder ein Klassiker: Ich schaue mir den Status vom Tomcat im Browser an, drücke immer mal wieder reload, um die Zahl des Sessions zu verfolgen. Aber irgendwie war es anders als sonst. Die Sessions blieben wieder auf null, oder waren kurz da und wieder weg. Warum?

Bis ich mal den Status der Webapplication gesehen hatte: STOPPED! Hilfe, was war das?

Da stand doch allen ernstes in der URL des Monitoring noch der Befehl reload drinnen. Und mit jedem Browser-Reload wurde auch die Webapplication neu durchgestartet, alle Sessions verworfen und der Server unnötig geärgert. Das ging dann so weit, daß die Anwendung nicht mehr hochfuhr.

Welcher Idiot legt Aktionen auf eine URL und leitet nicht anschließend weiter? In allen Anwendungen von mir wird so eine URL-Aktion ausgeführt, dann aber via Redirect auf die Ergebnisseite gesprungen. Auf der darf man dann reloaden so oft an will, es passiert nichts schlimmes mehr. Man stelle sich das mal auf Bestellseiten vor: Bei jedem Ausdrucken wird neu abgebucht, oder wie? Da hat es doch wieder einer nicht gekonnt.

Schade drum.

© 2017 IT-weblog

Theme von Anders NorénHoch ↑