Wechseln zu:Navigation, Suche
Wiki
KKeine Bearbeitungszusammenfassung
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 1: Zeile 1:
{{DISPLAYTITLE: Fehleranalyse UTM}}
{{Set_lang}}


== Informationen ==
{{#vardefine:headerIcon|spicon-utm}}
Letze Anpassung zur Version: '''11.7.12'''
{{:UTM/Extras/Fehleranalyse.lang}}
<br>
Bemerkung: Neuer Artikel
<br>
Vorherige Versionen: -
<br>
== Einleitung ==
Im Fehlerfall sind folgende Schritte notwendig, damit eine korrekte Fehleranalyse von unserem Support durchgeführt werden kann.


=== Hinweise ===
{{var | neu--Layout
Um einen ordnungsgemäßen Betrieb sicherzustellen, darf das UTM-System nicht ohne ordentliches Herunterfahren stromlos gemacht werden.
| Allgemeine Layoutanpassung
Ansonsten kann es zu Beschädigungen oder Beeinträchtigungen kommen. Die UTM kann wie folgt ordnungsgemäß heruntergefahren werden.
| General layout adaption }}


* Über das Webinterface (Konfiguration -> Herunterfahren)
</div><div class="new_design"></div>{{Select_lang}} {{TOC2}}
* Über die Powertaste am Gerät
{{Header|02.2024|
* Via SPCLI (system poweroff)
*{{#var:neu--Layout}}
* Via SSH (spcli system poweroff)
|[[UTM/Extras/Fehleranalyse_v11.7 | 11.7]]
}}
----


=== {{#var:Einleitung}} ===
<div class="einrücken">
{{#var:Einleitung--desc}}
<br clear=all></div>


<div>
==== {{#var:Hinweise}} ====
<div style="display: flex;padding-right:10px;float:left;"> [[Datei:alert-yellow.png]] </div>
<div class="einrücken">
<div style="display: flex;"><span style="background-color: #ffc926;padding:10px;border-radius:4px;font-weight:bold;">Ein Semikolon ";“ steht für die Eingabe-Taste.</span></div>
{{#var:Hinweise--desc}}
</div>
<li class="list--element__alert list--element__hint">{{#var:Hinweis-Eingabe Taste}}</li>
<div style="clear: both;"></div>
<li class="list--element__alert list--element__hint">{{#var:Hinweis-Terra Cloud}}</li>
<br>
<li class="list--element__alert list--element__hint">{{#var:Hinweis-spcli}}</li>
<div>
<br clear=all></div>
<div style="display: flex;padding-right:10px;float:left;"> [[Datei:alert-yellow.png]] </div>
<div style="display: flex;"><span style="background-color: #ffc926;padding:10px;border-radius:4px;font-weight:bold;">Auf Terra-Cloud Firewalls kann kein Benutzer "root" erstellt werden, hierfür muss der Support kontaktiert werden.</span></div>
</div>
<div style="clear: both;"></div>
----
----


== Vorbereitung==
=== {{#var:Vorbereitung}} ===
Ein Benutzer mit dem Namen "root", freiwählbaren Passwort und der Gruppe "Administrator" muss auf der Firewall erstellt werden.
<div class="einrücken">
Login via SSH (z.B. PuTTy) auf der Firewall mit dem Benutzer "root".
{{#var:Vorbereitung--desc}}
 
<br clear=all></div>
Wie ein Benutzer über das Webinterface erstellt wird, ist [[UTM/AUTH/Benutzerverwaltung | hier]] zu finden.
<div>
<div style="display: flex;padding-right:10px;float:left;"> [[Datei:alert-red.png]] </div>
<div style="display: flex;"><span style="background-color: #bc1b18;padding:10px;border-radius:4px;font-weight:bold;color:white">Das Passwort "insecure" ist kein sicheres Passwort.</span></div>
</div>
<div style="clear: both;"></div>
 
===Erhöhen der Syslog-Einträge===
<code>spcli;</code>
<code>syslog backlog set type messages limit 100000;</code>
<code>system config save;</code>


===Freigabe der Securepoint IP für eine Fehleranalyse von extern.===
==== {{#var:Erhöhen der Syslog-Einträge}} ====
<code>manager new hostlist 87.139.55.127/32;</code>
<div class="einrücken">
{{#var:Erhöhen der Syslog-Einträge--desc}}<br>
{{code|1=spcli syslog backlog set type messages limit 100000 <i class="fas fa-arrow-turn-down-left key"></i><br>spcli system config save <i class="fas fa-arrow-turn-down-left key"></i>|class=inline-block}}
<br clear=all></div>


Anschließend die SSH-Verbindung trennen.
==== {{#var:Freigabe der Securepoint IP}} ====
 
<div class="einrücken">
<div>
{{#var:Freigabe der Securepoint IP--desc}}<br>
<div style="display: flex;padding-right:10px;float:left;"> [[Datei:alert-red.png]] </div>
{{code|1=spcli manager new hostlist securepoint.de <i class="fas fa-arrow-turn-down-left key"></i>}}<br>
<div style="display: flex;"><span style="background-color: #bc1b18;padding:10px;border-radius:4px;font-weight:bold;color:white">Es muss sichergestellt werden, dass die Ports 11115 und 22 von einem davorstehenden Router auf die UTM weitergeleitet werden.</span></div>
{{#var:Anschließend die SSH-Verbindung trennen}}
</div>
{{Hinweis-box|{{#var:Hinweis-SSL Ports}} }}
<div style="clear: both;"></div>
<br clear=all></div>
----
----


== Fehleranalyse ==
=== {{#var:Fehleranalyse}} ===
Im Fehlerfall bitte folgendes testen und dokumentieren.
<div class="einrücken">
{{#var:Fehleranalyse--desc}}
<br clear=all></div>


* Pingtest auf die IP der UTM (eth1)
==== {{#var:Prüfen der Schnittstellen}} ====
* Traceroute auf die IP der UTM (eth1)
<div class="einrücken">
{{#var:Prüfen der Schnittstellen--desc}}


* Login UTM via SSH
{{code|<nowiki>root@firewall:~# ip a
* Login UTM via Webbrowser (Bitte mit mindestens zwei Browsern testen)
* Login UTM via Monitor und Tastatur an der UTM
 
Wenn der Login via SSH oder Monitor und Tastatur klappen sollte, bitte Folgendes durchführen.
 
=== Prüfen der Schnittstellen===
<code>ip a;</code>
 
Hier sollten folgende Informationen angezeigt werden,  wobei die IPs, Interface und MAC-Adressen abweichen können. Hier  bitte überprüfen, ob die Ports „NO-CARRIER“, „DOWN“ oder „UP“ anzeigen.
 
<pre>root@firewall:~# ip a
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff
link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff
Zeile 89: Zeile 68:
valid_lft forever preferred_lft forever
valid_lft forever preferred_lft forever
8: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
8: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 31:32:33:34:35:36 brd ff:ff:ff:ff:ff:ff</pre>
link/ether 31:32:33:34:35:36 brd ff:ff:ff:ff:ff:ff</nowiki>}}
 
<br clear=all></div>
=== Prüfen der Interface Adressen ===
<code>spcli;</code>
<code>interface address get;</code>
 
Hier sollten folgende Informationen angezeigt werden, wobei die IDs und IPs abweichen können. Hier bitte prüfen, ob die Interfaces ONLINE sind.


<pre>firewall.foo.local> interface address get
==== {{#var:Prüfen der Interface Adressen}} ====
<div class="einrücken">
{{#var:Prüfen der Interface Adressen--desc1}}<br>
{{code|1=spcli interface address get <i class="fas fa-arrow-turn-down-left key"></i>}}<br>
{{#var:Prüfen der Interface Adressen--desc2}}<br>
{{code|<nowiki>firewall.foo.local> interface address get
id|flags  |device|address
id|flags  |device|address
–+——-+——+——-
–+——-+——+——-
16|ONLINE |eth0  |10.10.10.2/24
16|ONLINE |eth0  |10.10.10.2/24
5 |ONLINE |eth1  |192.168.175.1/24</pre>
5 |ONLINE |eth1  |192.168.175.1/24</nowiki>}}
 
<br clear=all></div>
=== PING-Test ins Internet ===
<code>exit;</code>
<code>tcpdump -i eth1 -nnp proto 1;</code>
 
Anschließend wird ein Ping auf die IP "9.9.9.9" von einem Gerät, welches sich hinter eth1 befindet und die UTM als Gateway eingetragen hat, durchgeführt.
 
Hier sollten folgende Informationen angezeigt werden, wobei die IPs abweichen können. Hier bitte prüfen, ob der ICMP echo request und der ICMP echo reply an der Schnittstelle ankommt.


<pre>root@firewall:~# tcpdump -i eth1 -nnp proto 1
==== {{#var:PING-Test ins Internet}} ====
<div class="einrücken">
{{#var:PING-Test ins Internet--desc}}<br>
{{code|<nowiki>root@firewall:~# tcpdump -i eth1 -nnp proto 1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
Zeile 117: Zeile 92:
08:32:43.070499 IP 9.9.9.9 > 192.168.175.101: ICMP echo reply, id 36620, seq 9, length 64
08:32:43.070499 IP 9.9.9.9 > 192.168.175.101: ICMP echo reply, id 36620, seq 9, length 64
08:32:44.051886 IP 192.168.175.101 > 9.9.9.9: ICMP echo request, id 36620, seq 10, length 64
08:32:44.051886 IP 192.168.175.101 > 9.9.9.9: ICMP echo request, id 36620, seq 10, length 64
08:32:44.070340 IP 9.9.9.9 > 192.168.175.101: ICMP echo reply, id 36620, seq 10, length 64</pre>
08:32:44.070340 IP 9.9.9.9 > 192.168.175.101: ICMP echo reply, id 36620, seq 10, length 64</nowiki>}}
<br clear=all></div>
----
----


== Dokumentation ==
=== Dokumentation ===
Die Ergebnisse müssen dokumentiert werden, auch wenn diese fehlschlagen sollten. Ebenfalls ist es wichtig, dass Meldungen die möglicherweise beim Login auf der UTM angezeigt, auch dokumentiert werden.
<div class="einrücken">
Anschließend bitte ein Supportticket über das Resellerportal erstellen und das Protokoll bereithalten.
{{#var:Dokumentation--desc}}
<br clear=all></div>

Aktuelle Version vom 20. Februar 2024, 15:52 Uhr






























De.png
En.png
Fr.png








Securepoint UTM Fehleranalyse
Letzte Anpassung: 02.2024
Neu:
  • Allgemeine Layoutanpassung
notempty
Dieser Artikel bezieht sich auf eine Resellerpreview

11.7


Einleitung

Im Fehlerfall sind folgende Schritte notwendig, damit eine korrekte Fehleranalyse von unserem Support durchgeführt werden kann.


Hinweise

Um einen ordnungsgemäßen Betrieb sicherzustellen, darf das UTM-System nicht ohne ordentliches Herunterfahren stromlos gemacht werden. Ansonsten kann es zu Beschädigungen oder Beeinträchtigungen kommen. Die UTM kann wie folgt ordnungsgemäß heruntergefahren werden.

  • Über das Webinterface (Konfiguration -> Herunterfahren)
  • Über die Powertaste am Gerät
  • Via SPCLI (system poweroff)
  • Via SSH (poweroff)
  • Ein steht für die Eingabe-Taste
  • Auf Terra-Cloud Firewalls kann kein Benutzer "root" erstellt werden, hierfür muss der Support kontaktiert werden.
  • Der Befehl spcli ruft über den root-Benutzer die Securepoint CLI der UTM auf. Dieser Befehl muss nicht verwendet werden wenn diese bereits geöffnet ist. Verlassen wird die Securepoint CLI mit dem Befehl: exit. Außerdem kann der Befehl auch einem Befehl direkt vorangestellt werden: spcli interface address get.


  • Vorbereitung

    Ein Benutzer mit Root-Berechtigungen wird benötigt. Hierzu wird dringend empfohlen einen Support Benutzer zu verwenden, da dieser immer ein Ablaufdatum hatn und ein permanenter root-Benutzer ein Sicherheitsrisiko darstellt.


    Erhöhen der Syslog-Einträge

    Mit den folgenden Befehlen kann die maximale Anzahl an Syslog-Einträgen erhöht werden, dies ist sinnvoll bei der Fehleranalyse, da so ein längerer Zeitraum analysiert werden kann.
    spcli syslog backlog set type messages limit 100000
    spcli system config save


    Freigabe der Securepoint IP

    Für eine externe Fehleranalyse muss die IP von Securepoint für das Admin Interface freigegeben werden:
    spcli manager new hostlist securepoint.de
    Anschließend die SSH-Verbindung trennen.

    notempty
    Es muss sichergestellt werden, dass die Ports 11115 und 22 von einem davorstehenden Router auf die UTM weitergeleitet werden.


    Fehleranalyse

    Im Fehlerfall bitte folgendes testen und dokumentieren.

    • Pingtest auf die IP der UTM (eth1)
    • Traceroute auf die IP der UTM (eth1)
    • Login UTM via SSH
    • Login UTM via Webbrowser (Bitte mit mindestens zwei Browsern testen)
    • Login UTM via Monitor und Tastatur an der UTM

    Wenn der Login via SSH oder Monitor und Tastatur klappen sollte, bitte Folgendes durchführen.


    Prüfen der Schnittstellen

    Um die Schnittstellen zu überprüfen kann der Befehl ip a genutzt werden. Die Ausgabe von diesem sollte ähnlich (IP-Adressen, Interfaces und MAC-Adressen können abweichen) wie die folgende Aussehen. Besonders darauf geachtet werden sollte, ob die Ports NO-CARRIER, DOWN oder UP anzeigen.

    root@firewall:~# ip a 5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff inet 10.10.10.2/24 scope global eth0 valid_lft forever preferred_lft forever 7: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 21:22:23:24:24:26 brd ff:ff:ff:ff:ff:ff inet 192.168.175.1/24 scope global eth1 valid_lft forever preferred_lft forever 8: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 31:32:33:34:35:36 brd ff:ff:ff:ff:ff:ff


    Prüfen der Interface Adressen

    Mit den folgenden Befehlen können die Interface Adressen überprüft werden:
    spcli interface address get
    Die Ausgabe sollte ähnlich (IP-Adressen und Interfaces können abweichen) wie die folgende aussehen. Besonders darauf geachtet werden sollte, dass die Interfaces ONLINE sind.
    firewall.foo.local> interface address get id|flags |device|address –+——-+——+——- 16|ONLINE |eth0 |10.10.10.2/24 5 |ONLINE |eth1 |192.168.175.1/24


    PING-Test ins Internet

    Wenn die Securepoint CLI (spcli) geöffnet ist muss diese nun mit exit geschlossen werden.

    Anschließend kann mit Befehl tcpdump -i A1 -nnp proto 1 ein Ping auf die IP "9.9.9.9" von einem Gerät, welches sich hinter eth1 befindet und die UTM als Gateway eingetragen hat, durchgeführt werden.

    Hier sollten folgende Informationen angezeigt werden, wobei die IPs abweichen können. Hier bitte prüfen, ob der ICMP echo request und der ICMP echo reply an der Schnittstelle ankommt.
    root@firewall:~# tcpdump -i eth1 -nnp proto 1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 08:32:43.051837 IP 192.168.175.101 > 9.9.9.9: ICMP echo request, id 36620, seq 9, length 64 08:32:43.070499 IP 9.9.9.9 > 192.168.175.101: ICMP echo reply, id 36620, seq 9, length 64 08:32:44.051886 IP 192.168.175.101 > 9.9.9.9: ICMP echo request, id 36620, seq 10, length 64 08:32:44.070340 IP 9.9.9.9 > 192.168.175.101: ICMP echo reply, id 36620, seq 10, length 64



    Dokumentation

    Die Ergebnisse müssen dokumentiert werden, auch wenn diese fehlschlagen sollten. Ebenfalls ist es wichtig, dass Meldungen die möglicherweise beim Login auf der UTM angezeigt, auch dokumentiert werden.

    Anschließend bitte ein Supportticket über das Resellerportal erstellen und das Protokoll bereithalten.