Veilige FTP-server vsftpd verbetert SSL-ondersteuning
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.
SSL zou niet meer gebruikt moeten worden. Als het nou een TLS server was, dan zou het super zijn.
Eind sarcasme
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.
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.
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 .
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 .
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.
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-.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?