[Problem] FTP Zugriff was muss ich freischalten?

johnydo

Neuer User
Mitglied seit
17 Dez 2008
Beiträge
35
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,

ich habe derzeit das Problem das ich kein FTP Protokoll über HTTP öffnen kann. Ich möchte zum Beispiel diese Seite aufrufen:

ftp://ftp.avm.de/fritz.box/....

Im Firewall Log habe ich gesehen das der Port 21 geblockt war und den habe ich dann freigeschaltet. Jetzt ist es ja so das der FTP Cient in dem Fall mein Browser mit dem Server einen weiteren Port aushandelt. Da ich im Vorfeld diesen Port nicht kenne habe ich jetzt die Frage wie ich so etwas einrichte? Gibt es da auf der Firewall ein spezielles Objekt oder Service der dafür verwendet wird?
 
Willst Du nun den Server ftp.avm.de über HTTP ansprechen, was Du im ersten Satz schreibst oder über FTP, was die URL vermuten läßt?

Wenn es tatsächlich um HTTP gehen sollte: Unter dem CNAME ftp.avm.de verbergen sich (zumindest war das vor nicht allzu langer Zeit so) drei verschiedene Server und nur einer von denen (download.avm.de) läßt auch den HTTP-Zugriff zu.
 
Ersetze gedanklich im ersten Satz HTTP durch Browser, dann ergibt es einen Sinn.
 
Na ja, wie man's nimmt ... dann verstehe ich das so, daß der TE per Browser einen Download (aber über das FTP-Protokoll, was ja auch noch lange nicht jeder Browser selbst versteht in vollem Umfang unterstützt, z.B. für Uploads) ausführen will und das auch noch im passiven Modus. Er hat aber eine Firewall, die selbst ausgehenden Verkehr blockiert und jetzt will er wissen, wie man den beim passiven Modus des FTP verwendeten Port auch noch freischaltet?

Ich bin mehr als verblüfft, weil ja so eine Firewall-Konfiguration (es geht alles nicht, was nicht ausdrücklich erlaubt ist und zwar nicht mal als egress) ja praktisch nicht handhabbar ist ... wie funktioniert das z.B. bei einem "echten" HTTP-Zugriff auf eine Webseite, die ihrerseits Inhalte von - sagen wir mal - 20 verschiedenen Servern nachlädt und das muß ja nicht automatisch Port 80 (oder 443) sein, woran man event. noch etwas "festmachen" könnte?

Entweder der TE hat hier ein Problem mit der Darstellung der Aufgabe (welche Firewall ist das überhaupt? wo sitzt die im Netzwerk - auf einem Gateway, hinter einem Router oder ist das am Ende nur irgendeine Firewall auf einem Client?) oder ich bin wirklich nicht in Form (fühle mich aber eigentlich nicht so).
 
Zuletzt bearbeitet:
Wenn ich den Thread hier überfliege geht es wohl tatsächlich um die Überwachung ausgehender Ports. Du müsstest bei jedem Server, den Du erreichen willst nachfragen in welchem Portbereich Verbindungen angeboten werden und anpassen. Einfacher ist es wohl, bestimmte Programme pauschal zu erlauben.
 
Hallo zusammen,

es geht wie schon geschrieben um die obige Webseite. Diese möchte ich mit dem Browser öffnen. Dahinter verbirgt sich ein FTP Server der "nur" im Browser angezeigt wird.

Ich habe eine Checkpointfirewall und diese macht die Interneteinwahl und das Routing. Die Standardpolicy auf der Firewall verbietet erstmal alles von innen nach außen. Ich habe dann angefangen das Regelwerk aufzubauen und Ports die ins Inbternet benötigt werden freigeschaltet.

Derzeit habe ich eine Regel die sieht so aus:

Source: 192.168.5.0/24
Destination: *
Service: 53 UDP, 123 UDP, 80 TCP, 443 TCP, 21 TCP
Action: Accept


Damit komme ich mit meinen Clients ins Internet und das Funktioniert auch soweit. Nur wenn ich auf einen FTP Server zugreife egal mit Browser oder FTP Client wird das von meiner Firewall noch blockiert. Mir ist auch schon klar warum weil ja der FTP Server mit dem Client einen Port aushandelt und diesen kann ich im Vorfeld nicht wissen. Es muss doch aber eine Funktion auf der Firewall geben die sagt -> "wenn ein Client einen FTP nach außen aufmacht dann lass das rein was angefordert wird" oder nicht?

