UTM/Extras/ipsec fehleranalyse - Versionsgeschichte

Lauritzl am 6. März 2024 um 06:38 Uhr

2024-03-06T06:38:27Z

← Nächstältere Version		Version vom 6. März 2024, 08:38 Uhr
Zeile 6:		Zeile 6:
	{{var \| neu--Layoutaktualisierung		{{var \| neu--Layoutaktualisierung
	\| Layoutaktualisierung		\| Layoutaktualisierung
	\| }}		\| Layout update }}

	</div><div class="new_design"></div>{{TOC2}}~~<!--~~{{Select_lang}}~~-->~~		</div><div class="new_design"></div>{{TOC2}}{{Select_lang}}
	{{Header\|02.2024\|		{{Header\|02.2024\|
	* {{#var:neu--Layoutaktualisierung}}		* {{#var:neu--Layoutaktualisierung}}
Zeile 192:		Zeile 192:
	{{code\|tcpdump -i A1 host 10.4.0.10 -n}}<br>		{{code\|tcpdump -i A1 host 10.4.0.10 -n}}<br>

	{{#var:~~Nurnoch~~ NextGen UTM--desc}}<br>		{{#var:Nur noch NextGen UTM--desc}}<br>

	{{code\|<nowiki> 11:32:11.592831 IP 10.0.0.10 > 10.4.0.10: ICMP echo request, id 512, seq 1, length 40		{{code\|<nowiki> 11:32:11.592831 IP 10.0.0.10 > 10.4.0.10: ICMP echo request, id 512, seq 1, length 40

Lauritzl am 20. Februar 2024 um 15:27 Uhr

2024-02-20T15:27:50Z

Änderungen zeigen

Lauritzl am 11. März 2022 um 08:29 Uhr

2022-03-11T08:29:20Z

← Nächstältere Version		Version vom 11. März 2022, 10:29 Uhr
Zeile 1:		Zeile 1:
	{{DISPLAYTITLE: Fehleranalyse mit tcpdump }}		{{DISPLAYTITLE: Fehleranalyse mit tcpdump }}

	~~Letze~~ Anpassung zur Version: '''11.7.9'''		Letzte Anpassung zur Version: '''11.7.9'''
	<br>		<br>
	Vorherige Versionen: -		Vorherige Versionen: -
Zeile 34:		Zeile 34:

	===Level 3: Linux-Shell===		===Level 3: Linux-Shell===
	Die Linux-Shell greift auf das zugrundeliegende Betriebssystem zurück. Man erhält Zugriff auf viele Systemparameter, die über das Webinterface oder das CLI nicht zugänglich sind – wenn auch zumeist nur lesend. Mit dem Paketsniffer tcpdump steht auf der linux-Shell ein sehr leistungsfähiges Werkzeug zur Trafficanalyse zur Verfügung.		Die Linux-Shell greift auf das zugrundeliegende Betriebssystem zurück. Man erhält Zugriff auf viele Systemparameter, die über das Webinterface oder das CLI nicht zugänglich sind - wenn auch zumeist nur lesend. Mit dem Paketsniffer tcpdump steht auf der linux-Shell ein sehr leistungsfähiges Werkzeug zur Trafficanalyse zur Verfügung.

	Die Linux-Shell erreicht man ausschließlich über eine Textkonsole mit dem Benutzer „root“.		Die Linux-Shell erreicht man ausschließlich über eine Textkonsole mit dem Benutzer „root“.
Zeile 52:		Zeile 52:

	Beispiel:<br />		Beispiel:<br />
	<code>tcpdump –i eth1</code>		<code>tcpdump -i eth1</code>

	'''''proto''''' definiert die Protokollnummer auf Transportebene.		'''''proto''''' definiert die Protokollnummer auf Transportebene.

	Beispiele:<br />		Beispiele:<br />
	<code> tcpdump –i eth1 proto 1</code> zeigt ICMP-Pakete<br />		<code> tcpdump -i eth1 proto 1</code> zeigt ICMP-Pakete<br />

	<code>tcpdump –i eth1 proto 6</code> zeigt TCP-Pakete<br />		<code>tcpdump -i eth1 proto 6</code> zeigt TCP-Pakete<br />

	<code> tcpdump –i eth1 proto 17</code> zeigt UDP-Pakete<br />		<code> tcpdump -i eth1 proto 17</code> zeigt UDP-Pakete<br />

	<code> tcpdump –i eth1 proto 50</code> zeigt ESP-Pakete		<code> tcpdump -i eth1 proto 50</code> zeigt ESP-Pakete

	'''''port''''' definiert tcp- oder udp-ports.		'''''port''''' definiert tcp- oder udp-ports.

	Beispiel:		Beispiel:
	<code>tcpdump –i eth1 port 80</code>		<code>tcpdump -i eth1 port 80</code>

	'''''host''''' definiert einen bestimmten Host mit seiner IP als Quelle oder Ziel.		'''''host''''' definiert einen bestimmten Host mit seiner IP als Quelle oder Ziel.

	Beispiel:		Beispiel:
	<code>tcpdump –i eth1 host 10.0.0.1</code>		<code>tcpdump -i eth1 host 10.0.0.1</code>

	'''''net''''' definiert ein Netzwerk (Quelle oder Ziel)		'''''net''''' definiert ein Netzwerk (Quelle oder Ziel)

	Beispiel:		Beispiel:
	<code>tcpdump –i eth1 net 10.0.0.0/24</code>		<code>tcpdump -i eth1 net 10.0.0.0/24</code>

	Darüber hinaus lassen sich Filterparameter mit logischen Operatoren verknüpfen. So können		Darüber hinaus lassen sich Filterparameter mit logischen Operatoren verknüpfen. So können
	folgendermaßen alle ICMP-Pakete für Host 10.0.0.10 angezeigt werden:<br />		folgendermaßen alle ICMP-Pakete für Host 10.0.0.10 angezeigt werden:<br />
	<code>tcpdump –i eth1 proto 1 and host 10.0.0.10</code>		<code>tcpdump -i eth1 proto 1 and host 10.0.0.10</code>

	Weitere Steuerungsparameter sind beispielsweise:		Weitere Steuerungsparameter sind beispielsweise:
Zeile 97:		Zeile 97:
	===Initiator-Seite: Intern===		===Initiator-Seite: Intern===
	Wir beginnen unsere Analyse am internen Interface des Gateways der Zentrale. Dazu melden wir uns per ssh als User „root“ dort an und führen folgendes Kommando aus:		Wir beginnen unsere Analyse am internen Interface des Gateways der Zentrale. Dazu melden wir uns per ssh als User „root“ dort an und führen folgendes Kommando aus:
	<code>tcpdump –i eth1 proto 1 -n</code>		<code>tcpdump -i eth1 proto 1 -n</code>

	Der Parameter „proto 1“ bezieht sich auf die Protokollnummer 1 des ICMP-Protokolls auf Transportebene. Alternativ können wir auch nach Paketen suchen, die für das entfernte Subnetz bestimmt sind:		Der Parameter „proto 1“ bezieht sich auf die Protokollnummer 1 des ICMP-Protokolls auf Transportebene. Alternativ können wir auch nach Paketen suchen, die für das entfernte Subnetz bestimmt sind:

	<code>tcpdump –i eth1 net 10.4.0.0/24 –n</code>		<code>tcpdump -i eth1 net 10.4.0.0/24 -n</code>

	Versuchen wir jetzt zu „pingen“, zeigt sich folgendes Ergebnis:		Versuchen wir jetzt zu „pingen“, zeigt sich folgendes Ergebnis:
Zeile 114:		Zeile 114:

	===Initiator-Seite: Extern===		===Initiator-Seite: Extern===
	Zur weiteren Verfolgung muss das ausgehende Interface der zentralen Firewall betrachtet werden. Allerdings ergibt sich hier ein Problem: Da wir an dieser Stelle den Transport der übertragenen Daten nur in verschlüsselter Form betrachten können, bleibt uns das ICMP-Paket im Klartext verborgen – und das sollte auch so sein. Wir können allerdings versuchen, eingehendes Klartext- und ausgehendes verschlüsseltes Paket miteinander in Beziehung zu setzen. Wir starten dazu tcpdump mit folgenden Parametern:		Zur weiteren Verfolgung muss das ausgehende Interface der zentralen Firewall betrachtet werden. Allerdings ergibt sich hier ein Problem: Da wir an dieser Stelle den Transport der übertragenen Daten nur in verschlüsselter Form betrachten können, bleibt uns das ICMP-Paket im Klartext verborgen - und das sollte auch so sein. Wir können allerdings versuchen, eingehendes Klartext- und ausgehendes verschlüsseltes Paket miteinander in Beziehung zu setzen. Wir starten dazu tcpdump mit folgenden Parametern:

	<code>tcpdump –i any proto 1 or proto 50 -n</code>		<code>tcpdump -i any proto 1 or proto 50 -n</code>

	Wir suchen an einer beliebigen Schnittstelle nach ICMP-Paketen oder nach verschlüsselten Paketen. Das hierzu von IPSec verwendete Protokoll ESP hat auf der Transportebene die Protokollnummer 50. Gibt es mehrere IPSec-Verbindungen auf dem Gateway, kann alternativ auch nach Paketen für das entfernte Subnetz oder das entfernte Gateway gesucht werden:		Wir suchen an einer beliebigen Schnittstelle nach ICMP-Paketen oder nach verschlüsselten Paketen. Das hierzu von IPSec verwendete Protokoll ESP hat auf der Transportebene die Protokollnummer 50. Gibt es mehrere IPSec-Verbindungen auf dem Gateway, kann alternativ auch nach Paketen für das entfernte Subnetz oder das entfernte Gateway gesucht werden:

	<code>tcpdump –i any net 10.4.0.0/24 or host 198.51.100.4 –n</code>		<code>tcpdump -i any net 10.4.0.0/24 or host 198.51.100.4 -n</code>

	Wir erhalten folgendes Ergebnis:		Wir erhalten folgendes Ergebnis:
Zeile 154:		Zeile 154:
	Gehen wir davon aus, dass auf dem Gateway der Zentrale alles funktioniert, müssen wir weiter auf dem Gateway der Filiale suchen. Zunächst vergewissern wir uns, dass die verschlüsselten Daten auch an der Gegenstelle ankommen. Das diese von der Zentrale aus abgeschickt werden, heißt noch lange nicht, dass sie auch ankommen! Deshalb führen wir auf der SSH-Konsole auf der Filiale folgendes Kommando aus:		Gehen wir davon aus, dass auf dem Gateway der Zentrale alles funktioniert, müssen wir weiter auf dem Gateway der Filiale suchen. Zunächst vergewissern wir uns, dass die verschlüsselten Daten auch an der Gegenstelle ankommen. Das diese von der Zentrale aus abgeschickt werden, heißt noch lange nicht, dass sie auch ankommen! Deshalb führen wir auf der SSH-Konsole auf der Filiale folgendes Kommando aus:

	<code>tcpdump –i eth0 proto 50 –n</code>		<code>tcpdump -i eth0 proto 50 -n</code>

	Das Ergebnis ist folgende Ausgabe:		Das Ergebnis ist folgende Ausgabe:
Zeile 167:		Zeile 167:
	Wir können also sicher sein, dass die verschlüsselten Pakete auch am Gateway der Filiale ankommen! Die letzte Etappe ist nun die interne Schnittstelle des Filial-Gateways. Hier schauen wir, ob das ICMP-Paket auch ins interne Netz Richtung Zielhost geschickt wird:		Wir können also sicher sein, dass die verschlüsselten Pakete auch am Gateway der Filiale ankommen! Die letzte Etappe ist nun die interne Schnittstelle des Filial-Gateways. Hier schauen wir, ob das ICMP-Paket auch ins interne Netz Richtung Zielhost geschickt wird:

	<code>tcpdump –i eth1 proto 1 –n</code>		<code>tcpdump -i eth1 proto 1 -n</code>

	Ist auch auf dem Gateway der Filiale in Bezug auf Portfilter-Regeln alles korrekt konfiguriert, sollte sich folgende Ausgabe ergeben:		Ist auch auf dem Gateway der Filiale in Bezug auf Portfilter-Regeln alles korrekt konfiguriert, sollte sich folgende Ausgabe ergeben:
Zeile 180:		Zeile 180:

	<pre>		<pre>
	root@standort-4:~# tcpdump –i eth1 host 10.4.0.10 –n		root@standort-4:~# tcpdump -i eth1 host 10.4.0.10 -n
	11:44:39.553889 ARP, Request who-has 10.4.0.10 tell 10.4.0.1, length 28		11:44:39.553889 ARP, Request who-has 10.4.0.10 tell 10.4.0.1, length 28
	11:44:39.554212 ARP, Reply 10.4.0.10 is-at 08:00:27:e1:fd:ab, length 46		11:44:39.554212 ARP, Reply 10.4.0.10 is-at 08:00:27:e1:fd:ab, length 46
Zeile 209:		Zeile 209:
	Nachdem feststeht, dass der Fehler nur auf dem Zielhost liegen kann, müsste dieser auch dort gefunden werden. Wir können den Fehler aber auch bereits auf dem Gateway auf Responder-Seite weiter eingrenzen, wenn wir betrachten, ob und welche Pakete vom Zielhost zurückkommen:		Nachdem feststeht, dass der Fehler nur auf dem Zielhost liegen kann, müsste dieser auch dort gefunden werden. Wir können den Fehler aber auch bereits auf dem Gateway auf Responder-Seite weiter eingrenzen, wenn wir betrachten, ob und welche Pakete vom Zielhost zurückkommen:

	<code>tcpdump –i eth1 host 10.4.0.10 -n</code>		<code>tcpdump -i eth1 host 10.4.0.10 -n</code>

	Sind nun ausschließlich die von der NextGen UTM ausgehenden Ping sichtbar, dann ist anzunehmen, dass der Zielhost aufgrund einer aktiven lokalen Firewall nicht antwortet:		Sind nun ausschließlich die von der NextGen UTM ausgehenden Ping sichtbar, dann ist anzunehmen, dass der Zielhost aufgrund einer aktiven lokalen Firewall nicht antwortet:

Lauritzl: Lauritzl verschob die Seite Spielwiese/ipsec fehleranalyse nach UTM/Extras/ipsec fehleranalyse

2019-03-14T12:45:35Z

Lauritzl verschob die Seite Spielwiese/ipsec fehleranalyse nach UTM/Extras/ipsec fehleranalyse

← Nächstältere Version	Version vom 14. März 2019, 14:45 Uhr
(kein Unterschied)

Lauritzl am 14. März 2019 um 12:42 Uhr

2019-03-14T12:42:58Z

← Nächstältere Version		Version vom 14. März 2019, 14:42 Uhr
Zeile 1:		Zeile 1:
	{{DISPLAYTITLE: Fehleranalyse mit tcpdump }}		{{DISPLAYTITLE: Fehleranalyse mit tcpdump }}
	~~== Informationen ==~~
	Letze Anpassung zur Version: '''11.7.9'''		Letze Anpassung zur Version: '''11.7.9'''
	<br>		<br>
	Vorherige Versionen: -		Vorherige Versionen: -
	<br>		<br>

	==Einleitung==		==Einleitung==
	Falls eine TCP/IP-Verbindung mal nicht funktioniert, bietet die Firewall einige Möglichkeiten den Fehlern		Falls eine TCP/IP-Verbindung mal nicht funktioniert, bietet die Firewall einige Möglichkeiten den Fehlern

Jan: /* Initiator-Seite: Extern */

2018-09-03T15:16:34Z

Initiator-Seite: Extern

← Nächstältere Version		Version vom 3. September 2018, 17:16 Uhr
Zeile 113:		Zeile 113:

	===Initiator-Seite: Extern===		===Initiator-Seite: Extern===
	Zur weiteren Verfolgung muss das ausgehende Interface der zentralen Firewall betrachtet werden. Allerdings ~~stellt~~ sich hier ein Problem: Da wir an dieser Stelle den Transport der übertragenen Daten nur in verschlüsselter Form betrachten können, bleibt uns das ICMP-Paket im Klartext verborgen – und das sollte auch so sein. Wir können allerdings versuchen, eingehendes Klartext- und ausgehendes verschlüsseltes Paket miteinander in Beziehung zu setzen. Wir starten dazu tcpdump mit folgenden Parametern:		Zur weiteren Verfolgung muss das ausgehende Interface der zentralen Firewall betrachtet werden. Allerdings ergibt sich hier ein Problem: Da wir an dieser Stelle den Transport der übertragenen Daten nur in verschlüsselter Form betrachten können, bleibt uns das ICMP-Paket im Klartext verborgen – und das sollte auch so sein. Wir können allerdings versuchen, eingehendes Klartext- und ausgehendes verschlüsseltes Paket miteinander in Beziehung zu setzen. Wir starten dazu tcpdump mit folgenden Parametern:

	<code>tcpdump –i any proto 1 or proto 50 -n</code>		<code>tcpdump –i any proto 1 or proto 50 -n</code>

Jan: /* Tcpdump auf der root-Konsole */

2018-09-03T15:11:21Z

Tcpdump auf der root-Konsole

← Nächstältere Version		Version vom 3. September 2018, 17:11 Uhr
Zeile 41:		Zeile 41:

	===Voraussetzungen===		===Voraussetzungen===
	Die Voraussetzungen zur Verwendung von tcpdump sind ~~folgende~~:		Die Voraussetzungen zur Verwendung von tcpdump sind Folgende:
	*Ein User „root“ in der Gruppe Administrator		*Ein User „root“ in der Gruppe Administrator
	*Ein SSH-Client (z. B. PuTTY) oder eine lokale Konsole auf der Firewall		*Ein SSH-Client (z. B. PuTTY) oder eine lokale Konsole auf der Firewall

Jan: /* Level 1: Livelog */

2018-09-03T15:08:45Z

Level 1: Livelog

← Nächstältere Version		Version vom 3. September 2018, 17:08 Uhr
Zeile 25:		Zeile 25:
	#Wenn ein Paket angenommen wird, dann liegt der Fehler vermutlich in Richtung Zielhost.		#Wenn ein Paket angenommen wird, dann liegt der Fehler vermutlich in Richtung Zielhost.
	#Ist kein Paket im Livelog sichtbar, dann kommt vermutlich auch keins an der Firewall an. Der Fehler ist hier vermutlich in Richtung Quellhost zu suchen.		#Ist kein Paket im Livelog sichtbar, dann kommt vermutlich auch keins an der Firewall an. Der Fehler ist hier vermutlich in Richtung Quellhost zu suchen.

	===Level 2: CLI===		===Level 2: CLI===
	Das CLI (Command Line Interface) stellt die Schnittstelle zum Firewall-Server dar, welche zum einen vom Webinterface genutzt wird, zum anderen auch auf der Konsole zur manuellen Konfiguration der Firewall genutzt werden kann. Für die Fehlersuche bei Verbindungsproblemen ist das CLI allerdings nur von begrenztem Nutzen.		Das CLI (Command Line Interface) stellt die Schnittstelle zum Firewall-Server dar, welche zum einen vom Webinterface genutzt wird, zum anderen auch auf der Konsole zur manuellen Konfiguration der Firewall genutzt werden kann. Für die Fehlersuche bei Verbindungsproblemen ist das CLI allerdings nur von begrenztem Nutzen.

Jan: /* Einleitung */

2018-09-03T15:07:22Z

Einleitung

← Nächstältere Version		Version vom 3. September 2018, 17:07 Uhr
Zeile 6:		Zeile 6:
	<br>		<br>
	==Einleitung==		==Einleitung==
	Falls eine TCP/IP-Verbindung mal nicht funktioniert, bietet die Firewall einige Möglichkeiten~~, dem Fehler~~		Falls eine TCP/IP-Verbindung mal nicht funktioniert, bietet die Firewall einige Möglichkeiten den Fehlern
	auf die Spur zu kommen. Konkret gibt es drei Level der Analyse, die immer tiefer in das System		auf die Spur zu kommen. Konkret gibt es drei Level der Analyse, die immer tiefer in das System
	hinabsteigen. Das oberste Level ist über das Webinterface erreichbar, die unteren ~~Levels~~ benötigen eine		hinabsteigen. Das oberste Level ist über das Webinterface erreichbar, die unteren Level benötigen eine
	Textkonsole, entweder über SSH oder lokal am Gerät.		Textkonsole, entweder über SSH oder lokal am Gerät.
	----		----

	== Die Level der Fehleranalyse==		== Die Level der Fehleranalyse==
	===Level 1: Livelog===		===Level 1: Livelog===

Pascalm: /* Parameter zur Steuerung und Filterung */

2018-09-03T14:33:22Z

Parameter zur Steuerung und Filterung

← Nächstältere Version		Version vom 3. September 2018, 16:33 Uhr
Zeile 46:		Zeile 46:
	anzeigen. Es ist also notwendig, durch entsprechende Filterparameter ein Suchmuster vorzugeben.		anzeigen. Es ist also notwendig, durch entsprechende Filterparameter ein Suchmuster vorzugeben.

	'''''-i''''' definiert das Interface, an dem ein- oder ausgehende Pakete angezeigt werden sollen		'''''-i''''' definiert das Interface, an dem ein- oder ausgehende Pakete angezeigt werden sollen.

	Beispiel:<br />		Beispiel:<br />
	<code>tcpdump –i eth1</code>		<code>tcpdump –i eth1</code>

	'''''proto''''' definiert die Protokollnummer auf Transportebene.		'''''proto''''' definiert die Protokollnummer auf Transportebene.

	Beispiele:<br />		Beispiele:<br />
	<code> tcpdump –i eth1 proto 1</code> zeigt ICMP-Pakete<br />		<code> tcpdump –i eth1 proto 1</code> zeigt ICMP-Pakete<br />
Zeile 61:		Zeile 63:

	'''''port''''' definiert tcp- oder udp-ports.		'''''port''''' definiert tcp- oder udp-ports.

	Beispiel:		Beispiel:
	<code>tcpdump –i eth1 port 80</code>		<code>tcpdump –i eth1 port 80</code>

	'''''host''''' definiert einen bestimmten Host mit seiner IP als Quelle oder Ziel.		'''''host''''' definiert einen bestimmten Host mit seiner IP als Quelle oder Ziel.

	Beispiel:		Beispiel:
	<code>tcpdump –i eth1 host 10.0.0.1</code>		<code>tcpdump –i eth1 host 10.0.0.1</code>

	'''''net''''' definiert ein Netzwerk (Quelle oder Ziel)		'''''net''''' definiert ein Netzwerk (Quelle oder Ziel)

	Beispiel:		Beispiel:
	<code>tcpdump –i eth1 net 10.0.0.0/24</code>		<code>tcpdump –i eth1 net 10.0.0.0/24</code>