Från den säkerhet de ger i teorin är FTPS och SFTP lika. I praktiken har du följande fördelar och nackdelar:

• Med FTPS klientapplikationer misslyckas ofta att certifiera certifikaten ordentligt, vilket effektivt betyder att människan i mitten är möjlig. Med SFTP istället hoppar användare helt enkelt över information om värdnyckeln och accepterar vad som helst, så resultatet blir detsamma.
• Men användare och administratörer med mer kunskap kan använda SSH-nycklar ordentligt och använda dessa också för autentisering som gör sedan SFTP mycket lättare att använda jämfört med att använda lösenord. Och om lösenord alls är förbjudna är detta också säkrare eftersom lösenordsattacker med brute force inte längre är möjliga.
• FTP använder dynamiska portar för dataanslutningar och information om dessa portar överförs i bandet. Detta gör redan vanlig FTP (utan TLS) till en mardröm när brandväggar, NAT eller liknande är inblandade. Med FTPS (FTP + TLS) blir detta ännu värre eftersom på grund av krypteringen av kontrollanslutningens hjälpapplikationer på brandväggen inte längre kan ta reda på vilka portar som behöver öppnas. Detta innebär att för att klara FTPS måste du öppna ett stort antal portar som är dåligt för säkerheten (*). SFTP är mycket bättre eftersom det bara använder en enda anslutning för kontroll och data.
• FTP (S) -servrar ger ofta anonym åtkomst och SFTP-servrar brukar inte göra det. Flera FTP (S) -servrar erbjuder också pseudo-användare, dvs. användare som tagits från samma databas eller liknande som inte är riktiga användare i systemet. Om du bara har korrekta användare ändå spelar det ingen roll.
• SFTP använder SSH-protokollet och du måste konfigurera systemet ordentligt för att endast tillåta SFTP-åtkomst och inte även SSH (terminal) -åtkomst eller till och med SSH-vidarebefordran. Med FTP är det enklare eftersom FTP bara kan göra filöverföring ändå.

(*) Flera kommentarer tror inte riktigt att det är dåligt för säkerheten att ha ett stort antal portar öppna. Låt mig därför förklara detta mer detaljerat:

• FTP använder separata TCP-anslutningar för dataöverföring. Vilka portar som används för dessa anslutningar är dynamiska och information om dessa utväxlas i kontrollanslutningen. En brandvägg som inte vet vilka portar som används för närvarande kan bara tillåta ett stort portområde som kanske kommer att användas ibland FTP.
• Dessa portar behöver tillåta åtkomst från utsidan till insidan eftersom i FTP passivt läge klienten ansluts till någon dynamisk port på servern (dvs. relevant för serversidan-brandväggen) och för FTP-aktivt läge ansluter servern till någon dynamisk port på klienten (relevant för klientsidan-brandväggen).
• Har en bred utbud av portar som är öppna för obegränsad åtkomst från utsidan till insidan är inte vad någon brukar betrakta som en restriktiv brandvägg som skyddar insidan. Detta liknar mer att ha ett stort hål i dörren där en inbrottstjuv kan komma in i huset.
• För att kringgå detta problem använder de flesta brandväggar "hjälpare" för FTP som undersöker FTP-kontrollanslutningen för att ta reda på vilka portar som måste öppnas för nästa dataanslutning. Ett exempel är ip_conntrack_ftp för iptables. Tyvärr med FTPS är kontrollanslutningen (vanligtvis) krypterad så att dessa hjälpare är blinda och inte kan öppna de nödvändiga portarna dynamiskt. Det betyder att antingen FTP inte fungerar eller att ett stort antal portar måste vara öppna hela tiden.

Sysadmin höjer en giltig punkt. (men hans interpersonella färdigheter kan behöva arbete)

SSH är ett komplext protokoll och openssh implementerar mycket funktionalitet. All denna funktionalitet erbjuder attackvektorer, och det är väldigt svårt att vara säker på att ingen av dessa vektorer kan utnyttjas.

Även om openssh är utan buggar (vilket det inte är), vet man om alla rätt möjligheter att stänga av oönskad funktionalitet och att förstå hur dessa alternativ kan samverka kräver betydande ansträngning i sig. Och dessa interaktioner kan ändras från version till version. som har för avsikt att begränsa vissa användare till endast SFTP (vi tänkte till och med att låsa dem i deras hemkataloger):

  Matcha grupp sftponly ChrootDirectory% h ForceCommand intern-sftp  

Och nog:

 % ssh somehost Den här tjänsten tillåter endast sftp-anslutningar. Anslutning till somehost clo sed.  

Men vänta ...

  ssh -N -L 9000: localhost: 80 somehost  