Ich sag mal so jede Firma hat ja so eine Firewall und dort gehen auch FTP Zugriffe. Wie wird das dann gemacht?
 
Zuletzt bearbeitet:
Ich sag mal so jede Firma hat ja so eine Firewall und dort gehen auch FTP Zugriffe. Wie wird das dann gemacht?
Wenn so eine Firma tatsächlich eine Firewall hat, die auch jeden ausgehenden Verkehr blockiert (mit der gezeigten Filterung geht ja dann nicht einmal der Abruf oder Versand von E-Mails über die gängigen Protokolle), dann hat die in der Regel gar nicht das Bedürfnis, ausgehenden Verkehr überhaupt zu gestatten und dann wickelt sie das über einen Proxy-Server ab, der den ausgehenden Verkehr steuert, kontrolliert und meist sogar aufzeichnet. Damit wird dann dieser Proxy-Server zum "Ventil" und nicht irgendeine Firewall.

Ich habe keine Vorstellung, was man mit so einer Firewall-Konfiguration erreichen will ... zwar kann man sicherlich so das "nach Hause telefonieren" einiger moderner Geräte unterdrücken, aber damit wird auch jeder Auto-Update-Mechanismus, der abseits der "gängigen Ports" arbeitet (und davon gibt es genug, Stichwort "Webservices"), ausgehebelt und wer das in der heutigen Zeit tatsächlich noch stemmen kann, alles manuell auf dem neuesten Stand zu halten, der hat (meine Meinung, die durchaus polemisch an dieser Stelle geäußert wird) einfach nur zuviel Zeit.

Ich verstehe es sogar noch, wenn man für "verdächtige Geräte" (u.a. auch Smart-TVs und STBs) den ausgehenden Verkehr einschränkt ... aber wenn man ohnehin schon (wie oben gezeigt) für jedes Gerät im Netzwerksegment ausgehendes HTTP an beliebige Ziele erlaubt, dann verstehe ich den Sinn der Sache einfach nicht mehr ... ich lasse mich aber gerne aufklären, was das bringen könnte, außer der Feststellung: "Ich habe eine Firewall.".

Den Sicherheitsgewinn sehe ich auch mit viel Mühe nicht, zumal sich heute auch oft genug echte Schadsoftware nicht mehr die Blöße gibt, außerhalb "unverdächtiger Kanäle" zu kommunizieren und wenn dann auch noch HTTPS ausgehend zu beliebigen Zielen zulässig ist, kann die Firewall da auch nichts mehr blockieren. Was bringt so eine "kontrollierte Umgebung" also am Ende außer hohem Administrationsaufwand an zusätzlicher Sicherheit?

Wenn das z.B. ein Hotelbetreiber machen würde, um den Hotelgästen nur einen eingeschränkten Internetzugriff zu ermöglichen (auch wenn dafür der zulässige ausgehende Verkehr schon recht umfassend wäre und höchstens P2P-Netzwerke damit unterdrückt würden), verstehe ich das auch noch ... aber der hat dann in der Regel auch die Standhaftigkeit, solche Ansinnen wie diesen FTP-Zugriff eben mit "geht nicht" abzubügeln. Zumal das ja (wenn der FTP-Server tatsächlich nur eine eingeschränkte Auswahl von Ports für passive Transfers verwendet, mit etwas Pech kann das jeder unbenutzte Port zwischen 1024 und 65535 sein und lange nicht jeder Serverbetreiber hat auch noch eine eigene Firewall vor so einem FTP-Server, die zur Einschränkung der Port-Range Anlaß gibt) auch genau für diesen einen einzelnen FTP-Server gelten würde und beim nächsten schon wieder ganz anders aussehen kann.

Wie geschrieben ... ich versteh's nicht, würde ich aber gerne - vielleicht kann ich ja etwas lernen oder zumindest neue Ein- und Ansichten kennenlernen.
 
