Aufgrund der Sicherheit, die sie theoretisch bieten, sind FTPS und SFTP ähnlich. In der Praxis haben Sie die folgenden Vor- und Nachteile:

• Bei FTPS-Clientanwendungen können die Zertifikate häufig nicht ordnungsgemäß validiert werden, was effektiv ist bedeutet, dass ein Mann in der Mitte möglich ist. Mit SFTP überspringen Benutzer stattdessen einfach Informationen über den Hostschlüssel und akzeptieren alles, sodass das Ergebnis dasselbe ist.
• Benutzer und Administratoren mit mehr Wissen können SSH-Schlüssel jedoch ordnungsgemäß verwenden und diese auch zur Authentifizierung verwenden Dann ist SFTP im Vergleich zur Verwendung von Passwörtern viel einfacher zu verwenden. Und wenn Passwörter überhaupt verboten sind, ist dies auch sicherer, da Brute-Force-Passwortangriffe nicht mehr möglich sind.
• FTP verwendet dynamische Ports für Datenverbindungen und Informationen über diese Ports werden im Band übertragen. Dies macht bereits einfaches FTP (ohne TLS) zu einem Albtraum, wenn es um Firewalls, NAT oder ähnliches geht. Mit FTPS (FTP + TLS) wird dies noch schlimmer, da aufgrund der Verschlüsselung der Steuerverbindung Helper-Anwendungen in der Firewall nicht mehr herausfinden können, welche Ports geöffnet werden müssen. Dies bedeutet, dass Sie zum Bestehen von FTPS eine Vielzahl von Ports öffnen müssen, was für die Sicherheit schlecht ist (*). SFTP ist viel besser, da es nur eine einzige Verbindung für Steuerung und Daten verwendet.
• FTP (S) -Server bieten häufig anonymen Zugriff und SFTP-Server normalerweise nicht. Mehrere FTP (S) -Server bieten auch Pseudo-Benutzer an, d. H. Benutzer aus derselben Datenbank oder ähnlichem, die keine echten Benutzer im System sind. Wenn Sie ohnehin nur richtige Benutzer haben, spielt dies keine Rolle.
• SFTP verwendet das SSH-Protokoll und Sie müssen das System ordnungsgemäß konfigurieren, um nur den SFTP-Zugriff und nicht auch den SSH-Zugriff (Terminal) oder sogar die SSH-Weiterleitung zuzulassen. Mit FTP ist dies einfacher, da FTP ohnehin nur eine Dateiübertragung durchführen kann.

(*) Mehrere Kommentare glauben nicht wirklich, dass das Öffnen einer Vielzahl von Ports die Sicherheit beeinträchtigt. Lassen Sie mich dies näher erläutern:

• FTP verwendet separate TCP-Verbindungen für die Datenübertragung. Welche Ports für diese Verbindung verwendet werden, ist dynamisch und Informationen über diese werden innerhalb der Steuerverbindung ausgetauscht. Eine Firewall, die nicht weiß, welche Ports derzeit verwendet werden, kann nur einen großen Portbereich zulassen, der möglicherweise manchmal über FTP verwendet wird.
• Diese Ports müssen den Zugriff von außen nach innen ermöglichen, da im passiven FTP-Modus die Der Client stellt eine Verbindung zu einem dynamischen Port auf dem Server her (dh relevant für die serverseitige Firewall), und für den aktiven FTP-Modus stellt der Server eine Verbindung zu einem dynamischen Port auf dem Client her (relevant für die clientseitige Firewall).
• Mit einer breiten Eine Reihe von Ports, die für uneingeschränkten Zugriff von außen nach innen geöffnet sind, wird normalerweise nicht als restriktive Firewall angesehen, die das Innere schützt. Dies ähnelt eher einem großen Loch in der Tür, durch das ein Einbrecher ins Haus kommen könnte.
• Um dieses Problem zu umgehen, verwenden die meisten Firewalls "Helfer" für FTP, die die FTP-Steuerverbindung untersuchen, um herauszufinden, welche Ports für die nächste Datenverbindung geöffnet werden müssen. Ein Beispiel ist ip_conntrack_ftp für iptables. Leider ist bei FTPS die Steuerverbindung (normalerweise) verschlüsselt, sodass diese Helfer blind sind und die erforderlichen Ports nicht dynamisch öffnen können. Dies bedeutet, dass entweder FTP nicht funktioniert oder eine Vielzahl von Ports ständig geöffnet sein muss.

