Het probleem met FTP

Probleem 1 - FTP

FTP staat voor File Transfer Protocol en is een systeem om bestanden te transfereren. Het systeem bestaat letterlijk al jaren en wordt nog steeds gebruikt om websites op onze servers te zetten.

FTP dateert dus vanuit de tijd dat het Internet één grote, blije familie was waarin niemand kwade bedoelingen had met elkaar. Het is een protocol gebaseerd op een tekst-dialoog tussen client (jij) en server. Hier even wat er gebeurt na een succesvolle verbinding tussen client en server:

Geniaal in zijn eenvoud, nietwaar. Alleen zijn er twee problemen:

De dialoog gebeurt in leesbare tekst over het internet. Iedereen die tussen client en server zit, kan de dialoog meevolgen en dus ook wachtwoorden proberen te onderscheppen.

FTP is soms moeilijk aan de praat te krijgen op bepaalde netwerken. Ik wil niet teveel in detail treden, maar iedereen die al eens geworsteld heeft met Active en Passive mode, weet wat ik bedoel.

Vooral het eerste probleem weegt zwaar door. Vandaag zit het internet vol met kwaadwilligen en je kan het echt niet meer maken om wachtwoorden in leesbare tekst over het internet te sturen.

FTP gets an ‘F’ for Fail

Daarom doen wij al geruime tijd geen FTP meer.

Oplossing 1 - Weg met FTP

Voor elk probleem is er een oplossing: Secure FTP (ook wel eens 'FTP over SSH' genoemd).

SFTP is losjes gebaseerd op FTP, maar bevat een extra laag. De dialoog wordt namelijk niet rechtstreeks over internet gestuurd, maar wordt ingebed in een SSH (Secure Shell) sessie. Die sessie bouwt eerst een volledig beveiligde verbinding op tussen client en server, en gaat dan pas over tot de eigenlijke actie. Hierdoor is alles, inclusief het uitwisselen van wachtwoorden, volledig geëncrypteerd.

Een mogelijke hacker die zich tussen client en server heeft kunnen plaatsen, ziet dus alleen een geëncrypteerde stroom aan gegevens, waar hij niks mee kan doen.

Het enige dat je moet doen om dit te gebruiken i.p.v. FTP, is dit aan te vinken in de instellingen. Elke moderne FTP-client biedt deze optie.

Als je 'gewoon' wil FTP'en, heb je genoeg informatie en mag je hier stoppen met lezen.

Probleem 2 - wachtwoorden

Een volgende zwakke plek die we kunnen aanpakken zijn wachtwoorden. Denk even na over wat je kan met een wachtwoord en hoe dit eigenlijk werkt. Op onze server heb je een map waarin je bestanden wil plaatsen via SFTP. En dan liefst jij alleen, je wil niet dat anderen jouw site kunnen aanpassen. Dus geven we enkel toegang tot die bestanden als je een geldige gebruikersnaam/wachtwoord combinatie kent.

Nu gaan we wat technischer worden.

Die gebruikersnaam slaan wij op op onze server. Jaren geleden sloegen we ook het wachtwoord op. Nu slaan we alleen het wachtwoord in geëncrypteerde vorm op, omdat wij geen zaken hebben met hoe jouw wachtwoord eruit ziet. In geval van een ernstige compromittering van een server bij ons, kunnen zo ook geen wachtwoorden buitgemaakt worden.

Als jij een wachtwoord kiest, b.v. 'abc123' gaat onze server deze eerst omzetten naar een hash, bijvoorbeeld '2c6c8ab6ba8b9c98a1939450eb4089ed'. Het unieke aan een hash is dat je wel van het wachtwoord de hash kan maken, maar dat als je de hash hebt, je nooit het wachtwoord kan vinden. De hash van een bepaald wachtwoord is altijd hetzelfde.

(Nota voor de nerds onder jullie: ja ik gebruik hier md5 als voorbeeld, in werkelijkheid worden betere algoritmen gebruikt. Ik doe dit bewust, want als ik een sha512-voorbeeld zou geven, zouden er toch zijn die opmerken dat ik beter bcrypt zou doen. Of als ik bcrypt zou nemen, enz…. :))

Neem dan de volgende fictieve dialoog even terug (en veronderstel dat deze onder SFTP gebeurt):