Oj, jag har nu vidarebefordrat port 80 på somehost till port 9000 på min värd. Det betyder att vi kan ansluta till port 80 på somehost som om vi kommer från localhost. Troligen inte en stor sak för port 80, men hur är det med tjänster som bara lyssnar på localhost, som administrativa tjänster eller databaser?

Och det är bara TCP-vidarebefordran. SSH tillåter också vidarebefordran av X11 och vidarebefordran av SSH-agenter, och jag vet inte ens konsekvenserna av dessa två.

Vi använder ssh / sftp mycket, för för vår situation överväger fördelarna dessa risker. Men det är ett giltigt problem som inte bör tas för lätt. Vi slutade med detta för användningsfall där bara sftp räcker:

  Matcha grupp sftponly ChrootDirectory% h X11Forwarding no AllowTcpForwarding no AllowAgentForwarding no ForceCommand intern-sftp  

Vi hoppas att detta är tillräckligt för att säkerställa bara sftp-åtkomst, men vi kan inte vara helt säkra. (förslag välkomna;)

Båda protokollen har fördelar och nackdelar, vilket förklaras mycket bra i denna jämförelseartikel.

Detta sagt, eftersom frågan specifikt gäller säkerhet, finns det några överväganden som bör beaktas när man väljer vilket protokoll som är bäst under vissa specifika förhållanden.

FTPS och FTPES använder SSL eller TLS för att kryptera kontrollen / data anslutningar. Den största fördelen med dessa säkra kanaler är att de använder X.509-certifikat, som innehåller mycket mer information som ett enkelt nyckelpar (värdnamn, e-postadress, organisationsnamn, ISSUER (CA), ...) och därför är en mycket lättare att validera. Men:

• SSL 1.0 , SSL 2.0 : utfasad för länge sedan (osäker)
• SSL 3.0 : nyligen avskaffat på grund av POODLE
• TLS 1.0 : inte längre acceptabelt för PCI-överensstämmelse
• TLS 1.1 : saknar några av tilläggen av TLS 1.2 och har begränsad kundsupport, ingen anledning att använda den
• TLS 1.2 : nuvarande standard, hittills betraktad som säker / säker

Och ovanstående täcker endast kanal (s) krypteringsprotokoll, då finns det säkerhetsöverväganden när det gäller själva FTP-protokollet. Kommandot SITE har till exempel använts om och om igen för att utföra attacker, och den inneboende utformningen av själva protokollet kräver att flera portar öppnas och NAT på din brandvägg (vilket kan bli en mardröm att hantera ). Dessutom kan de flesta brandväggar inte korrekt NAT FTP-dataanslutningar såvida inte klienten begär det och servern tillåter CCC (Clear Control Channel) som besegrar en del av säkerheten genom att köra kontrollanslutningen okrypterad.

Å andra sidan har vi SFTP , vilket är ett delsystem för SSH . Den största utmaningen här är att SSH-nycklar är "bara nycklar", de utfärdas inte av en CA och inget utgivaruttal eller nyckelkedja ingår i dem, därför måste SSH-servernycklar uttryckligen lita på av klienten .

Någon kan hävda att det kan vara svårt att konfigurera en SSH-server så att den bara tillåter SFTP (inget skal, inga kommandon, inga vidarebefordranstunnlar, ingen X11). Det beror faktiskt: om du kör Linux och OpenSSH kan det vara sant, men det finns en uppsjö av SSH / SFTP-servrar där ute som gör denna typ av konfiguration till en vind, så jag skulle inte nödvändigtvis lista detta som en potentiell brist, om inte - som sagt - Linux / OpenSSH används.

Ett par anmärkningsvärda sidofördelar med SFTP inkluderar dock:

• ECDSA-nyckelutbyte stark >: en 521-bitars ECDS (X) -nyckel motsvarar en 15.360-bitars RSA-nyckel när det gäller säkerhet och kräver 9 gånger mindre CPU-cykler för signaturberäkning
• Inneboende framåt sekretess : SSH-protokollet kan omförhandla den faktiska kanalkrypteringsnyckeln under sessionen och ger inneboende framåtriktad sekretess, i motsats till alla SSL / TLS-aktiverade servrar som kräver ytterligare konfigurationsarbete för att uppnå detta

Så i slutändan är valet verkligen upp till er, men argumentet som sysadmin gjorde är uppenbart ogiltigt, och om det finns en befintlig SFTP-server som är väl konfigurerad (som förklaras) så finns det ingen anledning (särskilt ingen säkerhetsrelaterad anledning) att byta till FTPS (eller FTPES).