FTP läuft über zwei Ports.
20 und 21
Man muss also immer beide freischalten, und dann, wenn man Pech hat, auch noch weitere. Nämlich wen die 'falshe' FTP-Version (Client oder Server) verwendet wird.

Normalerweise sollte ein Server im Internet, der FTP anbietet, als 'Server' konfiguriert sei.
Aber es werden eben beide Ports benötigt.

-----
Das Protokoll ftp:// kann jeder Browser, die ist so alt, dass man eigentlich jedes mal vor der Nutzung den Staub abwischen müsste.
 
FTP läuft über zwei Ports.
20 und 21
Man muss also immer beide freischalten, [...]Aber es werden eben beide Ports benötigt.
Sorry, das ist nun mal ziemlicher Quatsch, wenn man da nicht weiter differenziert ... ich muß es so deutlich schreiben.

FTP bietet für die Datenübertragung (die Control-Verbindung geht immer über TCP-Port 21) zwei ziemlich verschiedene Übertragungsmodi an (aktive und passive Transfers), zwischen denen mit einem Kommando im Control-Channel umgeschaltet werden kann.

Bei aktiven Verbindungen kommt dann tatsächlich der TCP-Port 20 ins Spiel, weil von diesem Port aus der Server mit dem Client Kontakt aufnimmt, nachdem der Client dem Server einen passenden Port bei sich (dort muß der Client ja dann seinerseits ein "listen()" machen) über die Control-Verbindung mitgeteilt hat. Da dieser Modus z.B. an einem NAT-Router (ohne entsprechende Vorkehrungen seitens dieses Routers, was dann schon wieder in Richtung ALG gehen würde) glorreich scheitern wird (am NAT ist eben Schluß), verwendet man den aktiven Modus heute kaum noch und solange man diesen nicht benutzt, kann der TCP-Port 20 vollkommen außer acht gelassen werden bei irgendwelchen Firewall-Konfigurationen. Es gibt allerdings auch Clients, die den passiven Modus gar nicht beherrschen, dazu gehört u.a. der (Kommandozeilen-)FTP-Client von Windows (bis zu welcher Version weiß ich nicht genau, mind. aber bis W7).

Beim passiven Modus aktiviert der Server für die Datenübertragung eines Clients hingegen auf seiner Seite einen weiteren Port (i.d.R. jenseits von 1023) und teilt dem Client die Nummer dieses Ports mit, der nun seinerseits wieder (für seinen NAT-Router ist das ausgehender Verkehr) eine weitere Verbindung für den Data-Channel zum Server aufbaut.

Damit gibt es beim aktiven Modus zwei Verbindungen in unterschiedliche Richtungen (der Control-Channel vom Client zum Server und der Data-Channel vom Server zum Client) und beim passiven Modus eben zwei Verbindungen vom Client zum Server.

Es gibt im FTP-Protokoll auch niemals Unklarheiten, wer da Client und wer Server ist (der Client baut immer die Control-Verbindung zum Server auf), insofern verstehe ich
Theo Tintensich schrieb:
Nämlich wen die 'falshe' FTP-Version (Client oder Server) verwendet wird.
nicht - wenn man nicht den o.a. Unterschied in der "Verbindungsrichtung" auf "Client vs. Server" verkürzen will.

Auch die Frage, wie man denn
Theo Tintensich schrieb:
Normalerweise sollte ein Server im Internet, der FTP anbietet, als 'Server' konfiguriert sei.
verstehen müßte, quält mich etwas ... bitte ein Beispiel oder eine Erläuterung, wie ein solcher FTP-Server als "Client" konfiguriert werden kann.

Das Protokoll ftp:// kann jeder Browser, die ist so alt, dass man eigentlich jedes mal vor der Nutzung den Staub abwischen müsste.
Alt sicherlich (trotzdem findet sich immer noch kein Protokoll für dateiweise Übertragung mit ähnlich geringem Overhead) ... daß Du aber jeden Browser kennst (ich sehe keine weiteren Adjektive wie "üblicher" oder "verbreiteter" oder "aktueller"), das nötigt mir entschiedenen Respekt ab. Es ist allerdings nun auch wieder noch nicht so lange her, daß es z.B. bei Google Chrome einige heftige Probleme mit der Unterstützung von FTP "in allen Lebenslagen" gab: https://productforums.google.com/forum/#!topic/chrome/s0PfL4mKFtM

