Änderungen von Dokument Härtung des Servers

Zusammenfassung

• Seiteneigenschaften (1 geändert, 0 hinzugefügt, 0 gelöscht)

Details

Seiteneigenschaften

Inhalt

...	...	@@ -1,17 +1,15 @@
1	1	{{content/}}
2	2
3		-Für eine höchstmögliche Sicherheit ist es empfohlen den Tomcat-Server zu härten. Bei diesem Verfahren werden alle unnötigen Zugriffe oder Informationen nach außen so weit wie möglich verborgen bzw. entfernt. So kann zum Beispiel bereits die Information über die konkrete Version des Servers einem potentiellen Angreifer Informationen über in dieser Version bekannte Sicherheits-Lücken liefern. Apache selbst bietet [[hier>>https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html]] eine Übersicht an zu beachtenden Sicherheitsaspekten. Es folgt eine Zusammenfassung der wichtigsten Teilaspekte.
	3	+Für eine höchstmögliche Sicherheit ist es empfohlen den Tomcat-Server zu härten. Bei diesem Verfahren werden alle unnötigen Zugriffe oder Informationen nach außen so weit wie möglich verborgen bzw. entfernt. So kann zum Beispiel bereits die Information über die konkrete Version des Servers einem potentiellen Angreifer Informationen über in dieser Version bekannte Sicherheits-Lücken liefern. Apache selbst bietet [[hier>>https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html]] eine Übersicht an zu beachtenden Sicherheitsaspekten. Es folgt eine Zusammenfassung der wichtigsten Teilpunkte.
4	4
5	5	== Regelmäßige Aktualisierung des Servers ==
6	6
7		-Ein regelmäßiges Aktualisieren des Servers sorgt dafür, dass ggf. gefundene Sicherheitslücken innerhalb des Servers geschlossen werden können. Es sollte immer im Sinne der IT sein sowohl den Tomcat als auch alle beteiligten Server sowohl auf Ebene der Anwendung als auch des Betriebssystems möglichst aktuell zu sein.
	7	+Ein regelmäßiges Aktualisieren des Servers sorgt dafür, dass ggf. gefundene Sicherheitslücken innerhalb des Servers geschlossen werden können. Es sollte immer im Sinne der IT sein sowohl den Tomcat als auch alle beteiligten Systeme sowohl auf Ebene der Anwendung als auch des Betriebssystems möglichst aktuell zu sein.
8	8
9		-
10	10	== Entfernen der Standard-Anwendungen ==
11	11
12		-Je nach gewählter Installation wird der Tomcat-Server mit ggf. mehreren Standard-Anwendungen ausgeliefert. Hierbei handelt es sich um Beispiele, Dokumentationen und den Server-Managern. Sollten diese nicht verwendet werden, ist es empfohlen diese zu entfernen. Hierbei genügt es die entsprechend nicht verwendeten Anwendungen aus //webapps//-Verzeichnis der Tomcat-Installation zu löschen. Diese Anwendungen bieten sonst ggf. selbst eigene Angriffsmöglichkeiten bzw. geben auch unnötig Informationen über den verwendeten Server preis. Standardmäßig handelt es sich hierbei um folgende Verzeichnisse:
	11	+Je nach gewählter Installation wird der Tomcat-Server mit ggf. mehreren Standard-Anwendungen ausgeliefert. Hierbei handelt es sich um Beispiele, Dokumentationen und Management-Tools. Sollten diese nicht verwendet werden, ist es empfohlen diese zu entfernen. Hierbei genügt es die entsprechenden Anwendungen aus dem //webapps//-Verzeichnis der Tomcat-Installation zu löschen. Diese Anwendungen bieten sonst ggf. selbst eigene Angriffsmöglichkeiten bzw. geben auch unnötig Informationen über den verwendeten Server preis. Standardmäßig handelt es sich hierbei um folgende Verzeichnisse:
13	13
14		-
15	15	* **docs**... Dokumentation des Servers
16	16	* **examples**... Beispiel-Anwendungen
17	17	* **host-manager**... Verwaltungsoberfläche für das Administrieren von Virtuellen Hosts
...	...	@@ -22,7 +22,7 @@
22	22
23	23	== Entfernen unnötiger Server-Informationen aus den Antwort-Headern ==
24	24
25		-Vor der vorausgesetzten Tomcat-Version 9 wurde bei standardmäßig bei jedem HTTP-Response ein Header //Server// mit der Information der verwendeten Tomcat-Version übertragen. Dies ist standardmäßig inzwischen nicht mehr der Fall und sollte aber auch bei allen anderen involvierten Servern (Load-Balancer, Firewall o.ä.) sichergestellt werden. Sollte dieser Header dennoch vom Tomcat übermittelt werden, kann der entsprechende Wert innerhalb des Connectors der //server.xml// (///Pfad/Zum/Tomcat/conf/web.xml//) definiert werden. Eine Überschreibung mit einem leeren Wert würde hierbei beispielhaft wie folgt aussehen:
	23	+Vor der vorausgesetzten Tomcat-Version 9 wurde bei standardmäßig bei jedem HTTP-Response der HTTP-Header //Server// mit der Information der verwendeten Tomcat-Version übertragen. Dies ist standardmäßig inzwischen nicht mehr der Fall und sollte aber auch bei allen anderen involvierten Servern (Load-Balancer, Firewall o.ä.) sichergestellt werden. Sollte dieser Header dennoch vom Tomcat übermittelt werden, kann der entsprechende Wert innerhalb des Connectors der //server.xml// (///Pfad/Zum/Tomcat/conf/web.xml//) definiert werden. Eine Überschreibung mit einem leeren Wert würde hierbei beispielhaft wie folgt aussehen:
