Slashdot Mirror

Anonymous FTP doesn't provide support for partial retransmission

What? Since when? You have to be a schmuck to support resuming anonymous uploads, but you can even do that!

You get the same overall behavior as FTP, but you gain the ability to pause downloads, the ability to secure those downloads if you want to (with TLS), the ability to have passwords that are not sent in the clear, etc.

You can do all of that with FTP, too. FTP already permits resuming downloads, FTPS is already FTP with TLS, and already protects your password.

It's probably still smarter to use a web interface, but not because FTP can't be secured. It's only because users will have to download a secure FTP client, and they already have a web browser.

The vulnerability could have been this bug:

http://bugs.proftpd.org/show_bug.cgi?id=3521

This bug would have allowed them full access to the machine, assuming the daemon ran as root. I certainly had a few Plesk machines that were compromised by this bug. It's a pain clearing out rootkits from the system, I can tell you.

The bug was patched a month ago, so their server could have been exploited for that long, with crackers setting up backdoors into the system to regain root access. Just a hypothesis.

Plain text passwords

I'm pretty sure that's not the only way to use ProFTPD.

http://www.proftpd.org/localsite/Userguide/linked/config_ftpoverssh.html

I dislike the 'why would you want to do that attitude as well, but I've found this to kind of be a universal problem, not just Linux related.

And I know this is a bit of a tangent, but what you probably want (ie, what the Linux guy probably should have told you about) is FTP over SSL. Something like ProFTPd can do this. It's just like a normal FTP server other than the encryption, you can set up virtual users and everything.

http://ftp1.us.proftpd.org/pub/electronic-publications/stay-free/archives/18/loewen.html

Well, education-particularly when it comes to any sort of social study-is very much a mixed blessing in America. Probably the best way to explain this is to give you an example. I once did an exercise where I asked people about what kind of adults, by education level, supported the war in Vietnam. By an overwhelming margin-almost 10 to 1-audiences responded that college-educated people were more likely to be for withdrawing the troops, were more "dovish". When they explained their reasoning, they usually wrote that educated people are more informed and critical and therefore better able to figure out that the war wasn't in our best interests. Well, the truth was very different. Educated people disproportionately supported the war in Vietnam, were more "hawkish." Today, most people agree the Vietnam war was a mistake. So, if we follow conventional wisdom, it turns out that the more educated a person was, the more likely s/he was wrong about the war.

Now, when I asked my audience why educated Americans supported the war, they couldn't figure it out. One thing I heard is that since working-class young men had to go to war, naturally they and their families opposed it. But research shows that when people expect to go to war-whatever educational level they are-they tend to support that war. Because of cognitive dissonance, people come to believe in what they have to do. So I pointed out that there are two social processes, both tied to school, that could help explain why educated people supported the war. One, educated Americans tend to be more successful and affluent, and thus have more allegiance to society. They have a strong incentive for believing that American is fair because it means they earned their success. Two, education is socialization, and socializing teaches people how to conform to the needs of society. The more schooling, the more socialization.

We like to believe schooling is a good thing. But when it comes to understanding any problem with historical roots, we might expect that the more traditional schooling in history that Americans have, the less they will understand it.

Students who have taken math courses are better at math. The same is true for English, foreign languages, and almost every other subject. But in history, stupidity is the result of more, not less, schooling.

im glad to know freebsd is safe. makes me wonder why there is more development and fanatisicm for linux, when its clearly inferior.

There really is no need for an AuthShadowFile directive. The purpose of a shadow file is separate sensitive information (e.g. passwords) from other account information (username/UID/GID, etc). Programs like /bin/ls often reference the passwd file in order to display user/group names rather than numbers; these programs do not really need that sensitive information. Rather than relying on programs like /bin/ls to ignore the sensitive information, libraries were developed to split the information into /etc/passwd, /etc/shadow (and similarly for /etc/group, but very few administrators use group passwords anymore). Some operating systems, most notably FreeBSD, though, chose a different form of information separation. Since FreeBSD maintains account information in binary database files, the shadow libraries mentioned above are not used. Instead, FreeBSD returns the sensitive information to the calling program only if it has sufficient (i.e. superuser) privileges.

from http://www.proftpd.org/localsite/Userguide/linked/ x839.html
of all places heh

