El 2004-06-17 a las 18:53 -0400, pedritoelescamoso@tutopia.com escribió:
Gracias, si el wuftp no venia con la distribucion (suse 8.2) pero tengo que instalarlo para un trabajo de la universidad. en fin te agradezco mucho
Pues entonces instala el paquete "ftpdir", que te pone eso que te falta precisamente para el usuario anónimo. Sobre lo que te dije de la seguridad, te copio lo que dicen los del vsftpd (very secure ftpd): An example of insecure design ============================= Examples of insecure design may be found in most other ftpd's. That's one of the reasons vsftpd has been written. We'll pick on wu-ftpd as as pecific example, since it is rumoured to run about half of all ftp services. If I log on to wu-ftpd as an anonymous user, a process is run on my behalf to serve my ftp session. Unfortunately, this process typically runs with full root privileges on the remote machine. This means that any security flaw present in parsing the copious ftp protocol will lead to full compromise of that machine. Two concrete examples are the recent wu-ftpd format string bug (June 1999), and a buffer overflow dealing with large paths a few months beforehand. O sea, empieza por poner el "wu-ftpd" como ejemplo de inseguridad - por poner uno, pero escoge precisamente ese. En otro fichero, "TRUST" dice más - precisamente sobre lo que decía de tener que poner el binario del ls: 1) External /bin/ls helper A very common operation asked of FTP servers is to provide a directory listing. Unfortunately, convention seems to be to emit the directory listing in UNIX "/bin/ls -l" format. Even the Microsoft FTP service can be observed to do this. When writing an FTP server for the UNIX platform, then, this leads to the temptation to reuse /bin/ls as a child process, to avoid having to rewrite a load of code to handle directory listings. Even more unfortunately, FTP server writers seem to want to adopt the versatility of the average /bin/ls implementation. This means they allow clients to specify arbitrary parameters to /bin/ls. By using an external /bin/ls command, we would tie the security of our FTP server to that of the /bin/ls code. Be careful not to underestimate the amount of code paths in /bin/ls which are explorable by a remote malicious user. GNU /bin/ls has a myriad of options. Some of these options are complex such as -I or the various formatting options. All it takes is a single coding flaw in the handling of one of these options, and your FTP security is in trouble. By using an external /bin/ls, you also inherit the risk of any dangerous or complex APIs it uses. For example, calls to libc's complex fnmatch() or glob() functions, which will get given arbitrary malicious user controlled data as the search patterns. Also remember that users (and sometimes remote users) can upload/create files, and filenames are a very prominent input to /bin/ls. To conclude: vsftpd has no intention of using an external /bin/ls program because of the risks outlined above. Even if I were to audit e.g. GNU fileutils /bin/ls, and also important parts of glibc, this would still leave security in an unknown state on other platforms. The solution I have employed is to write a minimal internal implementation of a /bin/ls listing generator; it's hardly difficult. As a happy side effect, this will boost performance by avoiding unneccesary fork()s and exec()s! Here's some quick data about FTP servers which tend to use external ls programs: ftp.wuftpd.org: ftp> ls --version 227 Entering Passive Mode (x.x.x.x.x.x) 150 Opening ASCII mode data connection for /bin/ls. ls (GNU fileutils) 3.16 226 Transfer complete. ftp.digital.com: ftp> ls -v 227 Entering Passive Mode (x.x.x.x.x.x) 150 Opening ASCII mode data connection for /bin/ls. /bin/ls: illegal option -- v usage: ls [ -1ACFLRabcdfgilmnopqrstux ] [files] 226 Transfer complete. Note that /bin/ls is not the only external program invoked by common FTP servers such as wu-ftpd. wu-ftpd also has the ability to invoke "tar" and "gzip" on the fly, so there are trust relationships there too. -- Saludos Carlos Robinson