| ... |
... |
@@ -1,6 +1,8 @@ |
| 1 |
1 |
{{info}} |
| 2 |
|
-Die {{formcycle/}} Versionen 7.0.0 bis 7.0.6 verwenden eine Version von Log4j, welche die am 10.12.2021 bekannt gewordene Sicherheitslücke enthält. Momentan können wir noch nicht abschätzen, inwieweit diese in Kombination mit {{formcycle/}} ausgenutzt werden kann. In der Zwischenzeit empfehlen daher, die [[vom Hersteller>>https://logging.apache.org/log4j/2.x/security.html]] und [[vom BSI>>https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile]] für die verwendete Log4j-Version empfohlene Mitigation umzusetzen und für den verwendeten Servlet-Container die Option {{code language="none"}}-Dlog4j2.formatMsgNoLookups=true{{/code}} in den Umgebungsvariablen zu setzen. |
|
2 |
+Die {{formcycle/}} Versionen 7.0.0 bis 7.0.6 verwenden eine Version von Log4j, welche die am 10.12.2021 bekannt gewordene Sicherheitslücke enthält. Momentan kennen wir kein Szenario, bei der diese Sicherheitslücke in {{formcycle/}} ausgenutzt werden kann. In der Zwischenzeit empfehlen wir, auf die {{formcycle/}} [[Version 7.0.7>>doc:Blog.FORMCYCLE 707.WebHome]] zu aktualisieren, die eine neue Version von Log4j verwendet, welche die Sicherheitslücke nicht mehr enthält. |
| 3 |
3 |
|
|
4 |
+Falls eine Aktualisierung auf die neue {{formcycle/}} Version nicht möglich ist, empfehlen wir, die Mitigation umzusetzen, welche [[vom Hersteller>>https://logging.apache.org/log4j/2.x/security.html]] und [[vom BSI>>https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile]] für die in den möglicherweise betroffenen {{formcycle/}} Versionen verwendete Log4j-Version empfohlen wird. Diese sieht vor, für den verwendeten Servlet-Container die Option {{code language="none"}}-Dlog4j2.formatMsgNoLookups=true{{/code}} in den Java-Optionen zu setzen. |
|
5 |
+ |
| 4 |
4 |
Für einen unter Windows laufenden Apache Tomcat kann dies beispielsweise im //Tomcat Monitor// an folgender Stelle getan werden: |
| 5 |
5 |
[[image:tomcat_log4j_settings.png||width="350"]] |
| 6 |
6 |
|
| ... |
... |
@@ -7,7 +7,7 @@ |
| 7 |
7 |
Unter Linux werden Umgebungsvariablen bei Apache Tomcat Installationen üblicherweise in der Datei {{code language="none"}}setenv.sh{{/code}} gesetzt. Diese könnte nach dem Setzen des Parameters dann zum Beispiel den folgenden Inhalt für die Java-Optionen aufweisen: |
| 8 |
8 |
{{code language="none"}}export JAVA_OPTS="-Dfile.encoding=UTF-8 -Xms1024m -Xmx4096m -Dlog4j2.formatMsgNoLookups=true"{{/code}} |
| 9 |
9 |
|
| 10 |
|
-Bei der Verwendung von anderen Servlet-Containern als dem Apache Tomcat konsultieren Sie bitte die Dokumentation, an welcher Stelle dieser Parameter übergeben werden kann. |
|
12 |
+Bei der Verwendung von anderen Servlet-Containern als dem Apache Tomcat konsultieren Sie bitte die Dokumentation dieses Servlet-Containers, an welcher Stelle dieser Parameter übergeben werden kann. |
| 11 |
11 |
{{/info}} |
| 12 |
12 |
|
| 13 |
13 |
{{content/}} |
| ... |
... |
@@ -48,7 +48,7 @@ |
| 48 |
48 |
|
| 49 |
49 |
=== Härtung der Server === |
| 50 |
50 |
|
| 51 |
|
-Neben dem eigentlichen Server auf dem {{formcycle/}} betrieben wird, ist es empfohlen alle bei der Kommunikation relevanten Server soweit wie möglich zu härten. Dies bedeutet vor allem, dass neben dem Einspielen regelmäßiger Sicherheitsupdates auch alle unnötigen Zugriffe deaktiviert oder verhindert werden sollten. Auch ist dem Prinzip des „Information hiding“ zu folgen. Dies bedeutet, dass jegliche nicht nötige Information der Infrastruktur nach außen versteckt werden sollte. Hintergrund ist, dass diese sonst Angreifern Hinweise auf mögliche Angriffsmöglichkeiten in Form von zum Beispiel eingesetzten Software-Versionen bietet. Typtische Quellen für solche Informationen sind hierbei folgende: |
|
53 |
+Es ist zu empfehlen, dass neben dem eigentlichen Server, auf dem {{formcycle/}} betrieben wird, alle bei der Kommunikation relevanten Server soweit wie möglich zu härten. Dies bedeutet vor allem, dass neben dem Einspielen regelmäßiger Sicherheitsupdates auch alle unnötigen Zugriffe deaktiviert oder verhindert werden sollten. Auch ist dem Prinzip des „Information hiding“ zu folgen. Dies bedeutet, dass jegliche nicht nötige Information der Infrastruktur nach außen versteckt werden sollte. Hintergrund ist, dass diese sonst Angreifern Hinweise auf mögliche Angriffsmöglichkeiten in Form von zum Beispiel eingesetzten Software-Versionen bietet. Typtische Quellen für solche Informationen sind hierbei folgende: |
| 52 |
52 |
|
| 53 |
53 |
* Rückgabe des verwendeten Servers innerhalb von HTTP-Headern. Dies geschieht meist mit Versionsnummern welche den Patch-Stand des Servers preisgibt |
| 54 |
54 |
* Ausgabe der Server-Informationen auf Standard-Fehlerseiten |