Dus het is niet het wachtwoord zelf dat vergeleken wordt met de gebruiker op de server, maar de hash van dat wachtwoord. Dus onze server heeft nergens jouw wachtwoord opgeslagen. Mooi toch, waar zit dan die zwakke plek?

De zwakke plek is de gebruiker, jij dus. Want jij vinkt altijd aan dat jouw FTP-programma je wachtwoord moet opslaan. En om bovenstaande dialoog met de server te kunnen doen, moet jouw FTP-programma het wachtwoord opslaan in leesbare tekst.

Het gebeurt nog steeds dat we zien dat hackers op deze manier wachtwoorden verzamelen en sites op onze servers hacken. Ze doen dit via malware, spyware, virussen, ….

Jij slaat die wachtwoorden nooit op? Flink zo, maar ook dan kan je problemen hebben. Misschien heb je wel ergens een mail staan met die wachtwoorden die je van je hostingprovider kreeg. Of heb je die wachtwoorden gedeeld met iemand, b.v. een programmeur die aan je site werkt. Of binnen je bedrijf kende iedereen het FTP-wachtwoord, maar zijn er mensen vertrokken uit je bedrijf die nog steeds aan je site kunnen. Al bij al, genoeg reden om te kijken naar een oplossing voor het gebruik van wachtwoorden.

Oplossing 2 - weg met wachtwoorden

Zou het niet fijn zijn dat jij jezelf op ondubbelzinnige wijze kan identificeren bij onze server, zonder dat er een wachtwoord voor nodig is?

Wel, dat is mogelijk met SSH. We gebruiken hiervoor private en public key authentication. Dit is een geavanceerd, maar toch gebruiksvriendelijk concept, waarbij jij met sleutels op je PC werkt.

Zo'n sleutel (key) wordt volkomen willekeurig gegeneerd, en komt altijd in paartjes. Een private key:

en een public key:

Private en public key zijn onlosmakelijk met elkaar verbonden en zijn nutteloos zonder elkaar. Hoe werkt dit nu?

De private key mag jouw computer of beveiligde omgeving nooit verlaten. Je mag die nooit delen met iemand. Nooit! Als jij verbinding maakt met onze server, gaat jouw private sleutel gebruikt worden om een geëncrypteerde stroom gegevens te maken. De server heeft jouw publieke sleutel, en kan die stroom van gegevens ontcijferen.

De clou van het verhaal is dat niemand jouw gegevens zo kan versleutelen dat hij ontcijferd kan worden met jouw public key. Dus als de gegevensstroom kan ontcijferd worden met jouw publieke sleutel is de server 100% zeker dat jij het bent.

Dit concept staat of valt natuurlijk met de geheimhouding van je private key. Je kan stellen dat als je een virus hebt op je PC, deze private key ook in gevaar is. Voor dit geval kan je best nog een extra wachtwoord (pass phrase) zetten op je private key. Dat is dan weer een wachtwoord, zeg je? Ja, maar wel een wachtwoord dat jij in je hoofd hebt en NERGENS opslaat.

Bijkomend voordeel van deze aanpak is dat ieder zijn eigen sleutelpaar heeft. Dat betekent dat jij ook een heel duidelijk beeld hebt van wie er allemaal aan je server kan, hierover later meer.

In de volgende titels leggen we uit hoe je dit concreet doet.

Op de Mac-client

Nu kan je je publieke sleutel opvragen:

Op de Windows-client

Op Windows is SSH nog niet ingebouwd, al zou daar wel verandering in komen. Ondertussen kan je bijvoorbeeld PuTTYgen gebruiken. Als je PuTTYgen opent, klik je op Generate om een key te maken:

Daarna moet je een beetje met je muis bewegen, om de key echt random te maken:

En tenslotte krijg je je public en private key:

Op de server

Eerst moet je je public key aan het controlepaneel toevoegen. Dit is eenmalig, want je gebruikt jouw public key voor al je projecten, dat is wel zo makkelijk.

Daarna zeg je gewoon op de website wie er allemaal toegang mag hebben:

Hier zie je heel goed wie er allemaal toegang heeft tot een map of een server. Als iemand jouw organisatie verlaat, is het enige dat je moet doen zijn publieke sleutel van de server te halen.

Meer lezen?

https://filecamp.com/blog/top-5-reasons-ftp-dead/

https://ksantema.wordpress.com/2010/12/07/ftp-is-dead-now-will-someone-tell-developers/