Der Systemadministrator wirft einen gültigen Punkt auf. (aber seine zwischenmenschlichen Fähigkeiten erfordern möglicherweise Arbeit)

SSH ist ein komplexes Protokoll, und openssh implementiert viele Funktionen. Alle diese Funktionen bietet Angriffsvektoren an, und es ist sehr schwer sicher zu sein, dass keiner dieser Vektoren ausnutzbar ist.

Auch wenn openssh keine Fehler aufweist (was nicht der Fall ist), wissen Sie über die richtigen Möglichkeiten zum Schließen Bescheid Unerwünschte Funktionen und das Verständnis, wie diese Optionen interagieren können, sind an sich mit erheblichem Aufwand verbunden. Diese Interaktionen können sich von Version zu Version ändern.

Betrachten Sie als Beispiel das folgende Snippet sshd_config . Dies hat die Absicht, bestimmte Benutzer auf SFTP-only zu beschränken (wir haben sogar daran gedacht, sie an ihre Home-Verzeichnisse zu sperren):

  Match Group sftponly ChrootDirectory% h ForceCommand internal-sftp  

Und sicher genug:

 % ssh somehostDieser Dienst erlaubt nur SFTP-Verbindungen. Verbindung zu einem Host-Clo sed.  

Aber warten Sie ...

  ssh -N -L 9000: localhost: 80 somehost  

Hoppla, ich habe jetzt Port 80 auf somehost an Port 9000 auf meinem Host weitergeleitet. Das bedeutet, wir können eine Verbindung zu Port 80 auf somehost herstellen, als ob wir von localhost kommen Für Port 80 keine große Sache, aber was ist mit Diensten, die nur auf localhost lauschen, wie z. B. Verwaltungsdienste oder Datenbanken?

Und das ist nur TCP-Weiterleitung. Zumindest SSH ermöglicht auch die Weiterleitung von X11 und SSH-Agenten, und ich kenne nicht einmal die Auswirkungen dieser beiden.

Wir verwenden häufig ssh / sftp, da für unsere Situation die Vorteile diese Risiken überwiegen. Aber es ist ein berechtigtes Anliegen, das nicht zu leicht genommen werden sollte. Wir haben dies für Anwendungsfälle erreicht, in denen nur sftp ausreicht:

  Match Group sftponly ChrootDirectory% h X11Forwarding no AllowTcpForwarding no AllowAgentForwarding no ForceCommand internal-sftp  

Wir hoffen, dass dies ausreicht, um nur SFTP-Zugriff zu gewährleisten, können uns jedoch nicht ganz sicher sein. (Vorschläge willkommen;)

Beide Protokolle haben Vor- und Nachteile, wie in diesem Vergleichsartikel sehr gut erläutert.

Da sich die Frage speziell auf die Sicherheit bezieht, gibt es einige Überlegungen, die sollte bei der Auswahl des Protokolls berücksichtigt werden, das unter bestimmten Bedingungen am besten geeignet ist.

FTPS und FTPES verwenden SSL oder TLS, um die Steuerung / Daten zu verschlüsseln Verbindungen. Der Hauptvorteil dieser sicheren Kanäle besteht darin, dass sie X.509-Zertifikate verwenden, die viel mehr Informationen enthalten als ein einfaches Schlüsselpaar (Hostname, E-Mail-Adresse, Organisationsname, ISSUER (CA), ...) und daher a viel einfacher zu validieren. Aber:

• SSL 1.0 , SSL 2.0 : vor langer Zeit veraltet (unsicher)
• SSL 3.0 : Vor kurzem wegen POODLE
• TLS 1.0 veraltet : Für die PCI-Konformität nicht mehr akzeptabel
• TLS 1.1 : Es fehlen einige der Erweiterungen von TLS 1.2 und die Client-Unterstützung ist eingeschränkt. Es gibt keinen Grund, sie zu verwenden.
• TLS 1.2 : aktueller Standard, der bisher als sicher / sicher li angesehen wurde >