> ... I would personally settle for a configuration file format
> which isn't confusing, poorly organized, and often times not
> parsed correctly (ie, apache doesn't do what the docs imply). ...

When I encounter comments such as that, I immediately wonder if the author has difficulty using computers in general.

The Apache file format is the most logical, flexible, scalable, and easiest to maintain, and includes some of the best documentation I've ever seen compared to commercial and other free software. I particularly like the way Virtual Hosts are handled, and how the Location section directives make it so easy to do so much with very little effort. I've had zero problems with HTTPD.CONF file modifications, and particularly appreciate Apache's refusal to load when an error is encountered (configuration files should always be perfect).

In my own projects, I'm adopting this format, and am currently starting work on a Java library to read configuration files that are formatted in the same manner as Apache's HTTPD.CONF so that I can maximize flexibility while maintaining simplicity in future server and other applications that are on my drawing board.

When evaluating new products, if a product has a proper implementation of the Apache-style configuration file format it automatically gets a higher rating in my scoring system.

Some folks think XML is the way to go. It certainly has its uses, but I'm not a big fan of overhead, and when it comes to network management it's obvious that Apache's format is much easier to maintain in this regard. I'm very disappointed that Apache James uses XML for its configuration files, and this is one of the many reasons I don't bother with James at all.

There are other products that use the same configuration file format as Apache's, such as ProFTPD ( http://www.proftpd.org/ ), and this is a trend that I hope continues with other well-managed projects (both free and commercial).

--
Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com/

This message originated from within a secure, reliable,
high-performance network ... a Novell NetWare network.

I just add a bit on that list from top of my head.
Although I think the listed app goes beyond what the so called 'average pc user' wants, but there goes...

1. Konqueror ( http://www.konqueror.org/ )

2. Email - Sylpheed ( http://sylpheed.good-day.net/ )

3. I think Evolution is more like in this place.

4. Lately "Sound Juicer" is taking more attention too

5. VideoLAN aka VLC ( http://www.videolan.org/ ) and Ogle ( http://www.dtek.chalmers.se/groups/dvd/ ) [and Goggles ( http://www.fifthplanet.net/goggles.html ) for Ogle GUI wrapper] for DVD watching.

6. There are plenty way to do this, but the typical ones could be 'Jinzora' ( http://www.jinzora.org/ ) and 'MusicPD' ( http://www.mpd.org/ ), even plain Apache does it fine too, in a way.

8. If you want easier to manage iptables wrapper, Shorewall ( http://www.shorewall.net/ ) and there are other wrappers too.

9. KOffice ( http://www.koffice.org/ ) and by individual components, Abiword ( http://www.abisource.com/ ), Gnumeric ( http://www.gnome.org/projects/gnumeric/ ), Gnucash ( http://www.gnucash.org/ )

10. Inkscape ( http://www.inkscape.org/ ) or Sodipodi ( http://www.sodipodi.com/ ) for vector graphics.

11. Miranda ( http://miranda-im.org/ ). Windows only.

13. Hmm , Samba? ( http://www.samba.org/ ), WedDAV (Look parent post), FTP (plenty ftp daemons, ex : http://www.proftpd.org/, http://vsftpd.beasts.org/ etc)

16. GPhoto ( http://www.gphoto.org/ ), EOG ( http://www.gnome.org/ ? ), GQView ( http://gqview.sourceforge.net/ ). The latters are for just viewing mainly.

20. FreeNX ( http://www.nomachine.com/ , http://freenx.berlios.de/ ) http://www.poptop.org/ ), L2TPd ( http://sourceforge.net/projects/l2tpd ), RP-L2TPd ( http://sourceforge.net/projects/rp-l2tp/ )

24. Postfix ( http://www.postfix.org/ ), Sendmail ( http://www.sendmail.org/ ), Exim ( http://www.exim.org/ ), Cyrus ( http://asg.web.cmu.edu/cyrus/imapd/ ), Xmail ( http://www.xmailserver.org/ ), qmail ( http://www.qmail.org/ )

25. Spamassassin ( http://spamassassin.apache.org/ )

26. Same as above.

27. XSane ( http://www.xsane.org/ ) for sane frontends.

30. Buzzmachines ( http://www.buzzmachines.com/ ) I could be wrong...

31. 'various GUI frontends' - X CD Roast ( http://www.xcdroast.org/ ), K3B ( http://k3b.sourceforge.net/ )

32. Don't know any opensource ones...

IMO, these guides are useful for general Linux users who want a guide to various tools on their desktop.

Slackware users, on the other hand, tend to prefer a more terminal/console-centric view, so the usefulness of this guide to anyone using Slackware for, as I've usually seen it, a server of some kind [printer, file, FTP, web], would probably do better to read some other documentation.

Just my $0.25.

Plus you're still configuring an ftp server (I haven't done it yet, but it looks harder than adding a share to my smb.conf).

I guess this article was written before the ftp.gnu.org compromise. However, has there been *any* reason given on why ftp.gnu.org was running wu-ftpd ( which has a restrictive license) when there are at least 2 GPL ftp daemons ( proftpd and vsftpd) available? Especially given wu-ftpd's long, sad history of insecurity.

Good backup systems like Amanda already exist - I'm guessing that the reason that the FSF people don't have backups is because they're relying upon donations to buy backup servers/tape drives, etc. (Yes that was a subtle plea to donate them cash ;)

On this breakin I have only two comments:

1. Why not use proftpd, wu-ftpd has traditionally been prone to attacks. (Granted its a little bit more secure after each one is discovered and patched, but after so many its hard to trust it).

2. Why use MD5 sums? I use GPG signatures on all my software - forging signatures is .. non-trivial.

wu-ftpd? wtf?

even the worthless security audits I had here two years ago had in their recommendations to switch any wu-ftpd servers to ProFtpd

href=http://www.proftpd.org

These GNU guys spend to much time in politics and too little in stuff that matters (like maintaining their servers)

cheers.

most daemons/services are capable of authenticating users via PAM or from an SQL database.

for apache, PAM auth, mysql auth and postgresql auth.

for ftp you could use proftpd and ignore system accounts completely, it supports quite a few alternative methods.

for the email solution use something like vpopmail with no system users and supported by quite a few MTA/POP3 agents.

If you don't want the OS to handle the passwords, then you can set it up so it doesn't. By default system accounts are normally used which I assume is from the era of people having shells and doing * from it, ftp/read mails/etc in which case things would use the standard system accounts..

If I remember clearly, FTP is prefered over HTTP for downloading larger files for various reasons. First of all, HTTP is stateless, meaning it will accept your connection, pump out whatever data it returns and doesn't do much more really. FTP isn't stateless, meaning you connect to it, it responds, negotiates a transfer and actively tries to keep things going, resulting in (somewhat) slower initial connection because of more protocol overhead, but far more reliable down/uploads. Also, FTP security can be as good as you want it to be. Disallow anonymous access, set proper users accesses, chroot them into their home directory and use a decent, up-to-date server such as Proftpd. Also, you can't (easily) upload files with HTTP, though it is possible. However, FTP uploading is far more elegant and again, more reliable.

For security, proftpd no SITE command

What ftpd daemon are/were you using? ProFTPD can limit the number of connections per host (I set my limit to 2 so people could use a bwoser to see what's on the server & an FTP client to do the download).

"Security through obscurity is bad!" What other forms _are_ there? Passwords and encryption _is_ the same as obscurity.

Huh? You obviously thought long and hard about this one. Let me try to keep it simple.

* Security through passwords - there is something hard to guess which you and your computer know. If anyone else guesses this, they get access.

* Security through 'obscurity' with exploitable software - there is something which anyone can download which contains the information required to access your system without guesswork.

* Not telling someone when there's a hole that $BADGUY knows of a piece of software they're running (until the patch gets out),

IS LIKE

* not telling someone that you've discovered that $BADGUY knows their password (until you kill $BADGUY).

Seriously, if you know that someone's password is compromised, you tell them immediately so they can disable the account or change their password. If you know that someone's software is compromised, you tell them immediately so they can disable the server or change their software .

*plink*

There are solid competitors for all of these.

ftpd: Proftpd wins, hands down. Configuration is like Apache except less crufty. It's modular, and pretty secure too (I can't remember hearing of any major security holes). Some people who use it: ftp.gnu.org, download.sourceforge.net. Enough said. www.proftpd.org.

bind: bind 9? I can't really think of a replacement except DNScache, and I've never used it. I have no idea if it's better or worse or just weaker.

sendmail: I hear qmail is extremely good, if you don't mind DJB's bizarre lack of license (also applies to DNScache). Qmail purportedly runs Yahoo! Mail among others. Otherwise, the only other alternative I can think of is exim, which is designed to be easier to configure and simpler IIRC.

Next time, post some links or something. Sheesh.

Daniel

Anyone using wu-ftpd has only themselves to blaim if anything happends to their servers. This application has a bug history making Microsoft look like what OpenBSD claims to be. There are many free and secure and certainly more extensible options available, so why distros still stick with wu is beyond my understanding.

First off.. Do not just "Scrub" the system. Wipe the HD, LLFing if possible. Backup data files first, via the network to a known good server first (via anon FTP so any remaining sniffers, etc, will not read any important password).

Then go and reinstall a recent Linux distro. I recommend Slackware. It may not have the bells & whistles of Red Hat, but its BSD-style init scripts are easy (easy as config.sys and autoexec.bat) to learn, and tends to ship with reasonably secure daemons. Of course, OpenBSD is another possible solution :-)

Now, if you want to just give them FTP access (and nothing else), ProFTPD provides a nice solution. Granted, earlier versions had some interesting security holes (poke), recent versions have been a lot better security wise. Set it up with mod_linuxprivs (which uses the POSIX.1e interface of 2.2.x and later kernels to drop all root privs except for the ability to bind to ports less than 1024). (For the configure impaired, try "./configure --prefix=/usr --with-modules=mod_linuxprivs").. This lets them have ftp access (I'd also recommend you setup ProFTPD to chroot the various users to their homedirs). Disable telnet. Install SSH or OpenSSH and only allow your own login to use it (login.access allows this). Only allow your user to execpt su (perhaps as part of the wheel group), and have your root password as something other than your normal account password. At this point, you will have a secure system, FTP access for normal users, and secure remote access for your own administration. Of course, this doesn't get you out of your duties to monitor Bugtraq for possible advisories. I also recommend (very much so) that you read LASG -- the Linux Administrator's Security Guide. It's very good :-)
---

It's avaliable here: here and the website is here.
Funny how Freshmeat's description of it is
"Advanced, incredibly configurable and secure FTP daemon"
This will probably be counted against them, despite it not really being their fault.