image

Veilige FTP-server vsftpd verbetert SSL-ondersteuning

zondag 26 juli 2015, 12:16 door Redactie, 8 reacties

Voor gebruikers van FTP (File Transfer Protocol) die op veilige wijze bestanden willen uitwisselen bestaat al enige tijd de FTP-server 'vsftpd' en in de nieuwste versie is de ondersteuning van SSL verder verbeterd. Standaard worden bestanden en inloggegevens niet versleuteld bij het gebruik van FTP. Een aanvaller die de verbinding kan afluisteren kan zodoende allerlei gegevens achterhalen.

Chris Evans, hoofd van het Google Chrome Security Team, ontwikkelde enkele jaren geleden daarom vsftpd, wat staat voor very secure FTP daemon. Volgens Evans is vsftpd "waarschijnlijk de veiligste en snelste FTP-server voor UNIX-achtige systemen". Zo ondersteunt de FTP-server SSL. Daardoor is het mogelijk om versleuteld op vsftpd-servers in te loggen en gegevens uit te wisselen. De laatste versie van vsftpd dateerde van 18 september 2012, maar nu is er een nieuwe versie verschenen.

Daarin heeft Evans de SSL-ondersteuning verder verbeterd en verschillende maatregelen getroffen die aanvallen moeten voorkomen. Ook is er ondersteuning van Elliptic curve Diffie–Hellman (ECDH) toegevoegd. Volgens Evans is het gebruik van SSL in combinatie met FTP nog steeds "tricky" en zijn alle problemen nog niet 100% opgelost. Toch zou een combinatie van de meest recente versie van het FTP-programma FileZilla met vsftpd een goede start zijn voor gebruikers die SSL over FTP moeten gebruiken, zo merkt hij op.

Reacties (8)
26-07-2015, 12:30 door Anoniem
Even sarcastische:
SSL zou niet meer gebruikt moeten worden. Als het nou een TLS server was, dan zou het super zijn.
Eind sarcasme
26-07-2015, 13:05 door Anoniem
Wat is er mis met sftp dan? Dat is toch ook beveiligd?
26-07-2015, 13:28 door Anoniem
Wat mij betreft zouden we zo snel mogelijk moeten stoppen met FTP. Het protocol is nooit met beveiliging in gedachte ontworpen en heeft daardoor verschillende problemen. Het beste alternatief is SFTP, wat ook weer een aantal problemen met zich meebrengt, omdat het op SSH gebouwd is en je toch regelmatig met lapmiddelen werkt om de Shell toegang voor je SFTP gebruikers te ontzeggen.
26-07-2015, 16:41 door Anoniem
Door Anoniem: Wat is er mis met sftp dan? Dat is toch ook beveiligd?

Tegen wie ?

sftp heeft heel erg de gedachte dat de inloggers gebruikers (met shell accounts en homedirs) op de sftp server zijn.
Dat is helemaal geen gewenste use-case , in veel gevallen.

FTP daemons zijn veel vaker gebouwd met het idee dat een ftp user helemaal geen volledige systeem user hoeft te zijn, maar erg beperkt is in wat & waar de ftp user mag uploaden.
Dat past veel beter in allerlei scenario's (denk : webhosting zonder 'eigen' virtuele server) dan sftp .

Encryptie van login credentials (en data transport) is ook een stuk veiligheid, maar andere veiligheid dan het limiteren van die users in wat ze op de server kunnen, en het isoleren van de ftp daemon op het systeem.
26-07-2015, 18:58 door karma4
Door Anoniem: andere veiligheid dan het limiteren van die users in wat ze op de server kunnen, en het isoleren van de ftp daemon op het systeem.
Laat nu altijd de verhalen horen dat Unix/Linux zo veilig is omdat je de rechten zo goed kan instellen. Wil je nu beweren dat er niets van waar is?

Er is wel zeker een pijnpunt met dat on regelen. Je hebt meer functionele Accounts en groepen nodig. Geen punt meer de limiet van max 16 groepen per account is verleden tijd bij goede systemen. Helaas weten veel Unix security mensen dat (nog) niet. Dan blijft alleen nog het managen van al die groepen over met zetten DAC rechten.