Många tar upp giltiga punkter om skillnaderna mellan de två protokollen. Men jag tror att för ditt ändamål är frågan verkligen "Är SFTP säker nog?" snarare än "vilken är säkrare" ?. Som du har sagt har du andra bekymmer än bara säkerhet.

Detta visar sig vara ett svårt problem att lösa. SSH har använts i stor utsträckning och har studerats i stor utsträckning. Det finns inga kända protokolldesignfel. Säkerhetsproblem har dock ofta inget att göra med protokollet och allt att göra med implementeringen. När allt kommer omkring är SMTP i sig inte "osäker" och är relativt enkelt i designen, men för 16 år sedan var commmon SendMail-applikationen en av affischbarnen till dåligt implementerad mjukvarusäkerhet och hade hål efter hål i den.

Poängen är att även om protokollet är väl utformat och enkelt, kan implementeringen vara en råtta av komplexitet, lägga till funktioner och säkerhetsmardrömmar.

Så jag tror att handlar mer om att välja ett bra IMPLEMENTATION snarare än ett bra protokoll. Antingen protokoll är bra, och antingen implementeringen kan dåligt implementeras.

Jag är inte helt bekant med FTPS, så jag vet inte om det finns några väl respekterade implementeringar av det. För SSH betraktas dock OpenSSH i allmänhet som hög kvalitet och utformades med säkerhet i åtanke från grunden (privatseparation osv.).

Precis som du trodde jag att båda var nästan desamma när jag gick igenom webben och letade efter deras skillnader.

Men i verkligheten är det en annan historia. Nedan var min upplevelse:

1. För min NAS aktiverade jag FTPS-funktionen i tre månader. Konfigurationen av brandväggen var ok. Jag var bara tvungen att öppna FTP-porten och några fler portar som användes av FTPS-överföring. Hittills så bra, ingen stor sak.

2. Efter tre månader räknar jag, meh, kanske jag slår på SFTP-protokoll också eftersom det är vanligare och förmodligen lättare att klara av. Då hände något intressant. 10 MINUTER efter att jag öppnat SFTP-porten var min NAS utsatt för några attacker med blåmärken. NAS blockerade automatiskt den angripande IP: n efter 10 misslyckade lösenordsförsök och meddelade mig via e-post. Tänk dig om angriparen hade kontroll över tusentals datorer som alla hade olika IP-adresser, skulle min NAS inte kunna stoppa dem alla. Om personalen i vårt företag bestämmer sig för att skapa ett riktigt enkelt lösenord, kan den som använder attacken mot blåmärken så småningom komma in i vårt system.

Nu när jag inaktiverade SFTP, attacken stoppade och jag är glad att ingen försöker komma in på vår filserver längre.

Nej, SSH och SSL använder vanligtvis samma chifferstrenth. t.ex. RSA och AES, men SSH kan använda DSA. Men ssh använder port 22. men FTP använder port 21 och 22 för FTP- och FTP-data. att det enligt min mening är bättre konfigurerbart, du måste öppna 2 portar, vilket inte bara är opraktiskt med tanke på brandväggar utan också en potentiell säkerhetsrisk, eftersom du måste öppna 2 portar.

Svaret är ganska trubbigt antingen vilken väg du går i din retorik. Meddelanden på serversidan styrs av den som ger filen och är teoretiskt säkrare om man känner till alla säkerhetsfunktioner.

En användarsidesmetod skulle vara densamma men för användaren. I dessa dagar ifrågasätter vi inte förhållandet mellan de två. Var och en måste försäkra sig om sina förmågor för att skydda sig tillräckligt. Användare vänder sig därför till ett alternativ för brandväggar.

Alla alternativ du väljer för användaren kan lätt åsidosättas på sådana sätt. Därför oroar vi oss inte för användaren (mottagaren). Denna retorik är föråldrad nu i denna fråga.

Din oro bör vara på dina egna värdepapper. Detta skulle innebära serversidan. Du vill ha kontroll över informationen du släpper. Hur mycket oro efter att det släppts är inte längre klokt. Det är helt enkelt inte ditt ansvar bortom den punkten. Endast det som påverkar dig som en följd. Om du inte har några uppgifter om detta har du ingen konsekvens.

En verkligt kontrollerbar lösning skulle vara att använda en FTP-källa med kryptering helt efter din egen design. Lita inte på någon tredje part. Men även detta är föråldrat eftersom det är svårt att bygga egna bibliotek från början till slut.

Baserat på de terminologier du tillhandahåller otillräckligt vill du ha en enkel ssh ftp. För det är allt du kan göra att föreslå brandväggsregler och iptables-konfigurationer (om i Linux). Du verkar sitta fast med WYSIWYG hur som helst.