Auch kann ich mich durchaus noch an Zeiten erinnern (lang, lang ist's her), als z.B. der Internet Explorer noch keinen eingebauten FTP-Client hatte (da war der "Netscape Navigator" umfangreicher ausgestattet), bei meinem Favoriten "lynx" kann ich das heute noch mit einer Option abschalten und selbst die Fähigkeit, einen FTP-Download auszuführen, hat noch nicht unbedingt etwas mit einem voll ausgestatteten FTP-Client zu tun, z.B. unterstützt fast keiner dieser eingebauten Clients einen Upload bzw. im Moment fällt mir da gar keiner so richtig ein. Für die Aussage "ftp:// kann jeder Browser" finde ich das etwas wenig ... außer man versteht auch das wieder so, daß eine URI für einen FTP-Endpoint von fast allen Browsern verstanden wird.

Insofern gebe ich Dir teilweise recht, daß heutige moderne und aktuelle Browser in aller Regel (ich kenne beileibe nicht alle Mozilla- oder Chrome-Ableger - (Desktop-)Safari schon aus Überzeugung nicht - und kann das nicht mit Bestimmtheit sagen, auch Konqueror fällt mir noch ein, der wird das sicherlich auch eher in eine Extension ausgelagert haben, ist aber nur geraten und nicht recherchiert) das FTP-Protokoll soweit verstehen, daß sie einen Download und im günstigsten Falle sogar noch ein Verzeichnis-Listing unterstützen, wobei da die Fähigkeiten (z.B. bei owner/group, Zeitzonen uvm.) schon wieder auseinanderklaffen, aber der TE schrieb auch nur davon, daß er das FTP-Protokoll nutzen will ... da steht nichts von einer Richtung eines Dateitransfers.
 
Ich schrieb
Das Protokoll ftp:// kann jeder Browser, die ist so alt, dass man eigentlich jedes mal vor der Nutzung den Staub abwischen müsste.

und du fängst mit einem IE an, der zu einer Zeit im Einsatz war, zu der der Netscape Navigator noch 'up to date' war?
Wie war das mit "Staub abwischen"?

Was hat die Möglichkeit, FTP in der Browserkonfiguration abzuschalten damit zu tun, dass der Browser es kann?
Wenn ich bei meiner FB das WLAN abschalte, kann sie es doch, es wird nur nicht genutzt.

Der Hinweis zu Chrome ist auch lustig, dass das wohl ein Fehler innerhalb von einer jetzt uralten Chrom-Version war. Die Nutzung dieser grenzt an Leichenschändung.
Nach deinem Link (bzw. einem, der darin erwähnt wurde) funktionierte FTP nicht, wenn man einen Proxy (ach nee, doch nicht etwa das Port Problem?) eingestellt hatte.
Oder es funktionierte doch, wenn man nach der Fehlermeldung F5 drücke.
Was eigentlich sagt, dass es eine Macke in einem Chrome war, der vor über fünf Jahren aktuell war.
Und dann auch nur unter bestimmten Bedingungen auftrat.

Wenn wir uns bei FTP wirklich mit solch alten Kamellen rumärgern wollen?

Ist es nicht eher so, dass auch du sagt, wenn der FTP-Server falsch eingestellt ist, funktioniert es über eine NAT/PAT-Umgebung nicht?

Und dass auch aus dem Grund, dass das normale FTP keine gesicherte Übertragung zulässt, man FTP nur für anmeldefrei Zugriffe verwenden sollte?
Da FTPS nur von sehr wenigen Produkten sauber unterstützt wird, und auch hier nur der Control-Kanal verschlüsselt ist, sollte man gleich auf "sftp" umstellen, und damit benötigt man nur noch einen Port.
Der gesamte Verkehr geht nur Verschlüsselt über die Leitung, und das ist auch gut so.
 
Zur Thematik des Alters von FTP und der Aussage, daß FTP jeder Browser kann (stimmt, da stand ja nichts von "fehlerfrei") können wir uns sicherlich noch einigen - da habe ich, mit entsprechenden Einschränkungen, doch schon geschrieben, daß man das tatsächlich so sehen mag. Wenn Dich die neue Formulierung in #4 nach meiner Änderung jetzt eher zufriedenstellt, ist dieser Punkt für mich gegessen.

Das ändert nichts daran, daß die Aussage zu den Ports der Korrektur bedurfte (für mich jedenfalls, damit nicht der nächste sich auf diese falsche Fundstelle bezieht). Eine falsche Konfiguration eines FTP-Servers (passive Ports in Verbindung mit einer Firewall müssen natürlich auch dort eingehende Verbindungen zulassen) und die normalerweise ungesicherte Kommunikation auf dem Control-Channel (man kann - nebenbei bemerkt - auch den Data-Channel verschlüsseln, wenn man das will) haben damit ja per se nichts zu tun.

Die Verwendung des SFTP-Protokolls (das ist im Prinzip "normales FTP", aber eben über einen SSH-Tunnel) erfordert auf der Serverseite einen SSH-Server, das kann sich - je nach dem Charakter der Gegenseite - schwierig gestalten. Bei den (ja auch von uns beiden verwendeten) FRITZ!Boxen ist von Hause aus ja kein SSH-Server dabei. Außerdem hat das dann ebenfalls (wie die TLS-Verschlüsselung beim FTP-Protokoll auch in den meisten Fällen) den Effekt, daß man genau mit einem normalen Browser nicht mehr auf diese Services zugreifen kann - sicherlich auch ein Grund, warum bei den meisten eben keine TLS-Verschlüsselung für den FRITZ!Box-eigenen FTP-Server aktiviert wird (auch lange nicht jeder "Cloud-Client" einer App kommt mit "AUTH TLS" beim FTP klar).

Wenn es also um die "Grundsatzdiskussion" einer gesicherten Dateiübertragung geht, dann kommt vermutlich nur ein TLS-gesicherter Zugriff mit dem WebDAV-Protokoll als universelle Lösung (auch plattformübergreifend) in Frage ... solange man auf solche GUI-Lösungen wie FRITZ!NAS nicht wirklich steht (was auch schwer ist, schon angesichts der Handhabung beim Indizieren nach Uploads und der oft genug nur unvollständigen Anzeige des Verzeichnisinhalts). Wenn das dann nicht Gigabytes sind, die da übertragen werden sollen, macht auch der Overhead bei anderen Protokollen (FTP ist eben an dieser Stelle echt sparsam) nicht so sehr viel aus. Aber ... wie gesagt ... andere Baustelle.
 
Aber wenn man jetzt die Absichten des TE hier nicht hinterfrägt könnte er ja mit einem aktiven FTP (soweit vom Server unterstützt) sein Vorhaben umsetzen, da ausgehende Zielports lediglich TCP 20, 21 wären.
 
da ausgehende Zielports lediglich TCP 20, 21 wären.
Nö, TCP 20 ist eingehend aus Sicht eines Clients ... das ist ja das "NAT-Problem" bei aktivem FTP. Der Server baut die Verbindung zum Client auf.
 
Wenn ich jetzt nicht ganz falsch liege ist es doch so:

Client:X ---> Server:21 (Control)
Server:20 ---> Client:Y (Daten)

X>=1024, Y>=1024 (wobei letzterer durch den Client zuvor an den Server gemeldet wird)

Durch ein NAT oder eingehende Firewall kommt er trotzdem nicht, jedoch nicht wegen Port 20 sondern wegen Port Y, der zufällig sein kann (manche Clients nehmen Y=X oder Y=X+1, muss aber nicht sein).
 
@andiling:
Exakt ... wobei (theoretisch) das Y>=1024 nicht zwingend ist (das gilt für X streng genommen auch), diese Unterteilung in "privilegierte und unprivilegierte Ports" ist auf manchen Systemen auch nur graue Theorie und die ursprüngliche Idee aus dem *nix-Umfeld (kein Prozess eines normalen Users darf einen Listener auf einem Port < 1024 starten) funktioniert lange nicht überall. Beim NFS gibt es sogar einen Parameter dafür, wenn ein Request von einem Port > 1024 erlaubt sein soll (eine beliebte Fehlerquelle bei nicht funktionierenden NFS-Installationen), weil das Implikationen für das Durchsetzen von Zugriffsrechten nach sich zieht.

In einigen RFCs wird auch darauf eingegangen, daß diese Unterteilung nicht funktioniert bzw. nicht wirklich sicher ist, die in RFC1700 mal getroffen wurde. Dabei ging es eigentlich nur um die Zuweisung der "well known port numbers" durch die IANA, die irgendwann mal auf die Ports 0-1023 erweitert wurde. Die Theorie besagt dann eben (auch RFC1700), daß auf diesen "well known ports" nur Systemdienste (oder die von privilegierten Benutzern) laufen sollten:
RFC1700 schrieb:
The Well Known Ports are controlled and assigned by the IANA and on
most systems
can only be used by system (or root) processes or by
programs executed by privileged users.
[...]
The assigned ports use a small portion of the possible port numbers.
For many years the assigned ports were in the range 0-255. Recently,
the range for assigned ports managed by the IANA has been expanded to
the range 0-1023.
Unix-artige Betriebssysteme setzen das tatsächlich meist um, d.h. es braucht root-Rechte, um einen Listener auf einem Port < 1024 einzurichten (bzw. auch einen Sender an einen solchen Port zu binden).

TCP/20 ist natürlich ansonsten nur der Source-Port beim Server, von dem aus die Verbindung zum Client auf Port Y erfolgt, den der Client vorher mit einem "PORT"-Kommando an den Server übermittelt hat (das Pendant zum PASV-Kommando, wo der Server seinerseits mit einem Port antwortet).

Darauf basieren auch ALGs für FTP-Zugriff, die aber mit der zunehmenden Fähigkeit für den passiven Modus bei den Clients (der MS-Client auf der Kommandozeile ist da ja eine unrühmliche Ausnahme) aus der Mode gekommen sind. Diese ALGs überwachen alle ausgehenden TCP-Pakete mit Zielport 21 und untersuchen diese auf "PORT"-Kommandos. Finden sie ein solches, richten sie eine (temporäre) Portweiterleitung für einen zufälligen externen Port (das wäre dann "Z") ein und leiten dort eingehende Verbindungen von der Adresse des Servers und vom Port 20 dann an den Client auf Port Y weiter. Damit der Server jetzt die externe Adresse und den Port Z verwendet (anstelle der internen IP und des Ports des Clients), wird das "PORT"-Kommando entsprechend modifiziert, bevor es an den Server weitergesendet wird. So ein ALG scheitert natürlich am TLS im Control-Channel zwangsweise. Ob die FRITZ!Box nun eigentlich so ein ALG implementiert, frage ich mich auch jedesmal aufs Neue ... es ist gar nicht so einfach, einen aktiven FTP-Server mal so aus dem Ärmel zu schütteln für einen entsprechenden Test.

Ich wollte also eher darauf hinaus, daß es nicht beides "ausgehende Zielports" sind, weil TCP/20 vom Client nie angesprochen wird (solange das nicht die Antwort des Servers auf PASV vorgibt).
 
Leute, ich verstehe die ganze Aufregung hier nicht. Der TO sagt, dass er eine Firewall von Check Point hat und nun nicht weiß, wie er via FTP nach daußen kommt.

Check Point hat allerdings die "Stateful Packet Inspection" erfunden und besitzt ein Patent darauf. Damit sollte es überhaupt kein Problem sein, unverschlüsselt FTP selbst im aktiven FTP Modus nach draußen zu bringen. Also nix mit Überlegungen, welche feste Port-Ranges man dem FTP-Client freischalten sollte, etc.

Es fehlt einfach jemand, der sich mit dem Check Point Produkt auskennt und weiß, wie das zu konfigurieren ist. PeterPawn hat in seiner letzten Frage im Beitrag #4 alle entscheidenden Fragen gestellt ... die bis jetzt unbeantwortet blieben.

@johnydo: Wie heißt das Check Point Produkt jetzt genau, worauf ist es installiert, wie sieht die Infrastrukur aus?
 
Zuletzt bearbeitet:

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,695
Beiträge
2,216,699
Mitglieder
371,316
Neuestes Mitglied
realbluethunder
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.