Het is wat primitiever dan met AD dan wel RACF waar je het nesten van groepen kan regelen. Niet echt een probleem dwingt je beter er over na te denken.
26-07-2015, 22:00 door Anoniem
Door karma4:
Door Anoniem: andere veiligheid dan het limiteren van die users in wat ze op de server kunnen, en het isoleren van de ftp daemon op het systeem.
Laat nu altijd de verhalen horen dat Unix/Linux zo veilig is omdat je de rechten zo goed kan instellen. Wil je nu beweren dat er niets van waar is?

Er is wel zeker een pijnpunt met dat on regelen. Je hebt meer functionele Accounts en groepen nodig. Geen punt meer de limiet van max 16 groepen per account is verleden tijd bij goede systemen. Helaas weten veel Unix security mensen dat (nog) niet. Dan blijft alleen nog het managen van al die groepen over met zetten DAC rechten.

Het is wat primitiever dan met AD dan wel RACF waar je het nesten van groepen kan regelen. Niet echt een probleem dwingt je beter er over na te denken.

Dat een mechanisme voldoende uitdrukkingsmogelijkheden heeft om iets te bereiken maakt het nog geen _geschikte_ oplossing.
Het is heel makkelijk om een model wat veel complexiteit in user/groepen legt (evt met ACLs erbij, en selinux) per vergissing of na een paar rondes historische bagage teveel rechten weg te geven.
Te weinig merkt je wel , te veel merkt je niet of als het vervelend mis gaat.

"Dwingt je er beter over na te denken" is in security termen bijzonder gevaarlijk - de praktijk is dan dat er rechten en groepen worden bijgegooid "totdat het werkt" .

Kortom - beginnen met een 'normale' user en die beperken totdat hij nog kan werken maar verder ongevaarlijk is, of beginnen met een "user" die alleen in de context van een ftp daemon betekenis heeft .
De tweede versie is makkelijker om goed te doen dan de eerste .
27-07-2015, 07:52 door karma4
Door Anoniem:
je er beter over na te denken" is in security termen bijzonder gevaarlijk - de praktijk is dan dat er rechten en groepen worden bijgegooid "totdat het werkt"

Kortom - beginnen met een 'normale' user en die beperken totdat hij nog kan werken maar verder ongevaarlijk is, of beginnen met een "user" die alleen in de context van een ftp daemon betekenis heeft .
De tweede versie is makkelijker om goed te doen dan de eerste .
Met je betoog van te veel rechten uitdelen wat je moet inperken ben ik het eens. Het is 1 van de controls genoemd in de iso27002. Control 9.2.3 noemt het omgaan met high privileged data actie en waar je over moet denken. Die heb je hierbij genegeerd. Dat is niet goed.

Het terugbrengen van complexiteit door het goed te ontwerpen is een taak van de security architect die ook de techniek snapt.Een lastige combinatie.
Met een begrijpbare naamgevingsconvetiecen IAM tools als hulpmiddel breng je het werk terug tot uitvoeren van simpele opdrachten. Het overzicht sool/ist is iets wat daarmee aan richtlijnen kan voldoen.

Een security dan wel os admin die naar eigen inzicht maar wat aan rommelt is zelf een security gevaar. Het is denk ik vaak de praktijk. Kwaliteit heeft zijn prijs en security is een sluitstuk geen basis.

Dat je beweerd dat je de eerste keer gewoon trial en error aan de slag gaat zodat je een tweede keer dat zelfde trucje nog eens kan herhalen is choked vanuit naïviteit.
28-07-2015, 05:05 door Anoniem
Door karma4:
Met een begrijpbare naamgevingsconvetiecen IAM tools als hulpmiddel breng je het werk terug tot uitvoeren van simpele opdrachten.

http://apps.nrc.nl/stijlboek/begrijpbaar

Schrijf niet: ,,Het moet ook voor mensen boven de grote rivieren begrijpbaar zijn'', maar: ,,te begrijpen zijn'' of ,,begrijpelijk zijn''. Hetzelfde geldt voor: onklopbaar, ontvangbaar, onmisverstaanbaar, ontoereikbaar, onreinigbaar. Dat moet respectievelijk zijn: niet te kloppen, niet te ontvangen, niet mis te verstaan, niet toereikend, niet te reinigen. Zie ook: -baar, woorden die eindigen op-.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.