Und das Obige deckt nur das Verschlüsselungsprotokoll des Kanals ab, dann gibt es Sicherheitsüberlegungen bezüglich des FTP-Protokolls selbst. Der Befehl SITE wurde beispielsweise immer wieder verwendet, um Angriffe auszuführen, und das inhärente Design des Protokolls selbst erfordert das Öffnen und NAT mehrerer Ports in Ihrer Firewall (was zu einem Albtraum werden kann) ). Darüber hinaus können die meisten Firewalls FTP-Datenverbindungen nur dann ordnungsgemäß NAT-Verbindungen herstellen, wenn der Client dies anfordert und der Server CCC (Clear Control Channel) zulässt, wodurch ein Teil der Sicherheit beeinträchtigt wird, indem die Steuerverbindung unverschlüsselt ausgeführt wird.

Auf der anderen Seite haben wir SFTP , ein Subsystem von SSH . Die größte Herausforderung besteht darin, dass SSH-Schlüssel "nur Schlüssel" sind, nicht von einer Zertifizierungsstelle ausgegeben werden und keine Ausstelleranweisung oder Schlüsselkette enthalten ist. Daher müssen SSH-Serverschlüssel vom Client ausdrücklich als vertrauenswürdig eingestuft werden .

Jemand könnte argumentieren, dass die Konfiguration eines SSH-Servers so, dass nur SFTP (keine Shell, keine Befehle, keine Weiterleitungstunnel, kein X11) zulässig ist, schwierig sein kann. Das hängt tatsächlich davon ab: Wenn Sie Linux und OpenSSH ausführen, ist dies möglicherweise der Fall, aber es gibt eine Vielzahl von SSH / SFTP-Servern, die diese Art der Konfiguration zum Kinderspiel machen. Daher würde ich dies nicht unbedingt als potenziellen Fehler auflisten. es sei denn, wie gesagt, Linux / OpenSSH werden verwendet.

Einige bemerkenswerte Nebeneffekte von SFTP sind jedoch:

• ECDSA-Schlüsselaustausch : Ein 521-Bit-ECDS (X) -Schlüssel entspricht in Bezug auf die Sicherheit einem 15.360-Bit-RSA-Schlüssel und erfordert 9-mal weniger CPU-Zyklen für die Signaturberechnung.
• Inhärente Weiterleitung Geheimhaltung : Das SSH-Protokoll kann den tatsächlichen Kanalverschlüsselungsschlüssel in der Sitzung neu aushandeln und bietet im Gegensatz zu SSL / TLS-fähigen Servern, für die zusätzliche Konfigurationsarbeiten erforderlich sind, eine inhärente Weiterleitungsgeheimnis.

Letztendlich liegt die Wahl also wirklich bei Ihnen, aber das Argument, das der Systemadministrator vorbrachte, ist offensichtlich ungültig, und wenn es einen vorhandenen SFTP-Server gibt, ist dies der Fall Gut konfiguriert (wie erläutert), gibt es keinen Grund (insbesondere keinen sicherheitsrelevanten Grund), auf FTPS (oder FTPES) umzusteigen.

Viele Leute sprechen gültige Punkte über die Unterschiede zwischen den beiden Protokollen an. Aber ich denke für Ihre Zwecke lautet die Frage wirklich: "Ist SFTP sicher genug?" eher als "welches ist sicherer"?. Wie Sie gesagt haben, haben Sie andere Bedenken als nur die Sicherheit.

Dies stellt sich als schwierig zu lösendes Problem heraus. SSH wurde ausgiebig genutzt und ausgiebig untersucht. Es sind keine Fehler im Protokolldesign bekannt. Sicherheitslücken haben jedoch häufig nichts mit dem Protokoll und alles mit der Implementierung zu tun. Immerhin ist SMTP selbst nicht "unsicher" und relativ einfach im Design, aber vor 16 Jahren war die gemeinsame SendMail-Anwendung eines der Aushängeschilder schlecht implementierter Software-Sicherheit und hatte Loch für Loch.

Selbst wenn das Protokoll gut gestaltet und einfach ist, kann die Implementierung ein Nest voller Komplexität, zusätzlicher Funktionen und Sicherheits-Albträume sein.

Ich denke also Es geht mehr darum, eine gute UMSETZUNG als ein gutes Protokoll zu wählen. Beide Protokolle sind in Ordnung und beide Implementierungen können schlecht implementiert werden.

Ich bin mit FTPS nicht ganz vertraut, daher weiß ich nicht, ob es angesehene Implementierungen davon gibt. Für SSH wird OpenSSH jedoch allgemein als qualitativ hochwertig angesehen und wurde von Grund auf unter Berücksichtigung der Sicherheit (Trennung von Berechtigungen usw.) entwickelt.