26	26
27	27	{{code}}
28	28	<Connector... Server=" ">
...	...	@@ -30,7 +30,7 @@
30	30	</Connector>
31	31	{{/code}}
32	32
33		-Ebenso gibt es das Attribut //serverRemoveAppProvidedValues// welches benutzt werden kann um zu verhindern, dass dieser Header durch Anwendungen gesetzt werden kann. Eine beispielhafte Konfiguration sieht hierbei wie folgt aus:
	31	+Ebenso gibt es das Attribut //serverRemoveAppProvidedValues// welches benutzt werden kann um zu verhindern, dass dieser Header auch durch Anwendungen gesetzt werden kann. Eine beispielhafte Konfiguration sieht hierbei wie folgt aus:
34	34
35	35	{{code}}
36	36	<Connector... serverRemoveAppProvidedValues="true">
...	...	@@ -44,11 +44,11 @@
44	44
45	45	== Entfernen der Tomcat-Version aus Standard-Fehlerseiten ==
46	46
47		-Standardmäßig werden bei den Tomcat-Fehlerseiten unnötig Server-Informationen in Form der installierten Version preisgegeben. Um dies zu verhindern ist es möglich diesen Abschnitt der Fehlerseiten zu deaktivieren. Hierfür kann in der //server.xml// (///Pfad/Zum/Tomcat/conf/server.xml//) unter dem Knoten //Host// die Konfiguration des so genannten ErrorReportValve eingetragen bzw. angepasst werden. Sollte zum Beispiel weder die Server-Informationen noch Details zum eigentlichen Fehler ausgeliefert werden empfiehlt sich folgender Anpassung:
	45	+Standardmäßig werden bei den Fehlerseiten des Tomcat-Server unnötig Informationen in Form der installierten Version und Fehlerdetails preisgegeben. Um dies zu verhindern ist es möglich diese Abschnitte der Fehlerseiten zu deaktivieren. Hierfür kann in der //server.xml// (///Pfad/Zum/Tomcat/conf/server.xml//) unter dem Knoten //Host// die Konfiguration des so genannten //ErrorReportValve //eingetragen bzw. angepasst werden. Sollte zum Beispiel weder die Server-Informationen noch Details zum eigentlichen Fehler ausgeliefert werden empfiehlt sich folgender Anpassung:
48	48
49	49	{{code}}
50	50	<Host...>
51		- <Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false" showServerInfo="false"/>
	49	+ <Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false" showServerInfo="false"></Valve>
52	52	</Host>
53	53	{{/code}}
54	54
...	...	@@ -58,11 +58,11 @@
58	58
59	59	== Verwenden alternativer Fehlerseiten ==
60	60
61		-Eine weitere Erhöhung der Sicherheit bietet die Möglichkeit die Standard-Fehlerseiten des Servers komplett zu ändern. Hierfür können an den ErrorReportValve-Eintrag Attribute für einzelne HTTP-Fehlercodes und/oder eine Seite für alle nicht definierten Fehler angegeben werden. Hierfür wird das Attribute //errorCode.nnn// verwendet, wobei //nnn// dem HTTP-Fehlercode entspricht. wird dieser mit 0 verwendet, wird die angegebene Seite für alle nicht definierten Fehler benutzt. Ein Beispiel bei dem der HTTP-Status 404 (Ressource nicht gefunden) auf die Seite //404.html// und alle anderen Fehler auf //error.html// geleitet werden sieht hierbei wie folgt aus:
	59	+Eine weitere Erhöhung der Sicherheit bietet die Möglichkeit die Standard-Fehlerseiten des Servers komplett zu ändern. Hierfür können an den //ErrorReportValve//-Eintrag Attribute für einzelne HTTP-Fehlercodes und/oder eine Seite für alle nicht definierten Fehler angegeben werden. Hierfür wird das Attribute //errorCode.nnn// verwendet, wobei //nnn// dem HTTP-Fehlercode entspricht. wird dieser mit 0 verwendet, wird die angegebene Seite für alle nicht definierten Fehler benutzt. Ein Beispiel bei dem der HTTP-Status 404 (Ressource nicht gefunden) auf die Seite //404.html// und alle anderen Fehler auf //error.html// geleitet werden sieht hierbei wie folgt aus:
62	62
63	63	{{code}}
64	64	<Host...>
65		- <Valve className="org.apache.catalina.valves.ErrorReportValve" errorCode.404="webapps/404.html" errorCode.0="webapps/error.html"/>
	63	+ <Valve className="org.apache.catalina.valves.ErrorReportValve" errorCode.404="webapps/404.html" errorCode.0="webapps/error.html"></Valve>
66	66	</Host>
67	67	{{/code}}
68	68
...	...	@@ -70,4 +70,4 @@
70	70	Nach einer Anpassung ist der Neustart des Servers notwendig.
71	71	{{/info}}
72	72
73		-Zusätzlich bzw. alternativ können die Standardfehler meist auch durch zwischengeschaltete Server wie z.B. Load-Balancer oder Proxies behandelt werden. Dies ermöglicht eine standardisierteres Vorgehen.
	71	+Zusätzlich bzw. alternativ können die Standardfehler meist auch durch zwischengeschaltete Server wie z.B. Load-Balancer oder Proxies behandelt werden. Dies ermöglicht miest ein optisch standardisierteres Vorgehen und kann ebenso zusätzlich zur Anpassung innerhalb des Tomcats zum Einsatz kommen.