Wie Sie dachte ich, beide wären fast gleich, als ich im Internet nach ihren Unterschieden suchte.

Im wirklichen Leben ist es jedoch eine andere Geschichte. Im Folgenden habe ich folgende Erfahrungen gemacht:

1. Bei meinem NAS habe ich die FTPS-Funktionalität 3 Monate lang aktiviert. Das Firewall-Setup war in Ordnung. Ich musste nur den FTP-Port und einige weitere Ports öffnen, die für die FTPS-Übertragung verwendet wurden. So weit so gut, keine große Sache.

2. Nach 3 Monaten schalte ich möglicherweise auch das SFTP-Protokoll ein, da es häufiger und wahrscheinlich einfacher ist verwalten. Dann passierte etwas Interessantes. 10 Minuten nachdem ich den SFTP-Port geöffnet hatte, war mein NAS einigen blauen Flecken ausgesetzt. Der NAS blockierte die angreifende IP nach 10 fehlgeschlagenen Kennwortversuchen automatisch und benachrichtigte mich per E-Mail. Stellen Sie sich vor, wenn der Angreifer die Kontrolle über Tausende von Computern mit unterschiedlichen IP-Adressen hätte, könnte mein NAS sie nicht alle stoppen. Wenn sich die Mitarbeiter unseres Unternehmens dazu entschließen, ein wirklich einfaches Passwort einzurichten, kann die Person, die den Angriff mit blauen Flecken anwendet, möglicherweise in unser System gelangen.

ol>

Nun, da ich SFTP deaktiviert, der Angriff gestoppt und ich bin froh, dass niemand mehr versucht, auf unseren Dateiserver zu gelangen.

Nein, SSH und SSL verwenden normalerweise dieselbe Verschlüsselungsstärke. Beispiel: RSA und AES, aber SSH kann DSA verwenden. Aber ssh verwendet Port 22. Aber FTPs verwenden Port 21 und 22 für FTP- und FTP-Daten. Obwohl es meiner Meinung nach besser konfigurierbar ist, müssen Sie 2 Ports öffnen, was nicht nur angesichts von Firewalls unpraktisch ist, sondern auch ein potenzielles Sicherheitsrisiko darstellt, da Sie 2 Ports öffnen müssen.

Die Antwort ist irgendwie stumpf, egal in welche Richtung Sie in Ihrer Rhetorik gehen. Serverseitige Mittel werden von der Person gesteuert, die die Datei bereitstellt, und theoretisch sicherer, wenn alle Sicherheitsmerkmale bekannt sind.

Eine benutzerseitige Methode wäre dieselbe, jedoch für den Benutzer. In diesen Tagen stellen wir die Beziehung der beiden nicht in Frage. Jeder muss sich seiner Fähigkeit versichern, sich ausreichend zu schützen. Benutzer wenden sich daher einer Option für Firewalls zu.

Jede Option, die Sie für den Benutzer auswählen, kann auf diese Weise leicht außer Kraft gesetzt werden. Daher machen wir uns keine Sorgen um den Benutzer (Empfänger). Diese Rhetorik ist in dieser Angelegenheit jetzt überholt.

Ihr Anliegen sollte sich auf Ihre eigenen Wertpapiere beziehen. Dies würde Server-Seite bedeuten. Sie möchten die Kontrolle über die von Ihnen freigegebenen Informationen. Wie viel Sorge nach der Veröffentlichung ist nicht mehr umsichtig. Es liegt einfach nicht in Ihrer Verantwortung darüber hinaus. Nur was Sie in der Folge betrifft. Wenn Sie noch keine Daten dazu haben, haben Sie keine Konsequenzen.

Eine wirklich kontrollierbare Lösung wäre die Verwendung einer FTP-Quelle mit Verschlüsselung nach Ihrem eigenen Entwurf. Verlassen Sie sich nicht auf Dritte. Aber auch dies ist veraltet, da es schwierig ist, eigene Bibliotheken von Anfang bis Ende zu erstellen.

Basierend auf den von Ihnen unzureichend angegebenen Terminologien möchten Sie ein einfaches SSH-FTP. Dazu können Sie lediglich Firewall-Regeln und Iptables-Konfigurationen vorschlagen (unter Linux). Sie scheinen in beiden Fällen mit WYSIWYG festzuhalten.