R.I.P. FTP

Slashdot contributor Bennett Haselton says "Using FTP to administer a website is insecure -- but not for the reasons that you probably think. You yourself can stop using FTP any time you want, but how do we change the landscape Net-wide, to reduce the number of breakins using stolen FTP credentials?" You know what to click on if you want to read the rest.

On July 1st I found that one of my less important websites, hosted on a low-cost shared Web hosting service, had been broken into. A friend emailed me to say that the site was showing up in Google's search results with the Google "This site may harm your computer" warning listed next to it. I found that on one of the pages, about 1,500 HTML script tags had been inserted, loading JavaScript files from pseudo-random Russian hostnames like "www.chk06.ru" and "www.errghr.ru", none of which are currently resolving. Usually, when such script tags are maliciously inserted into a page on a website, the script tags attempt to install spyware on the machines of people who visit the site.

I immediately replaced the infected file on the website with the backed-up clean copy from my machine, and changed the password on the website in case the attacker had gotten in by using the old one. (The original file with the script tags inserted is here if you want to examine it, but use with caution -- if the .ru hostnames in the script tags start resolving again, then opening the file could cause the JavaScript on the pages to be loaded, which might infect your machine.) Then I started investigating (a) how this probably happened; (b) whether future similar attacks could be prevented, by changing some defaults in the way that hosting accounts are set up; and (c) whether the incentives for hosting providers are such that these changes are likely to happen by themselves, or whether it will require some third-party advocacy to change what we think of as "best practices".

Denis Sinegubko, the webmaster of Unmask Parasites, a free service that scans websites on demand for signs of break-ins, says:

The majority of web site compromises happen because of:

1. Stolen FTP credentials. Spyware on webmasters' computers: key-loggers, traffic sniffers (FTP protocol sends username/password as plain text), trojans that steal credentials from various programs' configuration files (FTP clients, DreamWeaver, etc).
2. Security holes in popular web software: CMS (Joomla, Drupal, etc), Forums (phpBB, vBulletin, Simple Machines, etc), Blogs (WordPress). Once a vulnerability discovered, hackers configure their automated tools to search the web for websites running vulnerable versions of the software and exploit them. This can be done easily and at almost no cost when they have an army of zombie computers.
3. Security hole in "in-house" web software. Many novice (and even many experienced) web developers don't properly sanitize user input making various attacks possible (SQL injections, XSS, etc)
4. Poor security practices (Something that should be manually configured by site/server admins and cannot be fixed with automated security updates): Weak passwords, open ports, insufficiently strict permissions for limited accounts, files and directories with world write permissions, etc.

I didn't have any third-party web software or custom-made software installed on the PublicEditorMyAss.com site, the password was a seven-letter meaningless mix of letters and numbers, and I didn't have permission to change most of the things like open ports and file permissions. That left the possibility of stolen FTP credentials. This is in fact what Sinegubko says is the most common cause of such break-ins:

I guess 90% of attacks use stolen FTP credentials this year. Check this Google's graph that shows the top 10 malware sites as counted by the number of compromised web sites that referenced it:
http://googleonlinesecurity.blogspot.com/2009/06/top-10-malware-sites.html

I reviewed 4 most widespread of them (Gumblar, Martuz, Goooogleadsense, Googleanalytlcs). All four used stolen FTP credential to penetrate web sites and upload malicious content. The chances are the rest used this vector too.

When the PublicEditorMyAss.com site was set up, the default setting was for pages to be edited over FTP. Even though FTP sends and receives passwords without encrypting them (in contrast with alternatives like SFTP or "secure FTP", which encrypts passwords), for a long time I had assumed that this was not a major security problem, because in order for an attacker to intercept the passwords in transit, they would have to control a machine somewhere on the path between my home computer and the PublicEditorMyAss.com server. I figured this wasn't worth worrying about, because it was much more likely that an attacker would attempt to steal the password by installing spyware on my home computer. And if an attacker managed to do that, then I assumed that the risk of passwords being stolen by spyware was about the same whether I used FTP or SFTP -- because either way, the spyware could just steal my password by reading it out of a configuration file where the password was stored. (Even though FTP and SFTP programs both store passwords in an encrypted format, the programs have to be able to decrypt the passwords in order to use them whenever the user wants to open a connection. So the spyware could just mimic whatever steps the client programs use to decrypt the stored passwords, in order to steal one of my passwords stored in a file.) So, I assumed it made no difference whether I used FTP or SFTP.

But according to what Sinegubko told me, this reasoning was probably wrong. The problem is that even though spyware installed on your machine could read passwords that are stored in configuration files, it would be a lot of work to write a spyware program that could do this, because every FTP program and SFTP program stores passwords according to a different algorithm. It's much simpler for spyware to simply watch the traffic sent and received from your machine, so that any unencrypted passwords will be spotted:

[Passwords can be stolen by] sniffers that read all TCP traffic on local computers. Like personal firewalls but malicious. They can easily intercept FTP credentials since they are sent as a plain text.

Sinegubko describes how one of his contacts obtained evidence that a common spyware program was doing exactly this:

One of them even infected a spare WinXP computer (with Gumblar) to test the consequences. On the infected computer he created a new account in a popular FTP client and saved it. The server address was correct (his server) and the username/password pair was not valid. A few hours later in FTP logs, he discovered login attempts that used that invalid username/password pair from a Singapore IP, then from a Florida IP, the some other country's IP. Apparently the FTP credentials were somehow stolen from that infected computer.

I know of only two instances where I've ever definitely been infected with spyware. I don't do stupid things like downloading and running strange programs from third-party sites, so I think both infections were probably caused by a site exploiting a security hole in Internet Explorer, or in a plug-in like Adobe Acrobat or the Flash player. Both times, once I noticed I was infected, I got rid of the infection with Malwarebytes, but I don't know how much damage the spyware did in the meantime.

So this was a case where a little knowledge can be a dangerous thing. If I had known nothing about Internet architecture, and someone told me "FTP is less secure than SFTP," I would have found a way to switch to administering the site via SFTP. But because I knew that the main reason FTP was considered "insecure" was because it transmitted passwords unencrypted, but I also knew that most of of the machines relaying those passwords in transit were secure and trustworthy, I thought it didn't matter. Now it seems that is probably how my password got compromised after all.

In that case, why don't more people switch to administering their sites via SFTP instead of FTP? Here are the steps it took me to enable SFTP on my GoDaddy hosting account. Feel free to use this as a reference, but the obvious point is that as long as this many steps are required, it's safe to say that most users won't be switching:

1. Go to the "Hosting" menu and pick "My Hosting Account."
2. Next to the name of your website, pick "Manage Account." This will open the Hosting Control Center.
3. In Hosting Control Center, click to expand the "Settings" options.
4. In the "Settings" control panel, click the "SSH" icon.
5. You will see a page saying "SSH is not set up", and prompting you to enter a phone number so that their automated service can call you with a PIN number. After you enter your phone number, the phone rings a second later, and you enter the PIN in a form on the GoDaddy website.
6. You will then see a page which says:

   Current Hosting Account Status: Pending Account Change
   Your request to enable SSH is being processed. This upgrade may take up to 24 hours.

In fact, even if only one step were required to switch, most users probably wouldn't change from the default setting to use FTP, due to the eternal, unchangeable fact that most people do not change their default settings, ever. (What percent of users ever change the default set of toolbars that are displayed at the top of their Web browser window?)

If more Web hosting companies made SFTP the default, then the number of websites that were compromised by stolen login credentials, would probably go down. Spyware authors might start to make their programs smarter at that point, enabling them to read the passwords stored by popular FTP and SFTP programs, so that it would make no difference whether the passwords were transmitted in the clear or not. However, this would be harder for spyware authors to do correctly, so it would at least raise the bar for a successful malware attack, and the number of compromised websites would be reduced.

Unfortunately, Web hosting companies don't have much incentive to make users switch to the more secure SFTP protocol. This isn't necessarily true of all security risks; sometimes the hosting company has a strong incentive to pass on the right wisdom (and select the right default settings) for their customers. From the hosting company's point of view, you could divide risks into three categories:

• Risks where the hosting company pays a large part of the price for a customer's machine being compromised. For example, if a cyber-criminal takes over a customer's machine and uses it to launch a denial-of-service attack by sending it a flood of traffic, the hosting company will see that traffic spike on their network. The hosting company has the most incentive to help prevent these types of attacks.

• Risks where the hosting company doesn't directly pay a price for the customer's machine being compromised, but they may have to deal with complaints sent in by third parties. For example, a customer's website could get broken into, and script tags could be inserted into the pages that cause visitors' machines to be infected with spyware. Those visitors might complain to the webmaster of the infected site, or they might complain to the hosting company, which then forwards the complaint to the webmaster. The hosting company may have to provide a few minutes of tech support to the customer, advising them to change their password and scan their own machine for spyware, but they probably won't incur any other material costs.

• Risks where neither the hosting company nor the customer pays a price for the machine being infected, but the price is paid by "Internet users as a whole." The only attack that I can think of in this category, is an attack where a cyber-criminal inserts key words into your web page and links them to his site, in order to increase his Google ranking for searches for those key words. Neither the website owner, nor any visitors to the website, are victimized directly; the harm being done is that the quality of Google search results is reduced for everybody. The only reports of the attack would probably come from "good Samaritan" Web surfers, who tell the hosting company or the webmaster that one of their pages has been vandalized.

When a customer's FTP credentials are stolen, the price paid by the hosting company lies somewhere in the middle. An attacker who stole my current PublicEditorMyAss.com credentials would only be able to deface the content on the site, but they wouldn't be able to launch an attack against a third-party network (my PublicEditorMyAss.com hosting account doesn't have the ability to initiate an outgoing connection to a third-party site).

Weighing in the other direction are the costs of switching to SFTP. If existing customers are forcibly switched over, phone lines will be clogged by customers wanting to know why their old method of logging in to their site has suddenly stopped working. A better choice would be to allow existing customers to stay with FTP while making SFTP the default for new customers. But there is a time and money cost of changing anything, even a default setting.

So GoDaddy doesn't have much incentive to make SFTP their new default. Indeed, I've used many different shared hosting companies before I started running proxies exclusively on dedicated servers, and none of the shared hosting companies ever used anything but FTP as the default method for customers to administer their websites. So who can blame them? They're not making the choice that makes the most sense for their customers or for Internet security as a whole, they're making the choice that makes the most sense in terms of costs and benefits for themselves, and I'm not being judgmental about that. We shouldn't expect most companies to ever behave in any other way.

That's why I think that glib "solutions" to security problems, like "Everybody install anti-virus software", or "Everybody stop using Windows", aren't helpful, because regardless of whether these ideas would work if everybody actually followed them, the fact is that most people won't. The problems have to be addressed in terms of changing incentives for the choices people make.

What's an idea for reducing the risks of FTP credentials stolen by malware, that addresses the incentives problem? Maybe give tax breaks to Web hosting companies that set up customer accounts to use SFTP instead of FTP by default? Or ask more computer vendors to include a desktop link to pre-installed SFTP software, so that when Web hosting companies present options to their customers, it's easier for users to choose the SFTP option since they have a client already installed? (I was tempted to recommend that Microsoft include a universal SFTP client pre-installed in Windows with a prominent desktop link, but the problem with that is that if almost everybody used the same SFTP client, malware authors would have greater incentive to reverse-engineer the algorithm that the client used to store saved passwords -- and then passwords would be just as easily accessible to spyware, as if the user were using FTP all along. So a good mix of SFTP clients is safer for this purpose.)

Since the difference between SFTP and FTP usually only matters in cases where a customer's machine has been infected with malware, obviously the best solution is to avoid malware altogether, but that's much harder problem to solve, as long as malware authors can keep finding security holes in Internet Explorer and other popular programs. Making SFTP the new standard for Web hosting accounts is something that we know how to do, right now. The incentives aren't currently right for Web hosting companies to make it happen. But there may be ways to change that, and I'll bet some people can think of better ideas than the ones I've suggested. I'm just saying that the incentives problem is where attention should be focused.

Comments

All you need to know:

[Godeke]

I know of only two instances where I've ever definitely been infected with spyware. I don't do stupid things like downloading and running strange programs from third-party sites, so I think both infections were probably caused by a site exploiting a security hole in Internet Explorer, or in a plug-in like Adobe Acrobat or the Flash player. Both times, once I noticed I was infected, I got rid of the infection with Malwarebytes, but I don't know how much damage the spyware did in the meantime.

Malwarebytes is good software, but as you point out you don't know how much damage was done. Secondary infections can easily be missed, and many malware programs open your machine to further exploitation. As tired as the suggestion is, you needed to do what you did with your website: revert the machine to a known good backup of the system state, formatting first. Anything less and you *should* have that nagging doubt that you haven't actually cleaned everything up. There are ways to diminish the concern: inspecting the machine for unexpected packet flows, using anti-rootkit tool, etc... but only by formatting and restoring a know clean state or formatting and just restoring your data files will you be confident).

Re:All you need to know:

[Phroggy]

This assumes your "known good" backup is really clean. If you can't tell whether your current system is clean after removing the malware, how can you know whether your last backup was clean?

Re:All you need to know:

[MindStalker]

Exactly. A reinstall of your operating system is your best bet. While you will obviously have to copy the files back over you should be able to scan the files before/during copying. The files will only reinfect upon launching them generally not upon copying them (some old DOS systems excluded).

Re:All you need to know:

[clam666]

I told you people the God-damned internet was going to be a problem when you bought it, and now you're messed it up real good.

Next time listen to Daddy. Your mother and I told you pr0n and dirty pictures would lead to nasty business. Now we can add this one to the list.

1. Blindness
2. Hairy Palms
3. Broke the God-damned internets

Re:All you need to know:

[BikeHelmet]

Some of the stuff that can be missed by a thorough examination can't be purged through a reinstall.

I'm talking about those nasty buggers that hide in the BIOS chips, and re-infect on OS reinstall.

My (current) computer has never been infected by a virus or any malware - but I'm so anal that I open any possibly dangerous links in Opera, with all plugins disabled, rather than my default browser. (Firefox)

I also type many sites into the address bar in a form that'll go through Google's servers(www.slashdot.org -> "slash dot"), rather than using bookmarks. That way it'll warn me if the site could infect me with something.

Re:All you need to know:

[Anonymous Coward]

But the most anal thing one could do, now that one can have a decent computer for cheap, would be to buy a computer that you use exclusively for secure connections, and for nothing else than secure connections. That way you could always be pretty damned sure that your secure computer is clean.

It would preferably a small portable computer, like a netbook that you can carry along with your main laptop on travels.

Back we go then...

[Canazza]

Back we go then to HTTP based web forms...

RIPFTP!

[SteveHeadroom]

Isn't that the sound someone makes after eating enough chili or lentils?

Re:RIPFTP!

[Kral_Blbec]

RIPFFFFFFTP

There fixed it for ya

Hmm

[Anonymous Coward]

Is this a plea for everyone on /. to come look at your site?

Re:Hmm

[mcgrew]

Many summaries are pleas for us to look at the submitters' sites, but some of those sites are indeed good. Others, however, are just to someone's blog when a link to usatoady or scientific american would be far better.

It's annoying when you submit a story with a good link, and two days later someone else posts the same story with a link to some lame blog.

Re:Hmm

[Anonymous Coward]

Capsule summary of post:
Once I had a site, publiceditormyass.com, unfortunately the ftp password to publiceditormyass.com was sniffed and login credentials were stolen. Then publiceditormyass.com had all kinds of pwnage script tags inserted. What happened next to publiceditormyass.com was bad. Then I restored publiceditormyass.com and wrote an article for ./ all about how publiceditormyass.com was hacked. The premise of the article about the publiceditormyass.com incident is that ftp is rip. Happily publiceditormyass.com lives on. I just want to conclude that publiceditormyass.com is not the subject of this article, cleartext passwords are. This is not a plug for publiceditormyass.com.

Amusingly..

[grasshoppa]

This came up in a class I took at college. It was a bullshit "internet concepts" class, where they talked about setting up a website, basically. One of the things they talked about was ftp and how it's used to upload content to your "web host". Needless to say I felt the need to hurt those responsible for promoting this crap. While I did the assignments as they wanted, I made it a point to try to educate people in the class as to the proper protocols to use for uploading content.

Re:Amusingly..

[Archangel Michael]

So, how does one upload to a website? CPanel? Secure Shell? Do Tell! You know, not everyone manages their own server ....

Re:Amusingly..

[Cheech Wizard]

Then they should have someone knowledgeable manage it for them.

Re:Amusingly..

[maxume]

If you are maintaining a local copy and then 'uploading' it to the server, you freaking use rsync. If your host doesn't support rsync, you quit them.

Re:Amusingly..

[grasshoppa]

scp would be my protocol of choice.

Re:Amusingly..

[shadowknot]

Given the fact that most websites will be hosted on a Linux box I would say that using either scp or sftp (both of which use the server's ssh server) is the most secure way to go. It's what I use and there is a GUI tool for those using Windows on the desktop (WinSCP). As for how you would get around this if using a Windows/IIS server I wouldn't have the first clue and my advice would probably be along the lines of "get a man's operating system and stop using asp"!

Re:Amusingly..

[Hatta]

Rsync.

Re:Amusingly..

[ThePhilips]

Given the fact that most websites will be hosted on a Linux box ...

That makes it easier. Most Linux systems I have installed in past years don't have ftpd preinstalled.

On security note, default configs of ftpds found in Fedora, SUSE and Debian are [censored] insecure: they allow anonymous to access anything on hard drive while rejecting (even over SSL) valid users.

Unfortunately, raw FTP still rules when you need a high bandwidth. With SCP/SFTP I get consistently 4-5 times lower transfer speeds compared to FTP. It doesn't matter much if one transfers megabytes. But SCP/SFTP becomes a pain when one needs to upload dozens/hundreds megabyte. 'tar cf - . | ssh tar xf -' trick speed things up, but not always available.

As for how you would get around this if using a Windows/IIS server I wouldn't have the first clue and my advice would probably be along the lines of "get a man's operating system and stop using asp"!

IIRC, M$ stack uses WebDAV over HTTPS for such stuff. Abomination had spared me, thus do not have any performance numbers.

Re:Amusingly..

[Mr. Slippery]

If you are maintaining a local copy and then 'uploading' it to the server, you freaking use rsync.

rsync can freaking use ssh, rsh, or its own daemon connection. Using an rsync:// or an rsh connection is freaking insecure. But freaking-a, rsync over ssh freaking rocks.

Re:Amusingly..

[HogGeek]

Personally I use, and recommend a version control system...

Re:Amusingly..

[CastrTroy]

Using SFTP as opposed to FTP won't help if they brute forced your password. While it is possible to read an FTP password as it travels over the wire, most hackers won't go to these lenghts to break into a shared hosting account. If they brute force your password, SFTP won't help you at all.

Re:Amusingly..

[MikeyinVA]

CPanel? Granted, some web hosting companies will give this to you free (HostGator)..most don't. And you may have money to BURNNNNNN but my gosh, do you want to pay $30 A MONTH for this? Use Webmin. It's free.

Re:Amusingly..

[HeronBlademaster]

I used to work at a place where we used SCP to throw files around on the local 10/100 network. Those transfers always maxed out the network speed (11MBps or so). FTP didn't go any faster... I'm guessing your problem was elsewhere :P

Re:Amusingly..

[OrangeTide]

It is easy to setup a server to blacklist IPs temporarily for bruteforce attempts. Just enough to make bruteforce inconvenient while not locking too many customers out of their own accounts.
I have this setup for ssh/scp/sftp on my servers, they even cooperate and share the blacklist data.

Re:Amusingly..

[Bert64]

SCP is 4-5 times slower than FTP? What kind of CPU do you have?
I am easily able to saturate a 100Mbit link using a core2 system thats a couple of years old now... Even on a 1Gbit link i think the disk is the bottleneck moreso than the encryption these days.. Yes it uses a lot more cpu, but it isn't any slower.

Perhaps you are using an extremely poor implementation of SCP?

Re:Amusingly..

[Tanktalus]

A tar trick? At least add Z, z, or j to the commands: tar cjf - . | ssh tar xjf -. Or, simpler, try rsync -avz --delete -e "ssh -l webhostuser" . myhost.org:. The bz2 compression (j option for tar) probably has better compression, but rsync compresses some things that tar can't (see rsync's man page).

Re:Amusingly..

[DavidTC]

While it is possible to read an FTP password as it travels over the wire, most hackers won't go to these lenghts to break into a shared hosting account.

You didn't read the fucking summary, did you? Apparently, malware is doing exactly that.

They figured that, since they were already intercepting net traffic (To screw with web traffic) they might as well sniff port 21 and see what passwords are being used for FTP.

They then use (probably automated) tools to break into the FTP site, see if there's any HTML files there, and add javascript that loads malicious pages.

Re:Amusingly..

[jafiwam]

Yes in the article the malware is sniffing packets.

There are important differences though, traditional thought of "sniffing packets" involves a third party on a third machine, not something slightly more sophisticated than a keylogger on the same machine. Actual third party packet sniffing is still relatively rare, and the overly-long example in the overly-long summary doesn't refute that.

It's Palin-drooling stupidly obvious that if you get something infecting your computer you are going to have security problems, so I am not even sure why it's worth mentioning.

On the other hand, if you run a server and inspect logs, you know that just about any service gets pounded with brute force attacks from all over (which I assume are zombie machines). You can even look at the usernames used and follow what zombie is working on what botnet because they come in alphabetical order.

So, yeah, brute forcing it is way more common because it doesn't require an infection. (Make a Venn Diagram of the people using FTP who also get infected regularly and you'll find it's not that much of the population.)

The simple solution is don't open the service (or otherwise deny) to unknown IPs. I have all my networks all mapped out so I can reject traffic coming from elsewhere, I assume it would be easy to make a "visit this web page first" script to temporarily activate an IP for FTP access. I haven't done it because my IP changes once per year or so so for me it's not a big deal to do it manually.

Re:Amusingly..

[JWSmythe]

    Actually, what I saw in the summary, for that which I read before I gave up, was that he suspected malware had intercepted his password. It's kinda silly having a packet sniffer listening to all passing traffic, when all they really needed to do was look in common places for stored passwords, and have a keystroke logger intercept interesting things. The later two I've seen quite a bit. The first, not so often.

    In working in a few hosting environments, from the admin side, I will say brute force attacks are anything but uncommon. Unfortunately, some people don't believe in upgrading anything ever. Yes, they do exist. So, they'll have 10+ year old unpatched machines without firewalls up on the Internet because "oh, who would find us?" On the same machines, you can see the FTP and SSH logs where people are attempting to brute force their way in.

    On machines that I personally have full admin control over, there are limitations to everything, even though it doesn't reflect back to the user. Sure, you can try to brute force your way in. It won't do you much good. But as far as you know, the failure notice from attempt #1 is just as legitimate as #10 and #100,000,000. Little does the aggressive hacker know, nothing beyond #5 was accepted, and his attempt on a live server was propagated to other machines under my control so they can protect themselves.

    Back to the original story. It was likely some malware that found auth files, found where the auth information is stored in their Windows registry, or captured the keystrokes. It may have been described in more detail somewhere in that novel that they called a summary, but I failed to read it all before my eyes started to bleed.

Re:Amusingly..

[ThePhilips]

Nothing special: Linux to Linux over GB LAN or the internet. CPUs are C2D or AMD X2 or better.

Also note that SCP/SFTP transfer files one by one and the handshake times (especially if you have number of smaller files) dominates over actual file transfer times. That's why I have mentioned the tar trick. FTP for whatever reasons doesn't have the problem.

Re:Amusingly..

[Bashae]

You'll be fine if you take care of your own computer (which you do indeed manage). This article states that FTP is insecure, but that is based on the assumption that everyone's computer is infected periodically. So if your server is secure and your computer runs a secure OS, or at least a good firewall, a good antivirus, all security patches and is periodically scanned for malware, I don't see what harm the evil spammers can possibly cause.

Personally I barely follow a half of that advice, and yet I am never infected. If you know what you're doing, all it takes is some common sense to keep you safe. Such as not downloading and running suspicious programs, keeping your web browser(s) fully patched and making sure they are not vulnerable (VERY important) and a strong firewall (even if you get infected, it can stop your pet trojan from sending your passwords away).

Re:Amusingly..

[ThePhilips]

Do not overoptimize - SSH already by default compresses its traffic with gzip. Bzip sure is better, but compression speed is not there what becomes visible on GB LAN.

Re:Amusingly..

[gmack]

Seconded. I've maxed out a 100 mbps link using scp on an inter isp transfer and the sending machine was a non raid dual 650 with 512 mb ram.

Unless one of your computers is older than that piece of crap you shouldn't notice a difference.

Re:Amusingly..

[ThePhilips]

OK. Lied. It is disabled by default but seems to be enabled selectively on my servers.

Re:Amusingly..

[ThePhilips]

What'a day... OpenSSH has compression enabled by default. It's official commercial SSH (which we happen to have on couple of old Tru64 DEC boxes) have it disabled by default.

Re:Amusingly..

[gmack]

On security note, default configs of ftpds found in Fedora, SUSE and Debian are [censored] insecure: they allow anonymous to access anything on hard drive while rejecting (even over SSL) valid users.

Not sure where you get this. On Debian "apt-get install ftpd" installs proftpd with anon access disabled. My one gripe with the Debian install is that it doesn't chroot user directories by default causing confusion for my users. "DefaultRoot ~" in the config fixes that nicely though.

Re:Amusingly..

[ThePhilips]

It could be they heard my cries... On Debian 4, anon access enabled/user login disabled was default for both proftpd and vsftpd.

Re:Amusingly..

[Hatta]

On security note, default configs of ftpds found in Fedora, SUSE and Debian are [censored] insecure: they allow anonymous to access anything on hard drive while rejecting (even over SSL) valid users.

Really? Anonymous FTP users could access files with mode 000?

Re:Amusingly..

[statusbar]

I have a 'friend'... yeah, that's it... Who back in 1997 or so had a co-located server running RedHat linux with a vulnerable dns server. It was attacked. Multiple times. I only noticed - I mean my 'friend' only noticed when a further attack caused /etc/passwd to be broken. When the box was taken down and analyzed, it was noted that the system put the ethernet port in promiscuous mode and was sniffing all of the traffic for the co-located boxes that were connected to the same switch. A file on the disk contained all the user names and protocols and passwords of the people with accounts on those co-located systems.

So when you log in with unencrypted FTP, how do you know that the server that you are connecting to is not sitting in a rack next to a compromised system sniffing the traffic? How often do people misconfigure their servers and switches like this, and how would you know?

--jeffk++

Re:Amusingly..

[raju1kabir]

Unfortunately, raw FTP still rules when you need a high bandwidth. With SCP/SFTP I get consistently 4-5 times lower transfer speeds compared to FTP.

Switch to the blowfish cipher, it will speed things up substantially. This is an option in most gui clients; in openssh you can use the -c switch.

Re:Amusingly..

[JBdH]

I'm pretty sure that Woody (3.0) already had anon access disabled by default. Last Debian version I had that had anon access enabled by default was potato (2.2), which also had an open relay mail server by default. Those were the days...

Re:Amusingly..

[sloth jr]

Unfortunately, raw FTP still rules when you need a high bandwidth. With SCP/SFTP I get consistently 4-5 times lower transfer speeds compared to FTP. It doesn't matter much if one transfers megabytes. But SCP/SFTP becomes a pain when one needs to upload dozens/hundreds megabyte. 'tar cf - . | ssh tar xf -' trick speed things up, but not always available.

One thing you can try is to change your default cipher - try as an option to scp or ssh "-c blowfish" It helps. Honestly, I prefer using WebDAV over HTTPS, even though the performance is worse than scp/sftp, because you (potentially) don't need to have an actual user account on the destination to achieve authentication.

Re:Amusingly..

[profplump]

FTP opens an entire new TCP connect for each file transfered, and is plenty chatty in the command channel while that happens. It's probably not the handshake times that are slowing you down.

More likely it's the relative inefficiency of SFTP on high-latency links -- SFTP has a relatively small transfer and pending request window, which means that with any significant latency you'll spend a lot of time waiting for confirmations instead of actually sending data.

For example, in OpenSSH prior to 4.7 the default limit for outstanding requests was only 16. Since 4.7 the default has been 64, and in both versions you can adjust the limit at runtime with `-R num_requests`. OpenSSH 4.7 also increased the default receive window size, which improves transfer speeds on links with non-trivial latency.

Re:Amusingly..

[vrmlguy]

Actually, what I saw in the summary, for that which I read before I gave up, was that he suspected malware had intercepted his password. It's kinda silly having a packet sniffer listening to all passing traffic, when all they really needed to do was look in common places for stored passwords, and have a keystroke logger intercept interesting things. The later two I've seen quite a bit. The first, not so often.

If you read far enough, your scenario is discussed. Haselton estimates the likelyhood of various attacks a bit differently than you do.

But according to what Sinegubko told me, this reasoning was probably wrong. The problem is that even though spyware installed on your machine could read passwords that are stored in configuration files, it would be a lot of work to write a spyware program that could do this, because every FTP program and SFTP program stores passwords according to a different algorithm. It's much simpler for spyware to simply watch the traffic sent and received from your machine, so that any unencrypted passwords will be spotted:

Re:Amusingly..

[Nefarious Wheel]

One of the things they talked about was ftp and how it's used to upload content to your "web host"

You mean like the FileZilla utility that comes with XAMPP?

Re:Amusingly..

[Sancho]

sniffing all of the traffic for the co-located boxes that were connected to the same switch.

Was it also doing arp poisoning? Because otherwise, something in this story doesn't add up.

Re:Amusingly..

[Sancho]

It's kinda silly having a packet sniffer listening to all passing traffic, when all they really needed to do was look in common places for stored passwords, and have a keystroke logger intercept interesting things.

That was my initial reaction. Then I started really thinking about it.

It's probably harder to determine when those "interesting things" are, and even harder to programatically extract the really useful information from the keystroke logger. However protocol analyzer code already exists, and can detect usernames and passwords without human intervention. This means that the entire attack can be automated, from credential stealing to defacement.

That's not to say that keystroke loggers are going to go away any time soon, but I suspect that for now, they still require human intervention to detect the really useful bits (or at least to do so with a high degree of accuracy.)

Re:Amusingly..

[statusbar]

Yes, I think it was doing arp poisoning.

The thing is that there was a 75 megabyte file on the computer which contained the IP addresses, hostnames, user names, and email passwords and ftp passwords of users and computers in the same room. I watched the file grow in size as it collected passwords!

This is another reason why self-signed ssl certificates can be more secure than having no certificate at all, despite the warnings firefox gives you.

--jeffk++

Re:Amusingly..

[DavidTC]

And, again, I must ask, in what universe is it easier for a program to watch keystrokes to parse out a username and password, and then figure out the IP of the server, vs. just watching outgoing connections to port 21 and watching a standard FTP conversation where they know exactly where the username and password are, and what IP is connected to?

I'm really baffled as to how some people seem unable to realize that password capturing is very hard to automate for applications. You have to know the FTP client name, and watch for password prompt windows, and then try to read the IP somewhere (Which most infected people already have typed in and hence never will type again)...whereas password capturing is very easy for a known protocol on a known port. It is much easier than a program trying to figure out which keystrokes are the username and password.

This is why almost all keystroke sniffing applications do screen shots and record mouse clicks, too. So that another person can interpret them. The only thing that fully-automated keystroke logging is even slightly useful is grabbing credit card numbers, which follow a known pattern, which trips and records all information near that...and it still takes someone figuring out the month and year and stuff.

Reading the file the password is stored in, OTOH, is certainly possible, and slightly easier than keystroke logging...but considering the range of applications used for FTP, and the fact some people don't store passwords, it's only going to give you a fraction of the passwords that watching network traffic would.

Whereas you could write something to parse a tcpdump log of outgoing port 21 connections that got you the FTP username, password, and IP using a damn shell script and grep. Which is probably not how they do it, but the point is, it's easy.

Re:Amusingly..

[godrik]

You missed the point I believe. It is not enough that YOUR machine is clean. You need all the machines in the network to be clean. Otherwise, they are going to scan the network and you are fucked. (and switch is not the answer)

You need the transaction to be encrypted.

Re:Amusingly..

[drsmithy]

I used to work at a place where we used SCP to throw files around on the local 10/100 network. Those transfers always maxed out the network speed (11MBps or so). FTP didn't go any faster... I'm guessing your problem was elsewhere :P

It's not just about bandwidth, it's about latency. OpenSSH doesn't perform well when the latency is high. This is a known problem.

For example, between two of our offices (all have 100Mbit ISP links) with a ~300ms ping time an SCP struggles to break 170K/sec. Between two offices with only ~100ms the speed is around 350K/sec. To my home machine at only ~30ms it fully saturates my 10Mbit ADSL.

For high latency links with you need to look at alternative tools like dmscp2 to fully utilise the available bandwidth.

Re:Amusingly..

[drsmithy]

SCP is 4-5 times slower than FTP? What kind of CPU do you have?

It's not the CPU, it's the latency.

Re:Amusingly..

[Bashae]

I was writing from the standpoint of the small website owner, who is not on a local area network. The parent said he doesn't even manage his own server, so I am assuming he's an individual with a direct internet connection and a shared webspace account (and not a corporate user).

WebDav

[lymond01]

How to secure WebDav
http://www.howtoforge.com/webdav_with_ssl_and_two_factor_authentication

Re:WebDav

[Hurricane78]

Frankly, in my opinion, WebDAV is a slow and unreliable p.o.s.

I prefer properly configured/secured sshfs/sftp over webdav in all cases.

And with FUSE it is really comfortable. I run the following on login:

sshfs -o follow_symlinks,nonempty,idmap=user,allow_root $USER@$SERVER:. /home/$USER/server.$SERVER

Which gives me complete transparency. :)

(For Windows I recommend WebDrive, which can do the same.)

Re:WebDav

[stefanlasiewski]

I'm webdav (or Subversion, which uses WebDAV) as a possible tool for simple editing and publishing data to a website on the local network, using FreeBSD, Apache 2.x.

Why do you think that WebDAV has been slow and unreliable? Is it due to your implementation? Do you know if the problems were client-side, server-side or both?

HTTP is a pretty robust protocol, Apache is a pretty robust server. It seems like WebDAV would be a simple and robust, but I am reading about other stability problems as well. In addition, few people use WebDAV. I can't find many details or good articles which suggest why.

Re:WebDav

[stefanlasiewski]

I'm webdav

I'm _evaluating_ webdav.

they won't guess mine

[Anonymous Coward]

Nobody will ever guess my FTP credentials.

login: guest
password: anonymous@host.com

Re:they won't guess mine

[SEWilco]

You're right, they will never guess them.
They will look them up.

It doesn't matter

[RenHoek]

Look, if your machine is infected by malware, it's not going to make any difference if you use FTP or SFTP or god know what else.

Either your passwords are stored on your harddisk or you're going to have to type them in at a later point. In both cases software is going to be able to get your passwords. And they have that they can get in without a problem, regardless of protocol used.

So instead of this looooong article, some more vigilance online to avoid the infection to begin with would be more helpful.

And if you _have_ to use MSIE, use SandboxIE.

Re:It doesn't matter

[Chris Mattern]

You're missing the point. If you're using FTP a hacker has no need to infect your machine. All he has to do is intercept your packets that you sent out to the public internet, and he has your password to the FTP account.

Re:It doesn't matter

[Goaway]

You know, the article addressed that, but let's have it one more time:

Sure, a determined attacker with malware on your machine can get your password for anything. But these aren't determined attackers. They are people throwing their nets very, very wide, and they rely on automation to find their passwords. Getting every keystroke isn't going to tell them what your password is without manual analysis, and nobody has the time for that. And making your keylogger smart enough to figure it out by itself requires adapting it for every possible file transfer client out there.

So it is much easier to just listen for FTP connections. That's the low-hanging fruit. The software COULD do other things, but it generally DOESN'T. At least not yet.

Re:It doesn't matter

[hrimhari]

And it looks like the article also missed your point, since it says how intercepting packets in public internet is not the problem, but infecting your machine to sniff them from the source.

Re:It doesn't matter

[DNS-and-BIND]

How often does that actually happen, in this day and age? Compared to the accounts that are comprimised by other means? I mean, every time there's a security conference someone makes a point of capturing FTP and POP3 passwords sent in the clear, but how often does this happen in the wild? Even if you were able to comprimise some big-time router on the internet somewhere, it seems like you'd have larger fish to fry than intercepting the FTP passwords for Flo's Florist (100 unique visitors per day!)

Re:It doesn't matter

[a-zarkon!]

Funny, I've heard the same arguments against implementing encrypted protocols and banning plain text protocols too many times to count:
      1) That's not possible on a LAN because we have ______ select from (switches/firewalls/antivirus/leprechauns)
      2) That's not possible because someone would have to hack into the Internet to see that traffic
      3) That's not possible because anyone who could do something that tricky would not waste their time on us
      4) It doesn't matter because we don't have any _____ select from (credit cards/SSNs/personal info/nuclear launch codes)

In my experience and at the risk being modded a troll (believe me, that is not my intent) these assertions are typically made by system admins who resent being asked to change the way they do anything and generally won't take a step in the right direction until they've already been burned. Let me state that these arguments are all wrong. However, let's conveniently side-step the proving of why these assertions are wrong for now. Instead let's examine the alternatives:

-Replace Telnet/RSH with SSH
-Replace FTP with SFTP or SCP
-Replace HTTP with HTTPS (at least for sensitive data and/or authentication)

In all cases, implementing a secure access method is relatively trivial. Even if you don't believe in Santa Claus - is it going to really cause you that much hassle to leave a couple of cookies and a glass of milk out on Christmas Eve just in case?

Re:It doesn't matter

[ppanon]

Unless you use Flo's Florist's website and many others as a conduit for deploying malware and trojans to build a botnet. If that web site nets you 1000 users over a few months, get a few dozen of those and you start having a botnet with which you can do some serious damage (and/or illegal business).

Re:It doesn't matter

[The Cisco Kid]

The simplest way for a *CR*acker to "intercept packets" that you send to the Internet is by infecting your machine. In general, ISP networks, and even the average home router/firewall are *far* more secure than your windoze machine . And once they've done that, why would they bother sniffing packets when its far more trivial to just poke through stored password files and/or run a keylogger?

Re:It doesn't matter

[tehdaemon]

As if the other replier weren't enough... In order to read your IP packets some machine in the network between you and the FTP server needs to be compromised. And the easiest by far is your own machine. The whole point of this story is that malware does just that - it sniffs the packets as they leave your own machine to get those passwords. That is easier than installing a keylogger.

T

Re:It doesn't matter

[bugg]

One needn't compromise a router in order to gain access to it. They can be given access, after all.

There are thousands of network engineers and similar who work for ISPs, who routinely capture traffic as part of their jobs. It takes only one of them to disregard the rules/the law/their job and run a longer trace, or to run a trace to capture one specific thing and inadvertently capture passwords. Or worse yet, it takes only one of them to have their credentials or machines personally compromised.

It might be a bit farfetched, but once you start working in this business and you see how many engineers have pretty advanced credentials, you realize that any one of them could become a determined attacker and do quite a bit of damage -- or, a sufficiently determined attacker could get a job as a network engineer.

Re:It doesn't matter

[Bert64]

A lot of web hosting is done on colocated boxes, sitting on a lan with a lot of other colocated boxes... If one of them gets compromised, running a sniffer to capture insecure logins to the others is not too hard.

Re:It doesn't matter

[Bengie]

because hacking a major internet router to mirror data to you is so much easier

Re:It doesn't matter

[mrcaseyj]

Hackers could adapt to the top few ftp client's storage formats and get 90% of passwords with little extra effort. On the other hand a key logger wouldn't capture your password often if it was stored on disk and therefore typed infrequently. The key logger could corrupt the password store and force the user to re-enter the password while logging the input at certain times or to certain dialog boxes. A man in the middle attack run from the infected computer could also extract the password from a secure ftp protocol. I could go on and on about easy ways to defeat ftps when an attacker has malware running on the target machine. Secure ftp protocols are for untrustworthy networks, not compromised hosts.

This is why I think everyone needs something like a smart card to store credentials. Modern operating systems are far to complex and vulnerable to be well secured, but a smart card can have a relatively small and simple operating system that can stand a decent chance of keeping your secret keys secret.

Re:It doesn't matter

[DavidTC]

Yes, but sniffing FTP packets from a local traffic intercept is much easier to automate than sniffing passwords while typed, or trying to decrypt them from the myriad programs out there.

All you have do is watch a known port for a known character pattern.

Keystroke loggers, OTOH, require human intervention, unless you're trying to grab easily recognizable strings like credit card numbers. Stealing credentials from programs likewise requires supporting a bunch of different programs and formats.

Re:It doesn't matter

[DavidTC]

'You' don't compromise the password.

A program compromises it. It then reports that IP, username, and password to some other tool.

That tool then logs in, searches for .html files. If it finds them it downloads, put in javascript links to the program mentioned above, and reuploads them.

It's not 'work' at all. It's fully automated.

Re:It doesn't matter

[DavidTC]

In your universe, it's really 'far more trivial' to support dozens of different FTP and SCP programs, and/or to keystoke log and magically decide when someone's typing their username and password (And then somehow figure out what site they connected to?)...

...than to watch all outgoing traffic to port 21, wait for the standard FTP username and password prompt, and log the replies and IP?

Seriously, at this point so many people are missing the point, that I'm bemoaning the collective lack of intelligence on this site. Sniffing an FTP connection is MUCH easier than decoding obfuscated passwords and monitoring thousands of keystrokes.

Re:It doesn't matter

[Urban Garlic]

Well, as discussed in the article, it's a question of level of effort.

A malware packet-sniffer can watch for outgoing FTP connections, and skim plain-text passwords out of them. This is very easy, and, according to the article, quite common.

A highly sophisticated malware disk-browser can locate and, if required, decrypt your stored password from your SFTP profile. Or, a keylogger could log all your keystrokes, and try to figure out when you're typing passwords, and store them. These attacks are harder, and according to the article, quite uncommon.

By using SFTP, you're protected against the common, easy attack, but you remain vulnerable to the uncommon, difficult attack. It's not perfect, but you actually are less vulnerable. Thinking otherwise is like insisting on using a bad analogy, because people always misunderstand analogies anyways, so using a good one won't help.

Re:It doesn't matter

[Goaway]

And how would that card talk to the remote site? Through the OS, which is compromised. So that gains you nothing, and just creates a big target.

Re:It doesn't matter

[tunapez]

And if you _have_ to use MSIE, use SandboxIE.

Cripes, whatever you surf with, use SandboxIE! Especially when surfing Pr0n!!!!

Best program since sliced.bread.2.0, IMO.

Re:It doesn't matter

[vux984]

-Replace Telnet/RSH with SSH

Easy.

-Replace FTP with SFTP or SCP

Easy.

-Replace HTTP with HTTPS (at least for sensitive data and/or authentication)

Not easy.

https is just not that easy to swap in. Its harder to work with because you can't have multiple https sites listening on the same port on the same ip address, which is a common-as-dirt situation.

And then the certificates themselves are a hassle, and have a cost on top of that, and if you don't get it from the right place half your users will have a giant warning screen when they try to access it.

Re:It doesn't matter

[mrcaseyj]

And how would that card talk to the remote site? Through the OS, which is compromised. So that gains you nothing, and just creates a big target.

With public key cryptography you can authenticate yourself without revealing your private key to the other party or even to your own computer. The key can stay safely on your smart card. That doesn't solve all problems, but it has big advantages. For example, when you remove the card or shut down your computer, the hacker can no longer impersonate you or login to your servers, at least not until you power back up again. Also, with a button or keypad on the card, the number of authorizations can be limited to the ones you actively authorize by pushing the button or entering your pin code. If the smart card or similar device has a display, it can show you what you are authorizing, such as a bank transfer, including how much it's for and where it's going.

Re:It doesn't matter

[DNS-and-BIND]

I repeat: how often does this happen in the wild, compared to other means of exploitation?

Re:It doesn't matter

[Goaway]

Yes, but all the malware has to do is wait for you to log in, and then you notice your login failed because it was actually the attacker who logged in.

Re:It doesn't matter

[wurp]

Either your passwords are stored on your harddisk or you're going to have to type them in at a later point. In both cases software is going to be able to get your passwords. And they have that they can get in without a problem, regardless of protocol used.

Unless and until someone develops all these systems (starting with file transfer) to operate on challenge & response using pub/priv key systems. Hmm, in fact I suspect ssh does work that way when you use keys. I need to look into that...

Anyway, if you use such a system, then you can have a token (physical key) which contains your private key in an inaccessible way, but can provide the public key on demand or can be asked to sign a piece of text using your private key. Then the authenticating system sends you random text, your token signs it & sends it back, and the authenticating system validates the signature using your public key.

Then, regardless of the security of the system you're using, your identity is secure. Someone may steal your session and do Bad Things, but they can't ever login again as you once you're logged out on that session. For very dangerous operations, the authenticating system just requests you to authorize the operation explicitly, so even session hijacking won't let an attacker screw you. If necessary your token can provide a way to display a simple message about what operation you're authenticating by pressing OK.

Ideally, the physical key has a way for you to enter a password directly into it. Then someone would have to not only steal your key, but also learn your password to be able to hijack your identity.

If you need to invalidate an old token and migrate to a new one, you can allow a request signed by some authority to invalidate the old key and inject a new one. If you don't like central authorities, web of trust can be used in the same way.

FTPS

[xororand]

It's unfortunate that FTPS still seems to be widely unknown. FTPS is an extension of the FTP protocol which secures the control & data channels with TLS. It's standardized in RFC 4217.

Restricting users to their home directory is much easier with FTPS than with SSH. The latter requires you to setup a chroot jail for each user. At least OpenSSH has built-in chroot support that allows you to specify a chroot environment for each user via /etc/passwd.

Many FTP clients and servers support the FTPS protocol, for example:
* FileZilla
* curl (and curlftpfs)
* lftp

Servers:
* vsftpd (can enforce encrypted FTP)

Re:FTPS

[hardburn]

Does it fix FTP's multiple port usage? This design is a constant source of problems on firewalls, particularly stateful firewalls. Many types of firewalls from various vendors and operating systems have been penetrated over the years due to handling the complexities of FTP's port usage. There are fixes out there, of course, but the problem would go away if we standardized on OpenSSH SFTP.

Re:FTPS

[Hurricane78]

I actually only let people on my server, that I trust to have shell access, and to be able to properly use it in the first place. This gives them many advantages too.

Ok, I run SELinux on the box anyway. ^^

Re:FTPS

[BitZtream]

So many reasons why this post is silly:

chroot is not a jail, its a hack to make shitty software work in a specially constructed enviroment. It does not in any way prevent a malicious program from breaking out of the chroot, it just makes a poorly written one have the option of working in a special section of the filesystem where you can put specific versions of files without effecting the entire system.

FTP without a chroot is not really any different than ssh without a chroot. If you're just depending on the authors of your ftp daemon to protect you then your an idiot.

Let me say this one more time since no one ever gets it an every year we see a new slashdot article about it.

CHROOT IS NOT A FUCKING SECURITY FENCE, NOT INTENDED TO BE, DOESN'T ACT LIKE ONE, WILL NEVER BE ONE.

Re:FTPS

[Anonymous Coward]

Try using FTPS through a reverse proxy or behind a VIP? The header information that contains the server IP for the data channel gets encrypted, so unless the FTPS server has a method to inject the proxied or VIP address, you may get a failed connection since the client will try to connect directly to the host instead of the proxy or VIP.

Re:FTPS

[Anonymous Coward]

Not only it doesn't fix the problem it makes it worse. FTPS doesn't work for a client that is behind NAT, because the control connection is encrypted and therefore the NAT box cannot get the information needed to open the data connection.

Re:FTPS

[gpuk]

I have to disagree. I have no problem connecting from behind NAT to a my FTP daemon on the public internet. I run vsftpd with forced TLS encryption for both control and data channels.

Re:FTPS

[bitslinger_42]

I run the secured FTP server for my company, and I'm finding that FTPS survives through one layer of protection (i.e. a NAT on one end), but it dies if there are more (i.e. NAT on one end, firewall on the other). It isn't 100%, we do have some users that are just fine on FTPS, but the vast majority of my users are coming in through SSH-based SFTP.

Re:FTPS

[hrimhari]

So much misdirected anger... it has nothing to do with the parent.

Re:FTPS

[Anonymous Coward]

Hooray for you! How does this help in a GoDaddy-style shared hosting environment (which is an overwhelmingly more common use-case)?

Re:FTPS

[Hatta]

How does one break out of chroot?

Third, if there is no root user defined within the chroot environment, no SUID binaries, no devices, and the daemon itself dropped root privileges right after calling chroot() call (like in the code below), breaking out of chroot appears to be impossible. In other words, if there is no way to gain root shell or perform actions that only root can usually perform (e.g. create devices, or access raw memory) breaking chroot is not clearly possible. Ideally, if the custom software uses chroot for security the sequence of calls should be:

chdir("/home/safedir");
chroot("/home/safedir");
setuid(500);

Keep in mind, that after these lines are executed there will be no way for the program to regain root privileges.

Chroot can clearly add to security if used correctly.

Re:FTPS

[xororand]

That's only a problem if the FTPS server doesn't use the PASV data mode.

Re:FTPS

[SanityInAnarchy]

First: It's not just "shitty software". It can be very useful for things like installation. I always like the Gentoo Linux approach -- format the disk yourself, mount it, untar one tarball, and chroot for the rest of the installation.

Second, every single security "problem" with chroot is based on the root user breaking out. Non-root users cannot break out of a chroot'ed environment. It therefore does add some additional security.

And finally:

If you're just depending on the authors of your ftp daemon to protect you then your an idiot.

If you don't see the difference between explicitly allowing any user to run any command on your system via ssh, and the possibility that a bug in your FTP software might lead to the same problem, you're an idiot.

Re:FTPS

[SanityInAnarchy]

Until FTP can let me use a keypair instead of a password, I'll stick with OpenSSH public key authentication.

Never mind that ssh only requires a single port to be open...

Of course, it depends on your goals, but there's also the fact that I wouldn't pay for a server that I didn't already have some sort of shell access to. Since I already have ssh access (I'm assuming we're not even considering telnet), I already have scp and probably sftp.

Re:FTPS

[fnj]

Horse shit. chroot is a tool. Used properly, where applicable, it can greatly enhance security. Used improperly, it does little or no good. It doesn't matter what it was invented for; it doesn't matter how many times people make blanket statements about it; the fact is that it can be used as a useful security tool.

Some of the other commenters point you to sources detailing chroot's weaknesses and pitfalls, and how to avoid them.

There is no perfect, cure-all security measure. That doesn't mean you don't use available tools to enhance security as much as possible. The world is not black and white. It is shades of grey.

I'm not quite sure where you're aiming with the statement "FTP without a chroot is not really any different than ssh without a chroot.", but it strikes me as utter nonsense.

Pardon my French, but your sweeping statements are just out of control, beginning with where you call your parent's post silly.

Re:FTPS

[palegray.net]

Spoken like someone who hasn't been able to figure out how to use chroot properly for several years.

Re:FTPS

[ppanon]

I am under the impression that OpenBSD's chroot jails are reasonably secure when used in conjunction with OpenBSD's privilege separation and privilege revocation.

Re:FTPS

[jimicus]

Hosting companies can install something like rssh

Re:FTPS

[neoform]

SFTP isn't useful if you want to jail users to a certain directory. Setting up SFTP to work that way is a huge pain in the ass. Most FTP(S) servers were designed with this in mind.

Re:FTPS

[mzs]

Okay the guy you replied did not write in a pleasant way but he has a point. chroot is not jail, chroot is easy to break out of on many systems. The reason is because once you are chrooted you can call chroot yourself. The canonical approach to break out of a chroot jail that has been known about now for 10 years or so works like so:

mkdir "foo"
fd = open "."
chroot "foo"
fchdir fd
for (i = 0; i < 0x100; i++) chdir ".."
exec "/bin/sh"

Most chroots don't change the the cwd so the fchdir is often not needed also the dirent approach works as well in other cases.

So now you are running as nobody or yourself and you can use the local privilege escalation of the day to get root access, but just breaking out of the chrooted environment may have been the goal, you know like you were not supposed to be able to run a shell at all. Or you may now run some denial of service (local or remote).

So some systems prevent this. One notable is BSD where chroot fails if you have fds open. There also are other approaches for breaking out of a chrooted environment, as well as countermeasures.

One point is how would you run this stuff at all. Well one argument is that this might be a webserver where you have CGI and therefore an interpreter like perl, and doesn't that example I wrote there look a whole lot like perl. The other argument is that this was first seen in the wild against wu-ftpd back in 1999, and it used a buffer overflow to inject that same code to break out of the chroot jail and execute the shell in place.

So the argument I am trying to make in a much more civil manner is that if you need something like jail, use something like jail and not the poor substitute of chroot instead.

Re:FTPS

[phantomcircuit]

I have moderator points, but I decided to reply instead.

There are several ways to break out of a chroot'ed environment.

You do not need root privileges to break out of a chroot. If you can find a file descriptor which was opened before the call to chroot() you can break out of the chroot. That is only one example, but it gives a good idea of how complex compartmentalization of an entire operating system is. It is important to realize that chroot is not a security mechanism.

Re:FTPS

[medlefsen]

Actually it's only a problem if you are using PASV data mode. FTP's multi connection system makes it very difficult to do proper session management and firewalling. You should never use normal ftp (if you even can without running as root) and with PASV mode the data channel uses a random port so you can't lock down your outbound connections in your firewall.

The best you can do is have your firewall be smart enough to detect ftp traffic and add special logic for parsing out the data port and allowing the subsequent connection. This brings us back to FTPS, which encrypts the control channel thereby preventing any of what I just said.

In this day and age we simply should not be using any protocols that require incoming connections to non-known ports. Just look the BIND cache poisoning debacle.

Re:FTPS

[Hatta]

The reason is because once you are chrooted you can call chroot yourself.

You need root privileges to execute chroot. Take care not to provide any root privileges inside the chroot and you're safe.

Re:FTPS

[Hatta]

If you can find a file descriptor which was opened before the call to chroot() you can break out of the chroot.

How can you do this without root? Please give examples.

Re:FTPS

[Anonymous Coward]

But the FTP server needs to recover root access, even for later use in the current session (bind() to port 20 locally).

Re:FTPS

[treat]

Sometimes it might work. It can't work when there are two reasonably strict NAT gateways / firewalls - one on each end.

FTPS does make the problem FAR worse. That's a fact. Firewalls look at the data of the FTP control connection to know what to allow or what translation to do. FTPS deprives them of this and provides no other mechanism to help the situation.

Re:FTPS

[treat]

That's only a problem if the FTPS server doesn't use the PASV data mode.

PASV mode requires a new connection to be allowed. It's still a problem if the FTP server sits behind a firewall that isn't allowing connections over the Internet to a huge block of ports.

You can get by if you limit the port range to 100 or so and allow those. But any alternative now looks much better, if you're required to poke huge holes in the firewall just due to a historically silly protocol that was extended in an unuseful way.

Re:FTPS

[treat]

SFTP isn't useful if you want to jail users to a certain directory. Setting up SFTP to work that way is a huge pain in the ass. Most FTP(S) servers were designed with this in mind.

Exactly.

Whether you choose SFTP or FTPS, you get bitten by one problem or the other.

Re:FTPS

[Anonymous Coward]

this guy always in a foul mood and loves to be negative, mean, and use vulgar language. maybe he think it gives him or his opinions or posts more validity, when what it actually does is the exact opposite.

Re:FTPS

[treat]

So many reasons why this post is silly:

chroot is not a jail, its a hack to make shitty software work in a specially constructed enviroment. It does not in any way prevent a malicious program from breaking out of the chroot, it just makes a poorly written one have the option of working in a special section of the filesystem where you can put specific versions of files without effecting the entire system.

FTP without a chroot is not really any different than ssh without a chroot. If you're just depending on the authors of your ftp daemon to protect you then your an idiot.

Let me say this one more time since no one ever gets it an every year we see a new slashdot article about it.

CHROOT IS NOT A FUCKING SECURITY FENCE, NOT INTENDED TO BE, DOESN'T ACT LIKE ONE, WILL NEVER BE ONE.

Wait, so depending on the daemon to protect you is idiocy. But also chroot is not useful for security.

So you'd like another, unstated solution? Love to hear it.

Re:FTPS

[FutureDomain]

Mod parent: +1 Sane

Re:FTPS

[bigbird]

FTPS is basically the standard FTP protocol over SSL. So the same problem of a new connection being used for directory listings and file transfers still exists.

As another poster notes, the problem can be exacerbated using FTPS - firewalls can read the control channel of ordinary FTP and when PORT or PASV commands are encountered, they can automatically open the port number that is referred to. Because the command channel is encrypted in FTPS, firewalls can't do this, and FTPS transfers (and listings) are much more likely to fail than FTP transfers.

One solution is to switch back to an unencrypted control channel after authentication, although this of course complicates things for clients.

Using SFTP is the best solution - only a single port is used for both commands and for data transfers. So as long as port 22 is open, SFTP will always work.

The (slight) downside of SFTP is that it is a more complicated protocol and more difficult to implement.

Re:FTPS

[mzs]

chroot failing with EPERM when euid is not 0 is not universal. In fact it is relatively recent. I think it appeared circa FreeBSD 4.8 (or was that 4.4) in fact as a result of another exploit to escape chroot. I would not count on chroot only working for root, I've used systems where it was not the default and others that were poorly configured so that it was allowed (see man 5 privileges on solaris for example). There are a whole list of ways to break out of a chroot jail, and work a rounds have been adopted over the years. Another popular one was using mknod and using the superblock in there, but that has required root for as long as I know of.

Then there is the problem that a lot of programs that are run in a chroot jail do not call setuid (and only sometimes seteuid) since they do in fact need some root permission. For example an ftp server might need it for ports below 1024. In fact Samba was vulnerable to such a chroot escape in the past a couple of times.

Again, that's another reason to use something jail like instead of chroot like, the intent is that even root cannot escape a jail.

Then there is the whole can of worms that chroot really only tried to capture you to a portion of the filesystem. There were attacks where yo could send signals to other processes and just look at processes of other users for example. It all leads to the desire of having something jail like like jail or zones.

Re:FTPS

[raju1kabir]

You do not need root privileges to break out of a chroot. If you can find a file descriptor which was opened before the call to chroot() you can break out of the chroot. That is only one example

It's more of a notion than an example. Given an open file descriptor and no root privileges, how exactly would you break out of a chroot on a reasonably common and up-to-date system?

Re:FTPS

[phantomcircuit]

chroot only applies to file descriptors open after the call. If there is a file descriptor opened before the call to chroot on say a directory? you can easily transverse the file system.

Re:FTPS

[phantomcircuit]

im not repeating myself. http://slashdot.org/comments.pl?sid=1300757&cid=28683733

Re:FTPS

[raju1kabir]

Here's something that actually answers my question rather than just repeating its antecedent, in case anyone else has it:

http://www.linux.edu/index.php?option=com_content&task=view&id=45&Itemid=9

Re:FTPS

[Anonymous Coward]

We use Secure FTP Wrapper which is a secure FTP proxy (FTPS) that sits on our existing FTP server. Super easy to install/configure.

These aren't average users, are they?

[Sockatume]

(What percent of users ever change the default set of toolbars that are displayed at the top of their Web browser window?)

I'm guessing that when it comes to users who administer their own websites, and do it through FTP rather than the Geocities page builder, it's actually pretty high. This is a group of people that could probably navigate a simple menu to the SSH toggle intuitively. Now, the whole phone-number-PIN rigmarole is an un-necessary headache, but generally this isn't an end-user usability issue, it's an end-user risk assessment issue. They assume that because SFTP is an obscure, buried option, then it's not necessary for their everyday work, and ordinary FTP is sufficient. This leads to the same set of solutions - make SFTP default and bury the ability to disable it, or make it hard for the user not to notice that they can secure the connection - but for different reasons.

Re:These aren't average users, are they?

[hrimhari]

It's not my case. My cheap web host simply charges for SSH setup which seems to affect SFTP, since it requires SSH to be set up.

Re:These aren't average users, are they?

[hedwards]

The college that my mother works at uses sftp to do all the off campus file transfers. Specifically they use FileZilla with a walkthrough as to how to get it done. From what I gather they're not having a whole lot of trouble with it. Then again, they do have a couple of computer labs where they can walk people through the process from time to time if they need to. And I can assure anybody reading this comment that a fair number of them are barely computer literate, and even then just if I'm being generous.

But ultimately the bottom line is that while there are solutions to the issue of security, FTP is a protocol that probably ought to be replaced with something new, something that better tolerates the new realities of networking. IPv6 is a good excuse to scrap it for something that's redesigned to better handle that sort of thing.

that's why

[Anonymous Coward]

And that's why I bought a Saturn.

Users can't tell the difference

[Anonymous Coward]

Our end users keep asking and referring to FTP, when all they need is a way to transfer files temporarily (especially when the email server doesn't like 2 gig attachments). So we setup a web interface to post files, download them, and autodelete. They have been happy with it since then. What do they call it? The FTP server.

The FTP term has lost its meaning to represent a protocol (which is what the IT staff thinks of it as) vs the end users with think of FTP as a generic term to transfer files.

Re:Users can't tell the difference

[4D6963]

I hate to point out the obvious, but it might have to do with the fact that FTP stands for File Transfer Protocol ;-).

Re:Users can't tell the difference

[Hatta]

If you don't know that FTP refers to a specific protocol, you don't know enough to be running a web site.

Re:Users can't tell the difference

[clone53421]

The people running the web site do know. The users don't know, nor do they care.

Re:Users can't tell the difference

[vslashg]

If you don't know that FTP refers to a specific protocol, you don't know enough to be running a web site.

This is akin to saying if you don't know what a carburetor does, you don't know enough to be driving a car. Now, some people believe this, too, but this statement, and yours, are wrong.

Hey, look, I made a Slashdot car analogy!

Re:Users can't tell the difference

[Hatta]

No, that's akin to saying that if you don't know what a carburetor does, you don't know enough to be fixing cars.

Re:Users can't tell the difference

[CastrTroy]

Since most modern cars don't have carburetors, and instead have fuel injectors, I don't think most people should care about what it does.

Re:Users can't tell the difference

[Cyner]

You've got some tech savy users there. Mine all use the "download site". They download files from it and download files to the site.

Re:Users can't tell the difference

[fast turtle]

The FTP term has lost its meaning to represent a protocol (which is what the IT staff thinks of it as) vs the end users with think of FTP as a generic term to transfer files.

And the role of IT is to support those end users called "Joe Sixpack" in the completion of their duties. In this case those users are absolutely correct based upon the definition of FTP which is

File Transfer Protocol

Simply put, those users are using the terminology in the correct manner based upon the language instead of using it according to the damn RFC. In fact based upon the definition of FTP, it could easily include Sneaker Net, Direct Connection, Bit Torrent, Rapid Share, WhaleMail and a whole rash of other setups that do the same thing as you're local server does.

Re:Users can't tell the difference

[socsoc]

So you built a web interface to an FTP server?

Re:Users can't tell the difference

[Anonymous Coward]

Lots of people do this nowadays and it drives me insane.. I hate those stupid web file upload scripts. They're slow, require me to have a browser available on the machine I"m on, and they can't resume. also, there's all the extra clicking and gui manipulation I have to do to use them. they're not more convenient, they're LESS convenient.

Authentication goes both ways.

[skeeto]

With SSH you also know you are talking to the right server, not a man-in-the-middle or a DNS hijack.

Re:Authentication goes both ways.

[minsk]

Most SSH clients will verify that you are connecting to the _same_ server as last time. However they can not verify the actual identity of that server.

(Well, server with the same key as last time you connected to that domain name or IP, but close enough)

Re:Authentication goes both ways.

[hackel]

Then you don't know how to use SSH properly. You need to obtain the public key beforehand, and then *verify* it the first time you connect to a host (you know, when it prints the fingerprint and asks you, "Are you sure you want to continue connecting?") Even Putty in the Windows world does this. It's extremely important.

Re:Authentication goes both ways.

[SanityInAnarchy]

I like that this is an option.

Of course, I'll be honest -- I still often say "screw it" and just connect, rather than trying to transfer the key ahead of time, verify the fingerprint, etc. But then, I only connect from my laptop, and I intuitively know which machines I've already connected to, and which will give me the security prompt. So, generally, once I've connected once without a MITM, every connection from then on is secure.

Re:Authentication goes both ways.

[minsk]

Yes, yes, we all see your geek card. Now stop waving it around.

Manually verifying fingerprints is the kind of voodoo which utterly and completely fails to protect normal users. In fact, I was probably being too optimistic to imply that key conflict warnings would deter unsafe behavior.

Apply a trivial malware DNS hijack. Against a full-blown PKI. And we're still screwed, because most users don't understand the threat, and click through warning after warning.

Re:Authentication goes both ways.

[hackel]

Well I have to agree with you there. If I were in charge of a server where I knew I had less-knowledgeable users connecting to it, it would make sense to require them to use a particular client which requires them to *type in* the fingerprint I have given to them before it even allows them access. Of course this isn't very secure since they could still use any other client, but assuming most of these users wouldn't know how to do that, it's a step in the right direction.

And it's sad that something as crucial as this should require a "geek card" to talk about!

Perhaps another answer is to start using certificate authorities for SSH they way they do for websites and email...

Re:Authentication goes both ways.

[Burz]

Checking fingerprints is simple and the "normal users" you are referring to happen to be system admins.

Apply a trivial malware DNS hijack. Against a full-blown PKI. And we're still screwed, because most users don't understand the threat, and click through warning after warning.

This seems more aimed at https, but I'll bite: The users at least have the opportunity to learn about the warning, which is better than the alternative. But it seems to me that most of the ignoring is done by techies when they are asked what the warnings mean.

Re:Authentication goes both ways.

[tepples]

So, generally, once I've connected once without a MITM, every connection from then on is secure.

Mac OS X uses the same algorithm to verify digital signatures on student/hobbyist/microISV code: if the new version of an application was signed with the same certificate as the previous version, even a self-signed one, the OS keeps the parental controls and firewall settings that the user granted to the old version. But how can you be sure that your first connection was without a MITM?

Re:Authentication goes both ways.

[SanityInAnarchy]

But how can you be sure that your first connection was without a MITM?

Usually, because I'm actually physically right next to the machine. If I can't touch my switch, who can I trust?

In general, I'm working with probability. The fact that I've never had the "somebody nasty" message unexpectedly (that is, when I didn't just reformat or replace a machine), even when I move the same laptop from home, to work, to the airport, and back home, means it would take a truly massive network of people intercepting my packets at every turn, or I'd have at least detected it at some point.

Re:Authentication goes both ways.

[rainmayun]

Ever heard of TLS? This is the "S" part of FTPS. It does server and client authentication, with a built-in mechanism for establishing server identity and trust. In my opinion, managing TLS certificates with a CA is a much better approach than shipping SSH keys around.

here's a thought

[juanhf]

one of our clients web hosting company was the victim of a similar attack. we were able to trace the attack back to an extremely out of date version of PHP.

check the versions of the software your web hosting company is running.

Re:here's a thought

[clone53421]

An out-of-date version of PHP — or badly-written, insecure PHP scripts that failed to properly check their input? E.g. register-globals isn't in itself a security hole, it just makes it really easy to create insecure code if you don't know what you're doing.

Re:here's a thought

[jimicus]

PHP, IMO, is an absolute nightmare for a hosting company. Particularly if you have a lot of customers who have been with you for years using the same shitty web apps as they did when they first signed up.

The main problem is that the developers of PHP only started paying any attention to security relatively late on in the development of the language. They've added all sorts of things to make PHP more secure, but quite often they have to be specifically enabled and will break some code.

OK if you've got a relatively well managed corporate site with a single team dealing with any PHP applications. What if you've got a few thousand customers, many of whom don't actually know the first thing about their site because they paid someone else to set it up three years ago?

OTOH, what sort of hosting company is going to turn around and say "Sorry, we don't offer PHP"?

Re:here's a thought

[Anonymous Coward]

Mine does. Every major release of PHP up to the one being used right now has had major zero-day code exploits in it.

For this reason, the customers don't get access to scripting unless it's in a specialized container, or more recently just thrown on a VM. (On the VM, they can do whatever they want without screwing up everybody else, and are mostly confined to self-inflicted damage.)

Some of them bitch and leave, but the ones that insist on using Joomla 0.85 to host their forums are a pain in the butt anyway. 80/20 rule and all that.

SFTP support is still spotty ....

[King_TJ]

Switching from FTP to SFTP on the server side is great, in theory, but it's really only a trivial task for people running Unix type operating systems.

SSH isn't an integral part of most Windows operating systems, and nearly all of the well-regarded, commercial FTP servers for Windows have no SFTP support in them.

(I understand the Serv-U FTPD for Windows does support it, but it's an exception to the rule.)

I recently ran into this at my workplace. We've run the commercial WFTPD product (from Texas Imperial software) for years, but I had to get rid of it when our bank started requiring SFTP connections to send us electronic scans of daily check deposits.

Re:SFTP support is still spotty ....

[Anonymous Coward]

SFTP isn't even a ratified standard; the IETF folks have wandered off into some esoteric debate about 'file systems' and dropped that ball. Mickysoft ignores all things SSH. SFTP windows clients suck; every single attempt I've made to get a windows user to operate their SFTP account it's been a support hassle; it never just works the first time, regardless of how much care I take to provide correct, concise account information. Whatever secure client replaces FTP will need to be integrated into base OS tools that boneheads know they are expected to cope with; no extra downloads, creepy third party plugins, half baked shareware UI design, etc. Since Mickysoft would rather piss away hundreds of millions inventing their own proprietary solutions you should not hold your breath.

Re:SFTP support is still spotty ....

[redhog]

http://winscp.net/ works like a charm! And as an extra bonus, it works with the pageant ssh-agent from the putty telnet/ssh suite...

Re:SFTP support is still spotty ....

[LordLimecat]

I take issue with the term "well-regarded, commercial". It seems to imply that they would be more reliable than opensource software, for some vague "its not enterprisey" reason, when the opensource programs are just plain better. Stupid attitudes like this lead to reliance on big name vendors with shitty products just because its a big name vendor...which seems backwards to me (i would hope theyd be big name vendors BECAUSE of their product!).

Re:SFTP support is still spotty ....

[ppanon]

And thanks to pageantsc you can even use it with smartcards for portable, write-only private keys.

Re:SFTP support is still spotty ....

[flajann]

Of course, I think anyone who uses Windows for web services get what they deserve. Windows might be good for some things; serving the Web is not one of them.

Re:SFTP support is still spotty ....

[Alun Jones]

Thanks for the plug for WFTPD (actually you have to get WFTPD Pro for FTPS support). You might ask your bank why FTPS isn't a supported mechanism, given that it's possible to provide equivalent security through FTPS that they might get through SFTP, and it's a documented protocol, as opposed to SFTP, which has several incompatible versions and no documentation that allows for development of an SFTP implementation without having to refer to other people's source code in order to do so. This is the basic reason why there are so few SFTP implementations from established FTP developers - we don't want to build our implementations from other people's source code, and thus be subject to their licences.

Re:SFTP support is still spotty ....

[Anonymous Coward]

Have you tried setting up apache or lighttpd on Windows let alone using them for production? Windows just doesn't hold a candle to Linux in the server market. Windows is not a server OS. Sure some PHB will want it used INTERNALLY for Active Directory but who's going to FTP into that again? No one I hope. If you want an internet facing server today 13 July 2009 your choices are Unix and Linux.

Re:SFTP support is still spotty ....

[DavidTC]

Both SFTP and FTP[S] are stupid damn standards.

What we need is a single port (Which lets out FTP[S]) protocol with optional encryption of the password, the control channel, and/or the data channel, to whatever level you want. It should be able to be used unencrypted (Which lets out SFTP), and shouldn't be commonly tied to actual account logins (Which more SFTP is.).

This is, in fact, what WebDAV is suppose to do, but WebDAV is just an incredibly crappy implementation, and it brings in its own problems by tying it to an HTTP server, as many people are already running HTTP servers with the wrong permissions for this, and HTTP POST is a spectacularly poorly-made protocol to start with.

In only partial jest, I suggest using IMAP, which seems to manage all this stuff without any problems at all. ;)

Oh, and it also needs 'finished the upload' support, where files get uploaded in their entirely and then atomically replace existing files. As part of the protocol, if you turn it on, not via clients doing an 'upload and then rename'.

Also needs good resume support with CRC checking server-side, so that clients can check that a file that's partially uploaded or downloaded is the right one by asking for a CRC of the already transferred part.

Re:SFTP support is still spotty ....

[Anonymous Coward]

WinSCP is awesome...until one tries to get users to use it. I don't understand it, myself. I guess that the interface is a bit busy and I can see how it could be intimidating to some. But once the thing is setup then the user can ignore everything except the drag-and-drop parts.

I've taken users through using the program, created icons on their desktops that will connect to a specific remote host and place them in specific directories on both the local and remote, but they just won't use it.

I've given up. The only web server that I deal with at this point is insecure and poorly-configured. I ssh in and prop it up when it falls over in a flaming heap (and then back away slowly). I didn't set it up, I don't maintain it, I have no say as far as policy goes and I just don't care.

Re:SFTP support is still spotty ....

[raju1kabir]

It should be able to be used unencrypted (Which lets out SFTP)

% sftp -oCipher=none myserver.example.com
sftp>

Uh oh... time to hit my sshd_config.

Re:SFTP support is still spotty ....

[bigbird]

Try CompleteFTP. It's a reasonably priced Windows server supporting FTP,FTP and SFTP (with SCP in the next release). (I'm one of the developers btw).

Re:SFTP support is still spotty ....

[Anonymous Coward]

Switching from FTP to SFTP on the server side is great, in theory, but it's really only a trivial task for people running Unix type operating systems.

SSH isn't an integral part of most Windows operating systems, and nearly all of the well-regarded, commercial FTP servers for Windows have no SFTP support in them.

(I understand the Serv-U FTPD for Windows does support it, but it's an exception to the rule.)

I recently ran into this at my workplace. We've run the commercial WFTPD product (from Texas Imperial software) for years, but I had to get rid of it when our bank started requiring SFTP connections to send us electronic scans of daily check deposits.

Serv-U has supported FTPS out of the box since their really early releases. They added support for SFTP v3 and v4 in version 7, and recently added support for SFTP versions 5 and 6 in their most recent major refresh. They also have a built-in web client that is accessible via HTTPS.

Re:SFTP support is still spotty ....

[DavidTC]

Yours allows it, many don't. Many administrators, and a lot of distros to start with, don't allow unencrypted ssh connections.

Oh, and I left one thing out of my list...anonymous access.

Re:SFTP support is still spotty ....

[Trogre]

You only need a SFTP server running on the web server, which will (should) be a Unix type system anyway. If you're running a Windows workstation, then there's plenty of clients that support SFTP, such as Filezilla.

Not FTP, but any -- especially on IpowerWeb

[www.sorehands.com]

Any credentials being stolen is a security Risk. I had some sites on Ipowerweb, which the credentials were stolen. They deny all knowledge of it, but it was the only source of the leak. I tracked this when I moved a site to my own server, but used the same credentials.

My Server

[ironicsky]

I run a linux server that has FTP services on it.I did have an issue a while back where someone's ftp account got cracked, someone uploaded a malicious root kit, then executed it through the web and... BLAMO! I was compromised. Every .html and .php file on the server was over written. I didn't feel like cleaning it up, so I just loaded the back ups on the a clean server and took the compromised one out of production.

But I did make one change on the new server... I upped the security substantially. One of the changes involved enforcing SFTP and discontinuing my FTP services.

For me, all it took was one serious compromise to wake me up. I'm sure for a lot of other people it will be the same.

Re:My Server

[neoform]

How does SFTP stop someone from getting ahold of a user's password and uploading another malicious script, then running it via web? Sounds like you had a web accessible directory that a user could upload to, unless you change this, the same thing can happen again. The only thing you changed was you encrypted the file transfer process..

Wowa.....

[sysgeek01]

I just had a flashback to 1999...

FTP is not dead, nor it will be for a long time.

[Anonymous Coward]

Shocking. At 10 O'clock: why telnet should not be used.

One of them even infected a spare WinXP computer (with Gumblar) to test the consequences. On the infected computer he created a new account in a popular FTP client and saved it. The server address was correct (his server) and the username/password pair was not valid. A few hours later in FTP logs, he discovered login attempts that used that invalid username/password pair from a Singapore IP, then from a Florida IP, the some other country's IP. Apparently the FTP credentials were somehow stolen from that infected computer.

A much better test would have been to create the account first in the client, and then infect the computer. How do you know the malware was sniffing the traffic and not capturing the credentials when the account was being created?

The author's personal experience aside, unless customers ask for it, hosting companies will not change it. And customers will not ask for it because most web editing programs have FTP support built in, but not SFTP.

Yes, we tell people to not use FTP (I run a security consulting company), and despite that I see major financial services companies with lots of business-critical processes built around FTP.

Bottom line: there is no business case, until a lot more people get burned.

And then of course there is the minor matters that [a] SFTP is not immune to keyloggers and [b] once you get a trojan like that on your computer, all bets are off.

Keyloggers don't care

[kenp2002]

SSH, SFTP, SCP, FTP, ZMODEM, KERMIT, AND ALL THAT CRAP MEANS NOTHING!

Why? because moron employees surfing for p0rn at work will get a keylogger by accident installed and grab more information then packet sniffers EVER will. Regardless of how well the encryption is the keylogger and malware will trump all measure if employees are careless.

You can get a silent VNC session going and lockout the physical keyboard and mouse and by the time they figure out what has happened you have enough control to grab what you need.

Hell just track the next time they go to amazon.com or any onther online site. Who gives a rats ass about SSL when you are seeing them type in their info?!

FTP vulnerable? No more then your home phone line or cell phone. The problem is and always will be PEOPLE. One they have control of the physical machine all bets are off for ANY security measure.

Arguing protocols being secure or not is like arguing which unloaded gun is more dangerous....

Re:Keyloggers don't care

[Anonymous Coward]

Two words: "ssh keys".

Any passphrase associated with an ssh key is meaningless to keyloggers unless they also get the keys themselves. Far as I know, most modern keyloggers aren't that sophisticated yet. Granted, they could very well become so, but so long as Windows users are kept in the dark about SSH/SFTP and keep using Telnet/FTP, they probably won't...

Waaaaaaait... THAT'S why FTP is still around! A decoy against users with keylogger'd machines! Keeps the rest of us safe! NOW I get it!

Re:Keyloggers don't care

[Hurricane78]

Yeah! That's why I replaced all my employees by very small shell scripts. :P

Re:Keyloggers don't care

[Abcd1234]

Arguing protocols being secure or not is like arguing which unloaded gun is more dangerous....

Oh please, that's bullshit. Keyloggers a) need to get installed in the first place, b) need to not get detected by a virus scanner or malware detector, and then c) need to be installed on a machine where the user accesses a sensitive site. And most of those issues can be mitigated with a properly secured OS.

A broken daemon configuration or protocol simply requires the hacker to exploit it.

So you're telling me those are equivalent? Please...

Re:Keyloggers don't care

[tibman]

I recently read about a keylogger that plugs into your powergrid and can read keypresses up to 15 feet away via groundwire. There are even physical keyloggers that sit between the keyboard and box.. how easy would it be for the wife or friend to do this while you take a bio break? Software keyloggers can be very benign and go undetected for long periods of time too. Lots of programs use "global hotkeys" and similar features which function in the background to monitor all keyboard input and trigger zero anti-malwar/virus warnings.

Re:Keyloggers don't care

[nine-times]

Well first, that's a good argument to make sure you don't have a keylogger, but not an argument against encrypting authentication while operating over an insecure network. Really, it's not a whacky or complicated idea. Unencrypted authentication is vulnerable to more types of attacks than encrypted authentication.

But just to argue the point, SFTP can be set up so that a keylogger alone won't get your login credentials. You can use public key authentication instead of a password. Now sure, public key authentication is potentially vulnerable to another sort of attack (someone with local access under your local account can simply copy the private key), but if you just want to talk about keyloggers....

Re:Keyloggers don't care

[Penguin Programmer]

If you have a keylogger, the attacker also has your machine password, and can get your ssh keys. SSH is great, but it doesn't protect you from keyloggers.

Re:Keyloggers don't care

[Anonymous Coward]

VNC with local keyboard disconnect -- you have about 30 seconds before I pull the plug.

Re:Keyloggers don't care

[Abcd1234]

I recently read about a keylogger that plugs into your powergrid and can read keypresses up to 15 feet away via groundwire. There are even physical keyloggers that sit between the keyboard and box.. how easy would it be for the wife or friend to do this while you take a bio break?

If someone gains physical access to your hardware, you're fucked either way. And if they go that far, why not just install a piece of gear on the LAN and start sniffing traffic or executing MitM attacks?

Just to bring things back to reality, we're talking about the feasibility of an attack. Physical security breaches for the purpose of industrial espionage or other hacking activities are not, for most people, a concern. And if they are, there are plenty of physical security measures one can put in place to help mitigate them.

In reality, software keyloggers are the big concern. And malware/antivirus detection software will catch those. Hell, a well tuned firewall with L7 filtering might even catch the attempts to send the logged key data before it ever reaches the endpoint.

Software keyloggers can be very benign and go undetected for long periods of time too.

Again, that's what malware detection is for. I already addressed that. Why did you choose to ignore it?

Lots of programs use "global hotkeys" and similar features which function in the background to monitor all keyboard input and trigger zero anti-malwar/virus warnings.

You still need an application coercing these "programs" that you refer to to collect the data, and something still needs to send said data somewhere. Again, malware detection will catch something like this.

Re:Keyloggers don't care

[tibman]

I was bringing up physical keyloggers because they would take seconds to install and in the case of the power one... they don't even have to be in the same room (or apartment!). I was staying ontopic with keyloggers only, not other physical attacks.

I read your comment and i know you said to use malware detection, i did not ignore that, i addressed it. Keyloggers are not considered hostile to anti-virus and anit-malware programs.

Most data transmission is done via irc, email, im, and even http put/gets. This sort of thing happens dozens of times on your computer, i'm sure.. itunes update check, FF update check, windows update, usage polling, lots of programs report back home without triggering anything hostile.

You should write a keylogger in C# and see for yourself, i think you'll be amazed. Then take an hour and make it autolaunch from a thumbdrive and copy itself onto other portable media. All under the watchful eye of your anti-virus.. it's scary!

So much for regard

[Anonymous Coward]

I can't see why they should be considered well-regarded then. That's negligence. Pretty much every Windows FTP client for the last 5 years commercial or otherwise does SFTP now.

Re:So much for regard

[Trashman]

I can't see why they should be considered well-regarded then. That's negligence. Pretty much every Windows FTP client for the last 5 years commercial or otherwise does SFTP now.

Well, third-party clients, Yes. But, why is that in 2009, Microsoft doesn't ship a client (or a server) that does SFTP with their OS?

Re:So much for regard

[RalphSleigh]

Client != Server?

Quite why you would run a FTP server on windows is a

Re:So much for regard

[The Cisco Kid]

No one competent would *ever* run any sort of Internet-connected server on a Windows platform, period. And while I'm sure the astroturfers will point out all sorts of well-known websites that run Windows, however that does not change my point.

Re:So much for regard

[hrimhari]

So basically you're saying that people can install MS Office or Dreamweaver, but not FileZilla?

Microsoft doesn't ship with Word unless it's a trial or you buy it. That doesn't change the fact that MS Office still has a market share of 95%.

Re:So much for regard

[Trashman]

So basically you're saying that people can install MS Office or Dreamweaver, but not FileZilla?

No, that's not what I'm saying. The post I replied to said that pretty much every third party client has SFTP support. Given that Windows ships with an ftp client and server, Why won't they ship an SFTP client or server? MS gives us telnet, but no ssh. WTF!? Pretty much every OS I've used in recent years has these, but Windows does not.

Re:So much for regard

[ConceptJunkie]

But, why is that in 2009, Microsoft doesn't ship a client (or a server) that does SFTP with their OS?

Because they don't want to compete unfairly against Cygwin?

Re:So much for regard

[nine-times]

Probably the same reason why they don't go ahead and replace their CLI environment with some standard-ish Unix shell (e.g. bash) even though it would be a much better solution than their current command line. It's Not-Invented-Here and would increase interoperability, thereby decreasing vendor lock-in. Even if they do implement it, they'll make some weird incompatible implementation with patented "improvements".

Haven't you been paying attention?

Re:So much for regard

[Anonymous Coward]

There you go including Microsoft & "security" together...

Re:So much for regard

[WuphonsReach]

Well, third-party clients, Yes. But, why is that in 2009, Microsoft doesn't ship a client (or a server) that does SFTP with their OS?

"Those who don't understand unix are doomed to reinvent it, poorly." -- Henry Spencer

(Actually, as mentioned elsewhere, they do finally provide FTPS or SFTP in IIS7 on Win2008 server.)

FTP isn't going anywhere

[BigJClark]

Its an amazingly simple protocol, lightweight, and easy to setup and administrate. Concerned about security? Tunnel it with SSH. I think there is a packaged app out there somewhere (sftp?), but really, I tunnel all insecure protocols with SSH, using an incredibly simple, yet powerful app (putty).

Re:FTP isn't going anywhere

[Hurricane78]

Exactly. I remember that this modularity was called "the Unix philosophy".

But now many people use Unix-like OSes (even if only indirectly), and do not understand this, because they are crippled by their tiny Windows world of big monolithic desktop apps.

Re:FTP isn't going anywhere

[Corporate Troll]

I think there is a packaged app out there somewhere (sftp?)

Not really, no.... From Wikipedia: SFTP is not FTP run over SSH, but rather a new protocol designed from the ground up by the IETF SECSH working group.

Re:FTP isn't going anywhere

[Anonymous Coward]

SFTP is not FTP tunneled over SSH, it's a protocol for file transfer which is not based on FTP in any way. In fact, due to its dual connection nature, FTP is not trivial to tunnel over SSH. And since SFTP exists and is built in SSH servers, its a waste of time to try to tunnel FTP over SSH.

Re:FTP isn't going anywhere

[Abcd1234]

I think there is a packaged app out there somewhere (sftp?),

Ah, no. SFTP is a completely different protocol, a file transfer protocol layered over SSH that's separate and distinct from FTP. In fact, tunneling FTP over anything is non-trivial, thanks to FTP's dual-channel nature.

Concerned about security? Tunnel it with SSH.

But... if you're going to tunnel with SSH anyway, why wouldn't you just use (the real) SCP/SFTP? It's even more easily secured, and it's firewall friendly, too. For Gnome/KDE users, you can then access the sites directly using the sftp:// protocol in Nautilus/Konqueror, and for Windows users, they can just grab themselves a copy of WinSCP.

Re:FTP isn't going anywhere

[DNS-and-BIND]

Well, until this discussion, I honestly didn't know there was a difference between FTPS and SFTP. I just sort of mentally lumped it together with "secure FTP that never freaking works as advertised, especially under Windows."

Re:FTP isn't going anywhere

[BigJClark]

Fair enough, I've just come to realize there is a distinction. The reason why I don't use SFTP probably is because I'm a creature of habit, and I'm quite used to firing up putty, then remoting in, or doing whatever business I have to do. To be honest, I might FTP only a couple times a month, so its not as though I'm losing any productivity.

When I get some time (I'm way too busy reading slashdot articles, as you can tell ;) ), I'll give SFTP a thorough read-through.

Re:FTP isn't going anywhere

[Anonymous Coward]

FTP is actually not that simple to administer, in some ways. FTP is constantly creating new TCP connections for each directory listing or file transfer, and the new connections have a different destination port than your original connection. This fact makes FTP difficult to proxy.

For example, this dialogue could occur in an FTP session:
Client: PASV (Request PASV mode)
Server: 227 OK (192,168,1,1,123,456) (I'm listening on a new port at 192.168.1.1:31944) (because 31944 == 1238 + 456)

So your proxy software would have to see and understand this exchange, and begin proxying port 31944 also. Your proxy has to be "FTP-aware." If you were using putty to proxy your FTP control connection, this new connection would not use the SSH tunnel, and you probably wouldn't even notice.

The alternative would be to use PORT mode, which requires a new connection from the *server to the client,* with the obvious security risks and firewall/NAT problems that implies.

Yes, FTP is a silly protocol, but it dates from simpler times when NAT didn't exist and security wasn't the huge problem it is today. Daniel J. Bernstein wrote a good mid-level description of FTP at http://cr.yp.to/ftp.html .

-D

Re:FTP isn't going anywhere

[Anonymous Coward]

FTP expects the server to connect back to the client to run. That's not a simple protocol for something as simple as file-transfer.

Re:FTP isn't going anywhere

[fnj]

That's port mode. Relatively few people use it. Passive mode is much more common. You're still right, though. Ftp is a crazy protocol in either mode. Scp is just so much more straightforward and capable, it's crazy to use ftp for most purposes (anonymous ftp aside).

Re:FTP isn't going anywhere

[jackbird]

Windows users, they can just grab themselves a copy of WinSCP.

FileZilla supports SFTP and FTPS out of the box.

Re:FTP isn't going anywhere

[Corporate Troll]

Except sftp works as advertised under Windows. Well, I don't know of any "Drive mapper" that is Free, but I do know that Filezilla does the deed just fine. (Can't say for Windows Servers.... I obviously do not do Windows as Servers)

Re:FTP isn't going anywhere

[nine-times]

It really should just go away. There's no excuse for using a protocol on the web that includes unencrypted authentication. If you have to set up additional tunneling of one protocol through another protocol just to ensure secure authentication, then your first protocol isn't really doing its job. FTP is simple? I guess, but it stinks. Even today, even using passive mode, you sometimes see weird/stupid problems with FTP going through firewalls and VPN tunnels.

People really should be using SFTP, but it's suffered from some other problems. For one, there hasn't traditionally been any easy/standard way to jail users once they log in. OpenSSH has recently included jailing functionality, but it still requires that users home directories are read-only and owned by root. Second, FTP clients all default to using FTP, and users who are just barely computer literate enough to put in hostname/username/password are put off by having to alter any other settings.

Re:FTP isn't going anywhere

[Anonymous Coward]

amazingly simple protocol

Not.

Insecurities in ftp

[Cheech Wizard]

My apologies, but you must be new at this if you are just now recognizing the insecurities in ftp. I've did what Sinegubko did on a VM and watched. All I had to do was visit an infected page with IE and the machine was infected. It then 'stole' the bogus ftp passwords I put in a Dreamweaver install and away things went.

Sorry to hear you had a problem, but you really should have known better.

So basically...

[Mr. DOS]

...user gets infected with spyware, is surprised when information is stolen as a result? Y'know, it's called spyware for a reason.

      --- Mr. DOS

Thats not a rootkit

[Viol8]

A rootkit compromises your entire OS by modifying system files and binaries and allowing remote root access. Mucking up the web server files is annoying but hardly in the same league. And more fool you if you ran apache (or whatever) as root. Also if you'd set it up properly you wouldn't have to "clean it up". You'd just rm -rf the web server directory tree and untar from the backup you made the previous night, right?

Re:Thats not a rootkit

[ironicsky]

That does make sense and I agree. Apache doesn't run as root, it runs as nobody. But the person uploaded a php executable which broke out of the nobody and went gallivanting around the server. From there, it messed with my cPanel, renaming all index and php files
And then it did indeed root the server, certain programs started acting strange, random processes would start, my w and who commands were coming back blank, etc...

I learned early on from my windows days that once a server is compromised the best thing you can do is move on, wipe the system and start over.

Re:Thats not a rootkit

[socsoc]

That is the best thing to do, with a windows server.

Only /.ers Care

[Dracos]

The reality is, only the kind of people who read this site actually give a damn, and I bet for at least some, it's an academic concern.

Hosting companies don't care.

Server management software vendors (CPanel, etc) don't care.

Other vendors whose software relies on FTP (Dreamweaver, etc) don't care.

Why don't they care? Because retraining users and staff is something on which they can all put a reasonably certain dollar amount, which is almost certainly higher than maintaining the status quo of tedious disclaimers and putting out fires when they erupt.

The average user doesn't care, because they assume that a product or service is reasonably secure, and many of them can't be bothered with any technical details.

I agree, and have for years, that FTP should be unmercifully killed, certainly on public networks. I'm no security zealot, but this is pretty basic stuff.

Re:Only /.ers Care

[hedwards]

And that's where the legislature ought to be stepping in. Put a tax, fine or require companies to pay for the damage that they do by not properly securing their equipment. Or better still fine the crap out of companies that get caught advertising via spam.

There's far, far more wrong with FTP than would be fixed by proper authentication regimes, it wasn't ever meant to be used in a networking environment that doesn't allow for direct connections between machines without hackery.

Paper tape of course

[davidwr]

I send my files in by paper tape sent by a bonded, armed courier.

Re:Paper tape of course

[LihTox]

I send my files in by paper tape sent by a bonded, armed courier.

You only think he's a courier. Muhahahaha!

(Now where's that Anonymous button...?)

Not just unknown, incompatible

[danaris]

I have tried to set up an FTPS site.

Even with vsftpd, I was unable to configure it with settings that allowed it to connect with more than 1 different type of client at a time. So far as I can tell, there are a half-dozen different implementation of FTPS out there, none of which are able to interoperate properly.

SFTP is much more standard and well-supported, and more or less just works, and there are various tutorials out there for setting it up.

Dan Aris

Re:Not just unknown, incompatible

[Anonymous Coward]

Windows Server 2008 has a free downloadable add on for FTPS in IIS 7.0. I have had success in implementing this with FileZilla as an FTPS client.

Re:Not just unknown, incompatible

[danaris]

Windows Server 2008 has a free downloadable add on for FTPS in IIS 7.0. I have had success in implementing this with FileZilla as an FTPS client.

Very nice, for those who can afford Windows Server 2008.

However, a) we can't, b) it's on a Linux server, and c) this was before Windows Server 2008 was even in public beta (so far as I know).

Dan Aris

Re:Not just unknown, incompatible

[neoform]

I've worked with many different FTPS server and they're all very easy to use. Mind you, I was always using windows (FileZilla server, Ability FTP Server).

Hello...mcfly...

[furby076]

SFTP...use it. That or make a torrent and set it so only those given the torrent can access it. Different torrnet programs have different privacy capabilities to allow you to utilize their program to transfer files, securely, from your computer to a specific recipient.

store

[roedelius]

I still don't understand why slashdot's CSS designer, having apparently never heard of the

tag, turned tags into block level elements that aren't even italicized. TFA is a good example of why not to do that (see "store", "could", "same")

Re:store

[clone53421]

I don't know. Maybe it's to make them look stupid for not using the <em> tag like they're supposed to.

(okay, okay, I agree... breaking <i> is stupid, even if it is deprecated.)

Re:store

[Anonymous Coward]

Actually, neither <i> nor <b> have been deprecated.

http://www.w3.org/TR/html5-diff/

They are both now considered semantic and not presentational. Think of the old manuals of style.

Well, maybe Re:Authentication goes both ways.

[davidwr]

If the server's been compromised and it's key stolen and nobody in charge knows it's stolen, all bets are off.

PS: "It's been 4 minutes since you last successfully posted a comment" what happened to only waiting 1-2 minutes between postings?

Re:Well, maybe Re:Authentication goes both ways.

[Jake Griffin]

/. uses FTP for posting. Someone hacked in and modified the time limit.

The security lie

[Lord Bitman]

Once you have discovered you are infected, the ONLY way to be safe is to assume that you have also been infected in at least 100 other, undiscovered, ways.
Security companies like to sell the lie of "buy our product! Be safe! And if something slips through, just hit "delete" and be safe again!" but it really doesn't work like that: If there's one, there's three, and those three turn into a hundred very easily.

The only way to be safe is not "buy some guy's security software" (you're machine's been compromised, how the hell is running something else on the same machine supposed to help??), it's "reformat, treat every backed-up file as compromised". Sad, annoying, true.

In summary: when you found out you were infected, you did the equivalent of nothing at all, then were surprised when a password was stolen several months later.

Re:The security lie

[iamacat]

It depends on what you mean by safe. There is a likely price of being compromised and there is a cost of spending two weeks of your time hunting down the CDs and reinstalling all your applications just the way they used to be. For most people, this is a prohibitive form of insurance compared to buying an antimalware tool. For example, the article's author was able to recover from the actual exploit in less time than it would have taken him to rebuild the PC in the first place.

The equation is very different if your data is extremely valuable (government top secret documents) or the value of your time is very little (most computer science students).

Re:The security lie

[jimicus]

The FSM had the idea of imaging and lo! it was good.

And so He did lower His noodly appendage and create Ghost, Acronis TrueImage, dd and g4u. And He saw these applications and He was pleased. For they were good, and they prevented much Wailing and Gnashing of Teeth.

Re:The security lie

[iGoMogul]

Very true.

This is the biggest issue, really. Honestly, the only way to truly be safe is to throw out your Ethernet cables and never install your Wi-Fi drivers. You can have plenty of fun playing Solitaire and sweeping mines!

All jokes aside, if you have even an inkling that you could be infected by malware, the only truly safe route is to format the box. Security measures mean nothing when the system has already been compromised. Of course, it's easy for people to let it slide when they have their system configured to their liking and don't want to put the effort into truly resolving the issue.

FTP isn't completely secure, that's a fact. But that lies alongside the real problem: nothing is really secure. If they got your login information for your FTP, they can get your login information for nearly any other application you happen to run. Preparation (fixing security holes as much as possible) and proper resolution (in the case of infection, formatting) are the only ways to truly solve the issue before it progresses into a real problem. That being said, it is true that people should use SSH, if only to add another security measure to the protocol.

I guess it boils down to the fact that it's more important to be safe than to be lazy.

- Kevin @ iGoMogul

tl;dr

[olborer]

tl;dr

Not every machine is on teh webs

[spungo]

I spend a lot of time on working on closed subnets -- ftp is v useful for systems when there's only one or two users with access -- and everything is done in a secure room. Do we really need to sledgehammer of ssh? Admittedly I didn't RTFA (on principle, you understand), so why should everyone be denied ftp when it is not dangerous to all?

Re:Not every machine is on teh webs

[hackel]

*Especially* in a closed subnet, then even if only two people in that office have access to the ftp server/passwords, anyone else can get infected by spyware/packet sniffers that then have easy access to your passwords. I still remember having endless fun back in high school sniffing people's email passwords and such. What I don't understand is why anyone would prefer FTP in the first place? Every FTP client I've used lately also supports SFTP, so what difference does it make which protocol the user selects? It's beyond me...

Re:Not every machine is on teh webs

[spungo]

I think you misunderstand -- it is a CLOSED subnet -- four or five servers, with two or three users in a secure room. The ftp passwords never leave the secure environment -- no other machines are connected to it -- where exactly are spyware sniffers going to come from (OS loaded out of the box -- no connection with outside) -- even if there were sniffers, nothing can ever leave the subnet!!

Re:Not every machine is on teh webs

[socsoc]

nothing can ever leave the subnet!!

Sounds like your subnet misses one of the main purposes of a network.

Re:Not every machine is on teh webs

[raju1kabir]

If it's a subnet, stuff can leave it. Maybe the source of others' confusion is that you're thinking of a closed network.

well then the answer is simple

[circletimessquare]

get rid of the people

all joking aside, people are people. they are a known quantity. as such, they are the yardstick against which we judge securability, not to which we assign blame. and since this whole intarwebs thing is relatively new, then the obvious answer is we have a long way to go to fix the TECHNOLOGY so that the people in the equation can't cause as much damage as they are now doing

its very easy to blame the lusers. your post means nothing

Re:well then the answer is simple

[kenp2002]

its very easy to blame the lusers

That's because they are the largest contributor to an insecure system.

your post means nothing

My post means that you are better off spending more time training people then finding new technological ways to make things stupid-proof.

Missing the point...

[hackel]

Amazing how this article (and so many people responding) seem to be missing the point entirely. The real problem is people using operating systems that are vulnerable to these types of attacks! I don't know about Vista, but even if Linux was ever targeted for this kind of attack/spyware, you would have to run the software as root to enable packet sniffing! And anyone who uses IE for regular browsing and not just local site development is clearly not a competent web developer and has no business working in this industry! Seriously--how can anyone still use IE, FTP, or anything like that in this day and age? I think I stopped using FTP, what...10 years ago now?

The bottom line is that all hosting companies must disable all access to their services via insecure FTP. It's shameful how many companies still use it. I'm in such an isolated bubble, apparently, that I didn't even know this was still going on until recently I had to access a shared web service to migrate a particular client. I was shocked, to say the least! Secure-FTP (over SSL) is not sufficient as it only encrypts things without verifying the authenticity of the host you are connecting to. It's bad enough that people keep using Windows, but since we can't control this, competent sysadmins really need to take the initiative in disabling FTP. Likewise, unencrypted pop3, imap, telnet, or whatever unencrypted services they provide.

Re:Missing the point...

[DNS-and-BIND]

So your point is that you isolated yourself in an ivory tower surrounded by people who think like you do, and you're shocked and disgusted at what the great unwashed masses are doing? How can you live in such a small world? What are you, a journalist?

Re:Missing the point...

[The Cisco Kid]

encrypting the connection isnt going to do you any good when the crapware is running *on* the client machine, which has to have the cleartext pasword and/or private key in order to establish the connection. Really 'packet sniffing' isn't really the big danger. ISP networks rarely have windows machines (at least not connected where they have access to sniff anything,) and the network routers and switches are rock solid.

Re:Missing the point...

[hackel]

Well that was the point the article was making, wasn't it? That even though theoretically spyware could read all of that stuff off the local machine, for the most part it's too difficult to know the format all those various programs use to store passwords, so it's easier to just sniff them in plain text. And even if you have secured your own computer, if a spyware packet sniffer is running on another computer in your network it has access to all that unencrypted traffic as well. It's using operating systems and browsers which are vulnerable to these attacks in the first place that is the biggest worry.

Re:Missing the point...

[Alun Jones]

FTP over SSL _does_ verify the authenticity of the host you are connecting to, in the same way that HTTPS does. Checks that the certificate is issued by a trusted root, and that its CN matches the domain name provided to the client. I agree with you that the bottom line is that companies must stop using unencrypted FTP - I disagree with your conclusion, that all FTP is therefore bad.

Re:Missing the point...

[nine-times]

Secure-FTP (over SSL) is not sufficient as it only encrypts things without verifying the authenticity of the host you are connecting to.

Well what really does verify the authenticity of the host you're connecting to? SFTP doesn't really, it only verifies that the host you're connecting to is the same as the host you connected to before. SSL CAs sort of do, but most of them don't really work that hard to verify who they're giving certs to.

Re:Missing the point...

[Anonymous Coward]

To display the laughing cats download this file and type "sudo keylogger"

Re:Missing the point...

[bigbird]

Secure-FTP (over SSL) is not sufficient as it only encrypts things without verifying the authenticity of the host you are connecting to.

That's actually only the case if you switch off host verification.

Normally with FTPS you would compare the certificate that the host sends you with your certificate store to either 1) verify you have that certificate already or 2) that the certificate is signed by a CA in your store and that its common name matches the domain name you are connecting to.

Re:Missing the point...

[Anonymous Coward]

Ya because everybody doing web sites is a developer. What about suzy homemaker with her yarn and kittens site? The girl at the local dog pound posting pics of the puppies? Grandma's bridge club calender? Etc. etc.

These people haven't a clue what FTP is, or even what a web browser is. They know that the internet is that thing you click on, and to put stuff on the internet you use this other thing someone showed them how to use 8 years ago.

Re:FTP is not dead, nor it will be for a long time

[Anonymous Coward]

Yes. Doesn't TFA write understand that keyloggers will get _ALL_ keystroeks, before they are encrypted for transmission?

FUD. Bullshit article.

[EddyPearson]

I'm sorry. Is this Slashdot? This articles reads like it was written for the idiots, by idiots.

I've only skim read this dross, but it doesn't seem to make any concrete points. It draws attention some stupifyingly obvious security considerations (I wouldn't go as far as to call them bugs), babbles on about Windows spyware and then has a short excerpt from the GoDaddy help (what the fuck?)

What a waste of text, this boils down to 4 things:

1. User chose an easily guessable user/password for FTP.
2. User left user/password for FTP somewhere world readable
3. User got spyware which stole FTP details stored on his machine.
4. MITM attack on FTP session, stealing user/password over the wire. (this one I assumed because it's recommending SFTP without tellings us WHY)

Let me cut this craptastic essay down to size:

Easy to crack passwords get cracked easily.
Spyware steals login credentials.
Hackers can use MITM attacks to intercept data.
People are stupid and sometimes leave login credentials in a public page.

Frankly the editors should be embarrassed.

Wrong debate

[The Cisco Kid]

ftp vs sftp is not the issue.

using windows to (ftp *or* sftp) vs using a secure platform to (ftp *or* sfp) is the issue.

Switching to use sftp using going to do you any good if you are still working from a windows based client, and your stored passwords will still be stolen by the deluge of crapware that windows is specifically designed to support.

Re:Wrong debate

[hjf]

wow! troll much?

Misconception about crypto in article

[TerranFury]

From TFA:

And if an attacker managed to do that, then I assumed that the risk of passwords being stolen by spyware was about the same whether I used FTP or SFTP -- because either way, the spyware could just steal my password by reading it out of a configuration file where the password was stored. (Even though FTP and SFTP programs both store passwords in an encrypted format, the programs have to be able to decrypt the passwords in order to use them whenever the user wants to open a connection. So the spyware could just mimic whatever steps the client programs use to decrypt the stored passwords, in order to steal one of my passwords stored in a file.) So, I assumed it made no difference whether I used FTP or SFTP

This is incorrect. A decently-written program will not store your password anywhere, either encrypted or as plaintext. What it will store is a one-way hash of your password. When someone connects, it will compute a hash of the password they entered and compare it to the stored hash. Nowhere in this process is the actual password decrypted.

Rainbow tables allow one to attack these kinds of schemes, but adding salt to passwords basically makes even this impossible.

This may seem to contradict the "DRM is impossible" principle but it does not because the problems are different. For passwords, you only need to prove to me that you know the secret; you don't need to tell me what the secret is. For DRM, the music or movie is the secret, so it has to be revealed: You wouldn't pay iTunes for proof that they know what a certain song sounds like; what you want is the actual song!

Re:Misconception about crypto in article

[LostOne]

Bzzzt! Fail.

That only works on the *server* side. TFA is talking about the *client* software which saves the password for you so you don't have to enter it every time. There is no possible way for the client software to provide the correct password to the server unless it can obtain it, either by decrypting its stored password or by querying the user. So, no, a one-way hash is not usable in that circumstance.

Re:Misconception about crypto in article

[gggggggg]

What if you are not requesting a user to input their password again ("save password" checkbox)? Many clients can reconnect to a saved profile without requiring you to type your password again. They are obviously saving it somewhere and it is arguable that this password store can be cracked.

Re:Misconception about crypto in article

[TerranFury]

TFA is talking about the *client* software which saves the password for you so you don't have to enter it every time.

Whoops, my bad. I'd thought he was talking about a compromised server.

Bzzzt! Fail.

However, that's just obnoxious.

Re:Misconception about crypto in article

[TerranFury]

Yeah, I'd agree with that. I'd missed that he was talking about a compromised client rather than server.

Wrong side of the problem

[gmuslera]

No protocol is secure if your side aren't. A keylogger, in your pc, not in the remote site, defeats anything that is password based. Trojans that read or steal configurations of common clients (even ssh certificates) also defeats a lot of usually secure solutions. Even installing software that enables remote administration and not worrying ever about announces of remote vulnerabilities is wrong. When worrying about something that can be accesed in internet, remember that you are in internet too.

Where you should start changing things? replacing the ftp protocol? the ssh protocol? tcp protocol? Start changing yourself, securing your desktop in effective ways (drastically lowering odds switching away from windows could be an start), and how you use it.

include it in the OS

[i621148]

graphical ftp is included in windows and mac. graphical sftp is included by default in most linux distros. since it is "so hard" to download filezilla for windows and mac, that could be the final hurdle? why don't they just include a standard graphical sftp client in windows and mac?

Re:include it in the OS

[Culture20]

why don't they just include a standard graphical sftp client in windows and mac?

You're joking, right? Admit that SMB and AFP aren't the bestest file transfer protocols ever? Apple maybe since they have ssh(d) built in, but Microsoft never will. MS has had ample time to add ssh/sshd to their OS. IIRC, OpenSSH is released under the BSD license, so MS can do whatever they want with it. They refuse.

RIP FTP?

[Junior J. Junior III]

ORLY?
WTF BBQ!
TL;DR.

Re:RIP FTP?

[orsty3001]

BRB , FBI

Re:RIP FTP?

[Junior J. Junior III]

GTG, KTHXBAI.

Re:RIP FTP?

[orsty3001]

KTHXHAND

securing ftp

[Danathar]

There are many ways of securing plain ftp

1. FTPS

2. OpenVPN

3. IPSEC (I use transport mode)

4. GSSAPI authentication

Those are just a few.

SFTP is nice but does not have as many features as fanilla FTP

Re:securing ftp

[Anonymous Coward]

What features does FTP have and SFTP doesn't? And no, using separate control and data connection isn't a feature.

Re:securing ftp

[raju1kabir]

SFTP is nice but does not have as many features as fanilla FTP

What's a feature of fanilla FTP that you find missing in sftp?

Re:securing ftp

[bigbird]

SFTP is nice but does not have as many features as fanilla FTP

What features are missing?

Rambling nonsense

[Anonymous Coward]

I'm not trying to be a jerk here, but am I the only one who thinks this slashdot posting is total rambling nonsense? It's about 100 times longer than it needs to be. I'm not really even sure what he's talking about.

Basically this guy has discovered that sending data in the clear is bad, so that is why he now thinks FTP is bad. But for some reason he believes that this is a new discovery? I'm confused.

RTFA!

[SanityInAnarchy]

From TFA:

I figured this wasn't worth worrying about, because it was much more likely that an attacker would attempt to steal the password by installing spyware on my home computer.... So, I assumed it made no difference whether I used FTP or SFTP.

But according to what Sinegubko told me, this reasoning was probably wrong. The problem is that even though spyware installed on your machine could read passwords that are stored in configuration files, it would be a lot of work to write a spyware program that could do this, because every FTP program and SFTP program stores passwords according to a different algorithm. It's much simpler for spyware to simply watch the traffic sent and received from your machine, so that any unencrypted passwords will be spotted

Same goes for keyloggers, by the way. You can look at everything I type and hope you get a password, or you can just intercept FTP, where you know exactly where the password is being sent.

Not that we shouldn't protect against keyloggers, but why would you make it easy?

FTP vulnerable? No more then your home phone line or cell phone.

Not true -- while eavesdropping is probably easier with a phone conversation, man-in-the-middle attacks are much harder. If you said something, I know it was you who said it, because it sounds like you -- whereas with FTP, the server doesn't know if I uploaded the file, or someone in the middle uploaded the file, or someone who stole my password uploaded the file.

You can get a silent VNC session going.... Hell just track the next time they go to amazon.com or any onther online site. Who gives a rats ass about SSL when you are seeing them type in their info?!

Because you have to 0wn me first.

If you don't bother with SSL, then there's no way the user could be careful enough or savvy enough -- the next time they order something from a wireless hotspot, someone else's laptop will automatically pick out their credit card number.

If you do, they suddenly have to not only compromise your machine, but actively watch for you to hit amazon.com, or write a much more complex program that hooks into IE (but what if you're not using IE?) and watch for amazon.com, or search through pages and pages of keylogs.

The problem is and always will be PEOPLE. One they have control of the physical machine all bets are off for ANY security measure.

Both very true. But until the person or the physical machine is compromised, all of these other things mean a good deal more than "nothing".

It sounds very much like you're suggesting that we ignore security and encryption, because it's all futile anyway -- you certainly haven't offered a better approach. Well, you know what? Fuck you and your defeatist attitude. The rest of us will be working to actually make things better.

Re:RTFA!

[kenp2002]

Fuck you and your defeatist attitude

Get help, you need anger management.

http://www.apa.org/topics/controlanger.html#manage

Re:RTFA!

[SanityInAnarchy]

Thanks. You really changed my life. I have a whole new outlook on things.

Really? Anger management?

No, it does make me angry that you are telling people that more secure software does not matter. You are making the problem worse. Hopefully that "fuck you" got your attention.

But if you really want to make it about anger management... I didn't use capslock. I didn't even use bold or italic. You're the one who opened with "ALL THAT CRAP MEANS NOTHING!"

Re:RTFA!

[kenp2002]

Which is my observation but being foul mouthed towards complete strangers places you in a class with adolescent children and I will waste no more time with a child. Get help.

Re:RTFA!

[SanityInAnarchy]

So does using capslock, and being condescending towards someone for using a curse word.

But I don't suppose I should be wasting time with someone who would so easily dismiss an entire human being over one word. Even one "outburst", if you like.

Security through being different?

[Vellmont]

What I get from this overly long article is the author thinks that simply by not being the same as the herd (the herd being people who use FTP) that increases security.

While there's some truth to this, it's a lot less than you think. Being different in one way doesn't save you from all the other ways you're the same. If someone can install malware on your machine, a keylogger would grab ANYTHING you type in. It's not too hard to parse out all of that for username/passwords. It's like saying having a strange non-standard layout to your house keeps you safe from really dumb burglars that've already broken in.

Re:Security through being different?

[Culture20]

It's like saying having a strange non-standard layout to your house keeps you safe from really dumb burglars that've already broken in.

I find the ten-dimensional topography of my home's interior to be sufficient deterrent against all but the most intelligent burglars (and they tend to leave stuff alone, content to explore).
- M.C. Escher

Dreamweaver, sftp

[drougie]

FYI for those of you who rely on Dreamweaver you can in fact get it to use SFTP without any addons or tweaks. In the remote info under manage sites, in the advanced tab, selecting ftp up top, you can check Use Secure FTP (SFTP). If you run the server yourself, you want to install openssh, the common package name for which is openssh-server and its conf files may be found in /etc/ssh. If you don't run the server, ask your ISP to fire it up if they haven't already.

This of course won't defend you from getting nailed by a keylogger phoning home... but ditching XP and using nano or emacs on *nix of course would help. Do regular backups just in case -- not just the docroot folder but sql if you use that as well.

FTP, rsync+ssh

[dwheeler]

FTP is still fine for providing big files that don't need to be protected by a password. But yes, if you're CHANGING data, raw ftp is usually a bad idea.

If you're uploading files, I heartily recommend using rsync+ssh. It's incredibly fast, since only the files that CHANGED are uploaded, and ssh makes it all secure. It can be a pain to set up on some cheap hosting sites, but I've figured out how to make rsync+ssh work even on some cheap hosting sites. Hope that helps.

They steal passwords from config files

[UnmaskParasites]

Hi,

I'm Denis Sinegubko. The one quoted in this article.

I want to clarify one thing about how malware steals passwords from webmasters' computers.

TCP traffic sniffing was only one of possible vectors.

However, now I have more proofs that malicious programs just read configuration files and registry settings.

Just check how this trojan steals FTP, email and IM credentials:
http://www.viruslist.com/en/viruses/encyclopedia?virusid=147349

I checked programs, installed on my computer and indeed many of them store passwords in _plain text_, not encrypted. And those that encrypt
passwords use very weak algorithms.

FileZilla stores FTP credentials (including passwords) in .xml files in plain text. And this is "by design"! Check this thread:
http://forum.filezilla-project.org/viewtopic.php?f=2&t=12280

So why would malware bother with sniffing traffic or key logging (this activity can be detected by antivirus), when it can simply read everything it needs from files and Windows registry?

Re:They steal passwords from config files

[clone53421]

Absolutely. People should be more aware of exactly what is stored on their computer, and far more cautious about allowing people to access it via file-sharing, etc.

I've "hacked" several IM accounts by finding people's (insert name of certain IM client) .ini files shared on LimeWire. Yes, I know, that makes me a bad person (okay, I didn't do anything with the accounts, other than verify that the credentials were still good). It was more proof-of-concept than anything else – I discovered that the passwords were weakly encrypted and stored in the .inis, so I went sniffing on LimeWire to see how many people had this vulnerability left wide-open. (As LimeWire does not share .inis by default, nor does it share the Program Files folder, only relatively few and remarkably stupid people...)

(This was a while ago. I don't know if the particular IM client still stores the passwords in the .inis.) I do also remember that the version of AIM at that time had its (also weakly encrypted, via a nearly identical algorithm for what that's worth) passwords stored in the registry instead of the .ini, which meant that a LimeWire attack was out of the question... however, still not safe from someone who can read your registry (which, of course, would require compromising the computer rather than just sniffing their LimeWire shared files to see if there's anything sensitive).

I've also found all sorts of online account information in varied document formats shared on LimeWire. (Typically these were already compromised, though, and either locked out or had their passwords changed.) IIRC I was able to log into someone's e-mail account, noted that it appeared active, and decided to send them an e-mail, to themself, noting that their password was shared and warning them to change it and stop sharing their sensitive documents on LimeWire. Have no idea what came of that, but hopefully they got the message...

Posting as myself because, well, I don't really care if people know I did this. I often make a point of reminding people to be careful of what they share on file-sharing services, so I do feel like my "research" is being put to some decent use.

What to replace ftp?

[tc3driver]

That is the real question.

Considering that windows will not natively run ssh, sftp, scp, etc... That leaves millions of site owners with no way to upload content. Unless they want to run cygwin, or pay for programs, and this is all assuming that they are connecting to a *nix server from a windows machine... what do you do on a windows server? IIS? even Apache on a windows server, as far as I know windows servers still tout telnet, ftp, and rtp as the methods of remotely manipulating files. So as it comes down... I still have to blame windows... for once I would like to be able to blame something other than windows, or some Microsoft product... but it seems that I always have to come to the same conclusion.

Please note that the last IIS server or windows server I worked with was a SB2k3 server about 4 years ago, so something may have changed.

Re:What to replace ftp?

[bunratty]

How about PuTTY for ssh and FileZilla for sftp? They're both open source.

Re:What to replace ftp?

[tc3driver]

How about PuTTY for ssh and FileZilla for sftp? They're both open source.

While I agree with you, and Use both those programs, as well as winscp. The problem is that windows servers do not natively support such things, so you have to install servers that are able to listen for sftp connections, or ssh connections, in most cases one has to pay for these services on a windows server. IIRC Filezilla has a ftp server, I just don't know how what protocols it supports.

That is the point... and one of the things that really bothers me about windows as a whole. You have to pay for the software, then you have to pay to secure it, then have to pay to re-secure it, then the next version comes out, and it is lather, rinse, repeat.

Re:What to replace ftp?

[tc3driver]

http://wiki.filezilla-project.org/FileZilla_FTP_Server Clearly states that it does not support SFTP.

Whaaaaaa!

[flajann]

Why the hell would ANYONE still be using FTP these days? I don't even allow its mere existence on my servers! sftp or scp is fine. Regular old FTP? This is NOT the 80's!

Re:Whaaaaaa!

[UnmaskParasites]

On many cheap hostings plans FTP is the only way to upload files.

Re:Whaaaaaa!

[Anonymous Coward]

Used *extensively* in industry as an easy way to transport files between organizations that are PGP encrypted.

Re:Whaaaaaa!

[suso]

And many of the cheap hosting plans if not 50% of the web hosting industry these days is run by people without a clue. They are run by business people looking for a quick buck. So they just buy a turnkey solution with cpanel or whatever else. None of them read Slashdot or any security websites and most of them could care less if they are insecure. All they care about is that they look good and that they have a pretty girl on the front of their site.

Even big ones like Dreamhost have no clue and are insecure as hell. I haven't updated it in a while and I've heard that Dreamhost fixed or obfuscated their flaws, but I wrote a list of vulnerabilities that Dreamhost has at http://suso.suso.org/xulu/Web_hosting_providers_with_poor_security

It's not just a windows issue

[phorm]

I don't know about Vista, but even if Linux was ever targeted for this kind of attack/spyware, you would have to run the software as root to enable packet sniffing!

As a service on the local machine perhaps, but thinking that Linux solves everything is a fairly head-in-the-sand approach in itself. There's always:

a) In-transit packet sniffing. Plenty of places between your PC and the destination server for your unencrypted traffic to be sniffed.

b) Local password caches: Plenty of users locally store their passwords for convenience. It's not impossible or even that difficult to pull them. The "wallets" may to some extent work to protect these, but an infected user account could still happily launch a background service that politely asks for the password at a convenient time

c) Config files: Local infected accounts can have local configuration files (firefox, etc) overwritten without the user knowing. Will you notice if your proxy is set to funky server for a few days?

d) Menu items, etc: When you click on the firefox icon, are you really running what you think? What if it's a wrapper with a 3rd-party app? OK, you run from commandline... is your $PATH set to run /usr/bin before "./.hiddenvirusdir/usr/bin" ?

There are PLENTY of ways to compromise a 'nix desktop without root access. Yes, windows is less secure in many ways, but 'nix is far from invulnerable, because at some point it all comes down to the fine balance between security an convenience. My former co-worker and I use to play what was essentially "security wars." We would find fun ways to get into each others systems and muck things up. In the process we learned how easy it is, and migrated some of our practises to the web.

Actually (d) was my favorite, as before I left he asked me "why is it when I sometimes start my firefox it still goes to mylittlepony.com" (or whatever it was I'd set). Other fun tricks include a .tar.bz in a convenience location, sourced when they load a particular app, to overwrite their SSH authorized_keys or some other fun files. Having the data compressed means that they can't grep for expected items

Yes, windows has issues. For the experienced, so does Linux. If fact, short of writing actual trojans or binaries, I generally managed to more easily subvert my friend's 'nix machine more often than our other co-workers windows box.

Re:It's not just a windows issue

[mangobrain]

a) In-transit packet sniffing. Plenty of places between your PC and the destination server for your unencrypted traffic to be sniffed.

Yes... as per the entire point of this article. :)

b) Local password caches: Plenty of users locally store their passwords for convenience. It's not impossible or even that difficult to pull them. The "wallets" may to some extent work to protect these, but an infected user account could still happily launch a background service that politely asks for the password at a convenient time

A semi-decent password wallet will prompt the user whenever a (new) application asks for a particular password. GNOME keyring does this, for example. I don't know how thoroughly it verifies that future requests come from the same program, though (e.g. authorise Evolution to read your mail account password, then replace the Evolution binary with something malicious). Regardless, you can't use this to *gain* access; such a "background service" would however be an interesting thing to put in place on a compromised box.

c) Config files: Local infected accounts can have local configuration files (firefox, etc) overwritten without the user knowing. Will you notice if your proxy is set to funky server for a few days?

How does the account become infected? Once you have control, you can do anything that user can do; but if you don't have write access to those configuration files, this point is moot.

d) Menu items, etc: When you click on the firefox icon, are you really running what you think? What if it's a wrapper with a 3rd-party app? OK, you run from commandline... is your $PATH set to run /usr/bin before "./.hiddenvirusdir/usr/bin" ?

An interesting one, but the whole menu item issue (I remember the furore a while back) isn't really any worse than the stuff you can do on the command line - which you already seem to be aware of. :) Again, though - if you don't have access to edit system-wide .desktop files/login scripts, or write access to a user's home area, this is just describing the ends without hinting at the means.

There are PLENTY of ways to compromise a 'nix desktop without root access.

Maybe, but you haven't detailed any yet. All the stuff you're talking about - with the exception of your point A - is stuff you can do *after you've already compromised the target account*.

Yes, windows has issues. For the experienced, so does Linux. If fact, short of writing actual trojans or binaries, I generally managed to more easily subvert my friend's 'nix machine more often than our other co-workers windows box.

I really do have to ask: how? Did you use common root passwords? Home areas on NFS without root-squash? Leaving logged-on boxes unattended for long periods of time without passworded screensavers? Booting each other's machines into single-user mode/with Knoppix in the drive/etc.? Without physical access (which I have to admit is *very* difficult to protect against - but not OS specific), the things you're describing ought to be incredibly difficult to accomplish on a properly set-up Linux desktop.

The solution is so simple, yet people are too dumb

[Anonymous Coward]

The solution is so simple, yet people are too dumb to do anything about it properly.

1.) Use OpenBSD's OpenSSH suite for SFTP (not FTPS crap) - be it in OpenBSD, FreeBSD, Linux or even Windows, etc.

2.) For windows clients, there's WinSCP or FileZilla (or PSCP or PSFTP from PuTTY) + PuTTY, PageNT, PuTTYgen,
The trick here to avoid passwords being logged with keyloggers, sniffed, etc. hence, the use of public / private key pairs and an SSH-Agent such.

3.) For *BSD UNIX and Linux systems (and others), there's the OpenSSH suite + ssh-agent(1).

Anonymous, chroot'ed SFTP only accounts and/or chroot'd user accounts are extremely simply to set up and use. Head over to openbsd.org and read the FAQ and man pages.

Enjoy!

Short and sweet summary

[Anonymous Coward]

1. Protect your computer from malware or your FTP credentials could be swiped. Then they will post junk on your web site.

2. Use FTPS, FTPES, or SFTP instead of straight FTP. It protects you from most or all FTP-credential-swiping malware.

FTPS, SFTP, FTP over SSH, ...

[rabun_bike]

Good lord.

FTPS = FTP over SSL or TLS
SFTP = Totally different protocol from FTP and is unique unto itself. Bears no resemblance to FTP protocol except you are moving files to and from.
FTP over SSH = FTP over SSH where the FTP commands are tunneled inside an SSH session.


FTPS still uses passive ports to push data but FTPS client has to negotiate yet another TLS handshake which means you or the FTPS client has to re-authenticate or chain up the certificate every time a passive port is open. If your firewall allows clients to make passive connections to your FTP server then FTPS will work just fine. From the clients perspective, passive connections are the way to go since the client originates all connections to the server.

There are two modes of operation for FTPS - explicit and implicit. Implicit is weak because you can send you username and password in clear and then secure the connection. It should even be supported by FTPS clients but it is for legacy purposes. Explicit FTPS means right when the FTP connection is made from the client to the server, a TLS handshake and connection is created and then your credentials are passed in. All communications after the AUTH TLS command are secured within the TLS protocol.

There is a LOT of confusion when talking about FTP, SFTP, FTPS, FTP over SSH, or FTP over X.

http://en.wikipedia.org/wiki/FTPS
http://en.wikipedia.org/wiki/File_Transfer_Protocol

Re:FTPS, SFTP, FTP over SSH, ...

[Alun Jones]

As you say, a lot of confusion - and you've just added to it.

FTPS doesn't have to do a full TLS handshake on the data port - it reuses the SSL session that was negotiated on the control channel.

There are better ways for FTPS to do data connections than PORT and PASV, and I'm in the middle of a series of notes on my blog http://msmvps.com/blogs/alunj that will culminate in describing the best way to handle data connections for modern FTP.

You have confused Implicit and explicit FTPS. Implicit SSL is where the SSL session is established immediately after making the connection; Explicit SSL is where a command is sent to elevate the connection to SSL. Having said that, the weakness you propose as a problem for Explicit SSL is not the problem you think it to be - FTP clients and servers that support FTPS generally have options to refuse to authenticate outside of an SSL session. Good thing too, because the AUTH TLS command forces a logout of any previously authenticated user session within the FTP connection.

Implicit SSL is deprecated in the FTPS standard.

Finally, a late addition to the FTPS standard was to add the CCC command, which keeps the user's session active, and closes the SSL session on the control connection, so that a NAT or other ALG can look for PORT and PASV commands to open up temporary firewall holes for data connections. I'm not sure that I think that's a great idea.

Re:FTPS, SFTP, FTP over SSH, ...

[rabun_bike]

And now you have confused people even more. First, implicit FTPS is deprecated. Explicit FTPS is what is being used and implemented. It is what is described RFC 4217. It is what I used in my open source FTPS library and client. Works great.

http://www.ietf.org/rfc/rfc4217.txt

Need more: read here. http://en.wikipedia.org/wiki/FTPS#Methods_of_Invoking

http://www.rebex.net/secure-ftp.net/

It is so confusing I get confused and I have implemented these protocols. The mistake I made in my earlier post was referring to implicit FTPS as the the other mode of explicit FTPS where the user is allowed to turn the tunnel on and off. That is actually referred to as a name which escapes me.

http://www.rebex.net/secure-ftp.net/

Second, for every passive connection you most certainly have to handshake that connection. Certs are passed on the connection and the tunnel is set up each time a file is transferred. It might appear to you as a user of an FTPS client that isn't happening but I assure you it is.

So get off you high horse my little MVP friend and do some implementations and less blogging.

stupidity is a constant

[circletimessquare]

it does not go up or down

nor are you immune to it yourself

the idea is indeed to technologically minimize the impact of typical human stupidity

the technology we are talking about here, ftp, the internet, etc, is very much still in its infancy

for you to suggest the technology need not change, and everyone else suddenly become highly technically qualified and proficient, AND become miraculously immune to basic human foibles is quite ridiculous. the article this thread lies under describes a highly knowledgeable user still becoming a victim. do you really wish to assert that the solution to these problems is everyone using a computer become a security expert somehow on the order of six figure technicians working for international banks?

please, get real

Suggestion: Just Deal with those who get hit

[Anonymous Coward]

Nice Article. I wonder about a strategy for Hosting Providers that changes to SFTP for just those sites that are affected. Those people who do a poor job of protecting their own pc's should be the ones who you work at minimizing the problem. I don't know if both FTP and SFTP can be supported for the same server, but I would think that they can.

MS ships FTPS server with Windows Server 2008

[Anonymous Coward]

Not sure about the client, but for well over a year now, MS ships an FTPS server with Windows Server 2008. Of course, you said SFTP (SSH FTP), not FTPS (SSL FTP), so maybe that's not good enough.

People are slow to adapt...

[Bert64]

As someone else pointed out, getting infected with a piece of malware is extremely serious... Not something you can run some automated tool to "clean up"...
Most of the malware i've seen is not just a single infection, it tries to install additional malware too (to decrease the chance of you finding it all, nothing detects every piece of malware) and will often change system configuration to make it intentionally insecure, because none of the anti malware tools will detect if you have a legitimate but old (ie vulnerable) system binary installed, or if you have an insecure configuration such as allowing activex controls to run automatically without prompting. What you need to do is restore the system from known clean media and manually verify any data files you copy back (don't copy back any executable binaries).

Another issue with public shared hosting, is that often the web server runs as a single user, so that all the different sites need to be readable by that user. If one site gets compromised and an attacker gets a shell as the web server user they can read and possibly modify every other user's files... Quite often this will be enough to retrieve database passwords if not more.

Also consider the popular website authoring tools people use, which usually default to FTP and often don't support anything else. If your webhost doesn't support FTP you will lose customers.

FTP pros and cons

[Anonymous Coward]

FTP is insecure and shouldn't be used, generally, when there is a password at stake. However, FTP also makes for a very easy and light way to share files to a large group. It's sort of the lowest common demoninator of file transfers. FTP isn't going anywhere, because it's still very useful and resource light compared to other protocols. Which is why companies like HP and Dell use FTP servers to serve up drivers and other software.

lack of sftp server software

[Cronq]

In my practice setting up sftp server is a problem due to lack of sftp server software. Yes, there is openssh based sftp server which can do almost nothing.

No sql, no non filesystem quotas, no virtual fs etc.

If there were something like pureftpd or vsftpd supporting sftp...

Re:lack of sftp server software

[Culture20]

In my practice setting up sftp server is a problem due to lack of sftp server software. Yes, there is openssh based sftp server which can do almost nothing.
No sql, no non filesystem quotas, no virtual fs etc.

My chocolate ice cream didn't come with pickles for my sandwich either. See, I can make ridiculous requirements too. Why would SFTP provide SQL, quotas, virtual filesystems? It's a &@$^!* %$# secure file transfer protocol, not your mother.

Re:lack of sftp server software

[Cronq]

Not sftp. sftp _server software_. Why? Because it's useful to have and use. Just like in ftp servers - pureftpd, vsftpd, proftpd - all these have much more features than just pure/stupid file serving.

Re:lack of sftp server software

[Culture20]

I'm totally flabbergasted. Those things do not belong in sshd. Hell, they don't belong in ftpd.

Re:lack of sftp server software

[Cronq]

The reality is different.

But

[RomulusNR]

h0w 4m 3y3 g01ng 2 g3t 4ll my w4r3z mp3z and pr0n n0w?

Look at it another way...

[benjfowler]

The other side of the coin is the lawlessness and lack of enforcement of anti-computer crime laws. This is all as much a social, political and legal problem as a technical one.

It's no secret that much of the crime happening online comes from Eastern Europe (particularly, Russia, Ukraine, Romania, Bulgaria), and China. Russia and China in particular, are rabidly anti-West in their outlook. The governments over there think it's funny and cool for legions of bored and greedy kids to rob people and destroy other people's property, so long as they're not Slavs/Chinese.

Of course, the problem is going to get so bad, that the entire generation of criminals they're incubating will start attacking their own countries; but in the meantime, we have what is basically a law enforcement problem (clueless law enforcement), caused by a political problem (clueless and/or hostile foreign governments).

Believe me, if the Russian kids robbing people on the Internet today were actually made to face the consequences of their actions (e.g. chopping trees and dying of AIDS and TB somewhere in Siberia), the problem wouldn't be anywhere near as bad.

Fine display of judgement

[Anonymous Coward]

The original file with the script tags inserted is here if you want to examine it, but use with caution

Do you also send virus emails to your addressbook so people can examine them? Your site is still blacklisted, and that's a good thing.

Breaking out of chroot for a non root user

[Anonymous Coward]

Second, every single security "problem" with chroot is based on the root user breaking out. Non-root users cannot break out of a chroot'ed environment. It therefore does add some additional security.

Surely you jest!
It is possible! Ever heard about local root exploits? Just ask the OpenBSD guys, they remember this one.

Re:Breaking out of chroot for a non root user

[SanityInAnarchy]

Of course, if you're smashing the stack, I'm going to trust the kernel over the FTP server any day.

Re:Breaking out of chroot for a non root user

[mzs]

I forgot how good of an article that was, these were fixed in OpenBSD 3.1, they are errata 014 and 015.

http://www.openbsd.org/errata31.html

What are the best practices?

[tepples]

Then you don't know how to use SSH properly. You need to obtain the public key beforehand

Are there any recognized best practices for SSH public key distribution?

Re:What are the best practices?

[WuphonsReach]

Are there any recognized best practices for SSH public key distribution?

Typically, you don't distribute the key itself, but rather the fingerprint. The important thing is that the fingerprint needs to be distributed over a channel not compromised by an attacker. So via email, or posted on a bulletin board, or passed around in a memo, or posted on a message board, or website.

The methods for verifying a SSH host public key are the same as verifying a GPG/PGP public key. It's just that SSH hosts don't have that whole web of trust thing going that GPG/PGP keys have. So you might find best practices by searching for verification of GPG or PGP keys (such as key signing parties).

Re:What are the best practices?

[tepples]

The important thing is that the fingerprint needs to be distributed over a channel not compromised by an attacker. So via email

Antivirus software routinely installs e-mail proxies, so why can't malware?

or posted on a message board, or website.

In order to make sure that an HTTP connection doesn't get compromised, you need HTTPS, and that goes back to SSL certificates ($99/yr).

So you might find best practices by searching for verification of GPG or PGP keys (such as key signing parties).

As I understand it, a web of trust model involving key signing parties doesn't scale unless there's a sufficiently large strongly connected core of people, some of whom travel both internationally and to your home town.

Re:Using ports smartly

[cppmonkey]

Once upon a time ftp's port usage made a twisted kind of sense but I agree it is time to take old FTP out behind the woodshed and put her down if just for this reason.

Seriously people use anything but ssh/scp/sftp???

[nedlohs]

Using a key-pair is *so* much easier than remembering 47 different passwords I'm amazed people use anything else.

Re:FTP should be going away for just this reason

[cppmonkey]

Have you tried tunneling ftp with it's bizarre two port usage? Tunneling is harder than the average bear can comprehend to begin with but tunneling two ports is silly. sftp which is not just a tunnel is a better way of handling file transfers kinda like a prius is better than a K car.

Re:FTPS (breaks load-balancers and firewalls)

[toejam13]

One major issue with FTP over SSL/TLS is that network address translation (NAT) devices, such as firewalls and load-balancers, that eavesdrop on the FTP control channel in order to open dynamic data ports fail hard with FTPS.

If you use "explicit mode" FTPS, the client negotiates up to FTPS via a standard port 21 connection. After secure authentication, they can issue a 'CCC' (clear control channel) command which backs the control channel back to a NAT compatible mode. Problem is, this is a client side option. It cannot be pushed by the server. So, it is yet another thing that users must be educated over.

If you use "implicit mode" FTPS, which runs up on port 990, negotiation is not an option. You're immediately forced into crypto mode, and you cannot back out either the control or data channel. "Implicit mode" FTPS is incompatible with NAT devices unless you do some seriously nasty hacks.

In my opinion, SFTP (the file transfer subsystem of SSH) is a much better protocol. It does not utilize dynamic ports, and it doesn't involve callbacks (like active FTP) that make firewall rule management a PITA.

Re:WebDav vs SSHFS benchmarks

[psyclone]

Well, here are some benchmarks:

http://jamiew.tumblr.com/post/382844/macfuse-sshfs-vs-webdav-benchmarks

Obviously blocksize makes a difference.

A simple test you can perform: time the copy of a large file over WebDav via HTTPS vs an SCP transfer using the same client+host. (Beware using putty or filezilla on windows as it's slow; at least compared to scp from linux to linux)

WebDav makes sense for subversion as it's built that way, so your other repository users will expect it. But for a plain remote file system, webdav may not be the best for you.

what I do

[Anonymous Coward]

Being a sys admin for a hosting company (a medium sized one), here are some suggestions.

1. FTP passwords - 10 characters, numbers, letters, capitalization, changed every 90 days. I don't use FTP for uploading content, though. :)
2. SCP for uploading files. Can be used with Windows and Linux hosting, using generally much more secure SSH. Also move SSH to a different port (won't stop major scanners, but will keep most script-kiddies off your box).
3. File Permissions. Make sure they are set correctly. i've fixed more Linux boxes with incorrect permissions than I care to count. 755 on directories, 644 on files. Some CMS screw this up, so watch for it.
4. Disable local mail relaying from your boxes. Make all web forms use PHP PEAR to authenticate to a SMTP server to send out mail. Some yahoo that doesn't know how to program a php mail script can cause some major problems.

If not FTP, then what for resumes support?

[antdude]

I recalled SFTP can't do resume downloads and uploads when I last tried it, years ago. So I use good old Z-modem's sz and rz commands through SSH(1-2) connections with SecureCRT clients (wished PuTTY could do it and SyncTERM's Z-modem seems to be broken [never worked correctly]). FTP can do resumes too, but obviously insecured. Are there any other popular/common protocols that will transfers, with resume support, securedly on various platforms (Apple Mac, Windows, and Linux/UNIX)?

Re:If not FTP, then what for resumes support?

[squidinkcalligraphy]

I've been grappling with the same problem of late.

FTPS (FTP over SSL/TLS) seems to be the answer.

WebDAV should in theory support resumable transfers (I think), but is dependent on the client to support this.

Re:If not FTP, then what for resumes support?

[antdude]

Hmm, I guess we will have to FTP via SSH proxy. :(

Re:If not FTP, then what for resumes support?

[squidinkcalligraphy]

why not FTPS? A lot of clients (at least the popular filezilla, and cyberduck) support it; it's just FTP over an SSL connection, just like HTTPS is HTTP over an SSL connection.

Not sure what server support is like, but I'm sure there'd be a good few around...

Re:If not FTP, then what for resumes support?

[antdude]

That's the problem. I haven't seen any FTP servers using secure.

Been trying to switch users for years

[suso]

I'm the founder and main admin of a web hosting company and we've been trying to switch people to SSH/SFTP/SCP for many years. We even put an ultimatum on FTP users back in 2006 that by the end of the year, we'd be turning off FTP. You know what happened? Users backlashed and complained that their old antiquated website software like old versions of Dreamweaver or whatever couldn't do SFTP or SCP even though versions that did had been available for a few years. Also, people who came from other hosting companies too us didn't know about more secure protocols and complained when they had to switch away from their old programs that they liked, even if WinSCP works great. So in the interest of keeping customers, we had to leave it on. We've been pushing SSH since the 90s. And I wrote the # 1 ranked SSH tutorial on the net. So how do you think I feel? Its a really annoying problem and it may take several more years before it completely goes away.

On the other hand, there is one thing that I haven't seen available with SSH and that's the ability to have virtual users and let them be created by the parent user. Maybe there is a trick to make it possible in SCP/SFTP, but there are customers out there who need the ability to have sub users who manage parts of their site and so on. Many FTP servers allow this, but SSH does not. So this is another FTP feature that keeps it going.

And while I'm griping about it, it REALLY doesn't help the situation that WinSCP started supporting FTP.

Re:Been trying to switch users for years

[Anonymous Coward]

Maybe a way to combat this will be for you to NOT support FTP to any new customers. On your main website you may need to remove any mention of FTP and instead mention the other protocols instead. That way you keep your old customers happy but all your new ones secured. Heck, you can make a small campaign out of it, proclaiming what percentage of your customers are now safer... via email to your customers. That will spark some interest in your old base, at least the less informed ones.

Re:Been trying to switch users for years

[Knara]

Maybe a way to combat this will be for you to NOT support FTP to any new customers. On your main website you may need to remove any mention of FTP and instead mention the other protocols instead. That way you keep your old customers happy but all your new ones secured. Heck, you can make a small campaign out of it, proclaiming what percentage of your customers are now safer... via email to your customers. That will spark some interest in your old base, at least the less informed ones.

This, right here, is not a bad idea.

Phasing support out can, over time, really work well.

Just make sure you don't have the account renewal system put them into a state where suddenly existing users can't use FTP again, or you'll be hurtin.

Re:Been trying to switch users for years

[x2A]

Tunnelier is rather good, includes an FTP bridge. Connect to your ssh server, and it listens on localhost for ftp commands, translates and sends them to your server over ssh. Not only means encryption, but also compression (something I often care more about). Will sit in your system tray and auto reconnect if connection drops, and enable all old ftp-only software to talk to an ssh only server. I talk to everything over it, mysql, imap/smtp, even web traffic can be sped up.

Re:Been trying to switch users for years

[suso]

Unfortunately, it doesn't work that way and I already tried that. A few years ago we added a new shared server to the mix, I left FTP off and anyone who asked I told them about SSH/SCP/SFTP, why its better and encouraged them to use WinSCP or a Mac equivalent. As I mentioned before, some people used special programs that didn't have SFTP support or whatever and wouldn't make the switch, they would just cancel their service and go elsewhere.

Its hard to hold your values when hosting providers are a dime a dozen and people would rather go somewhere else where there are no restrictions than put up with good security practices. Some people do stay and appreciate it, but many don't.

Ironically, my fortune cookie from last night at the local Chinese buffet said "If you do what is right in business, money will come to you" or something like that.

Re:Been trying to switch users for years

[^me^]

ftp over ssl can do virtual users. (as opposed to sftp, which is ftp over ssh)

Symlink problem

[Antique Geekmeister]

SFTP and SCP do not properly handle symlinks. It only takes one smart-aleck upstream to create a symlink, by any means, and make your SCP or SFTP duplication go _insane_. FTP could at least report these and attempt to handle them properly. Frankly, I prefer rsync over SSH and even WebDAV over HTTPS: WebDAV over HTTPS is built into Microsoft's 'Network Neightborhood' and allows direct cut&paste operations. It's also the underlying technology of Subversion's HTTP access, so it gets some attention to functionality and regular bugreports.

Re:Using ports smartly

[socsoc]

Just like it's time to deprecate the teletype monospaced tag out behind the woodshed and put her down if just for this reason.

Re:Seriously people use anything but ssh/scp/sftp?

[rgviza]

Most people don't know How-To use key authentication :-p

horray for SFTP! :)

[Anonymous Coward]

horray for SFTP! :)

Re:FTP should be going away for just this reason

[socsoc]

Have you tried not using the visual abortion that is tt ?

WebDAV? FTP over SSL/TLS?

[stefanlasiewski]

Have many groups looked at WebSAV or FTPS (FTP over SSL/TLS) as a replacement for FTP?

1. Encrypted communication, using the industry standard TLS or SSL.
2. WebDAV offers the power and maturity of Apache HTTPD. I believe that several of the mature FTP packages also support FTPS.
3. Apache authentication options include Radius, LDAP, etc. and are generally easy to install, provided you have the infrastructure.

I still mostly use SFTP. However, the design of FTPS looks a little more elegant and standards-compliant.

Re:WebDAV? FTP over SSL/TLS?

[daybot]

Have many groups looked at WebSAV or FTPS (FTP over SSL/TLS) as a replacement for FTP?

Just set this up on an Amazon EC2 host for a customer. It works nicely, but you have to set some non-default options in some FTP clients in addition to enabling TLS, so your instructions to the customer are now a long way from "Use your favourite FTP client to connect to ftp.foo.com, port 21, user foo, password bar".

Re:WebDAV? FTP over SSL/TLS?

[stefanlasiewski]

This is for my staff, and it needs to be on the local network for a variety of reasons.

In my case, we can influence the choice of software clients.

Re:WebDAV? FTP over SSL/TLS?

[daybot]

The only downside I see, then, is that whichever client you use, there are still more options you have to set and therefore more scope for users to get the configuration wrong.

I'm using pure-ftpd on Debian and it took me less than 30 minutes to get FTPS working. There are plenty of howtos around - but I mainly used the pure-ftpd documentation. We use the FileZilla client on all platforms.

This is what you get when it's working...

Status: Connection established, waiting for welcome message...
Response: 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Response: 220-You are user number 1 of 50 allowed.
Response: 220-Local time is now 23:20. Server port: 21.
Response: 220-This is a private system - No anonymous login
Response: 220-IPv6 connections are also welcome on this server.
Response: 220 You will be disconnected after 15 minutes of inactivity.
Command: AUTH TLS
Response: 234 AUTH TLS OK.
Status: Initializing TLS...
Status: Verifying certificate...
Command: USER **************
Status: TLS/SSL connection established.

usatoady

[doti]

Speak for yourself. I'm not a toady!

I like your arguement right up to the very last

[DRAGONWEEZEL]

sentence.

Even if you don't believe in Santa Claus - is it going to really cause you that much hassle to leave a couple of cookies and a glass of milk out on Christmas Eve just in case?

Is fools logic. It's how salesmen made killings. Let me explain. If you spend time doing something, and have 0 gains, you actually have negative gains because you wasted your time. If you had to milk a cow and bake the cookies, your time might be better spent on something else.

For a recent verizon issue I had,
Upgrade early, and there's a $20 fee, you loose the $100 every two bonus (it restarts from time of upgrade) And you pay the current contract price for the phone. Looking at a $79 phone for the wife & I (one account is eligable, the other is not) What is the cost of upgrading the phone? if you thinkn the "real" cost is $99 you'd be forgetting the $100 bonus you'd get in 2 months.

So the real cost is 2 months to wait for a new phone and 0 upgrade costs, or get the phone right now and spend $200 (100 "real" dollars, and a guaranteed $100 should you wait) If you feel it's worth $100 a month to have a state of the art phone, great for you, but I'm not so sold, and thus I don't care. I'll wait as my income means more to me than that, but that is an exercise for the person in that position. If you're phones broke, what choices do you have?

While the risk is REAL and has value to switch from FTP to SFTP etc... the people who make those decisions have to do a risk/benefit analysis. Small companies won't come out on top (in favor of a switch)as far as security is concerned unless they get hacked 10 times in a row. It's just not economical for them, and so I'm all for setting it to default for all new users, then posting a bulletin to all your customers, along w/ an e-mail and written letter explaining why you did this.

In a some-ways-similar situation, my bank alerted me that a major credit card company had ben compromised and my credit card was on their list. They said you should take this time to change your card. I figured, well, I monitor my account really well, have purchases text me, etc... so I didn't really wory, and felt I may be in a rare position to help authorities catch the criminals. 3 months later, they sent me a letter and changed it anyway, they didn't want the risk.

Re:J.T.P.

[FutureDomain]

Anonymous Coward Transfer Protocol - let's just say it involves anonymous cowards, Slashdot posts, and /dev/null.
There, fixed that for ya!

Forest for the trees...

[dr00g911]

Do I get a medal for reading that thing?

At any rate, railing against FTP is kinda quaint seeing as how there are lots and lots of other ways to intercept the data if you've been pwned.

If you've got a keylogger (or registry scraping malware in the case of Win), it doesn't matter if you're got some outlandish quantum encryption link between machines.

The real story here is:

- Wordpress is insecure, news at 11. Lots of injection attacks happen, interestingly they're disproportionately successful on newer versions of Wordpress.
- Substitute "Wordpress" for your favorite off the shelf blog/forum/cms script.
- If you're on a shared hosting plan and one box/instance/etc at the facility has been pwned, it's likely able to capture data going to other machines/VMs on the same subnet, particularly if you're using a ghetto-tastic shared Win server (there are no other kinds... all shared Win-based hosts suck ass on all fronts due to incompetent administration and terrible cpanels).
- If your workstation has been pwned, your FTP passwords are the least of your concerns. Trust me.

I mean, it's nice that the author decided that the world needs a little bit of edumacation, but the big picture is more important than "FTP bad"

Probably not ftp's fault

[CoffeePlease]

More like you were attacked through one of the many http or sql injection attacks that are constantly being run out there. Which is not to say you aren't right - everything else uses encryption so why not FTP?

Sometimes you don't have physical access

[tepples]

But how can you be sure that your first connection was without a MITM?

Usually, because I'm actually physically right next to the machine.

But in a lot of cases where SSH would appear useful, you don't have convenient physical access to the machine. Say you're renting a virtual dedicated server from Go Daddy.[1] Now you probably don't have the money to fly to Go Daddy's datacenter to be right next to a server to which you're trying to connect, nor do you have the money for an international phone call to have the owner read you the key fingerprint over the Plain Old Telephone Service.

In general, I'm working with probability. The fact that I've never had the "somebody nasty" message unexpectedly (that is, when I didn't just reformat or replace a machine), even when I move the same laptop from home, to work, to the airport, and back home, means it would take a truly massive network of people intercepting my packets at every turn, or I'd have at least detected it at some point.

In a lot of cases, the person renting space on a server never connects to the server except from a single connection at home or from a single connection at work.

[1] Replace with another hosting provider.

Re:Sometimes you don't have physical access

[SanityInAnarchy]

But in a lot of cases where SSH would appear useful, you don't have convenient physical access to the machine. Say you're renting a virtual dedicated server from Go Daddy

That's true, and a good point. Although so is your footnote:

Replace with another hosting provider.

Yes, you should.

So, a decent hosting provider would give you that information, or at least some sort of AJAX console, over HTTPS. That means you now only have to worry about guys like VeriSign (or your OS provider) screwing you over.

Re:Seriously people use anything but ssh/scp/sftp?

[IBBoard]

Stealing a key-pair is *so* much easier than stealing 47 different passwords I'm amazed people use anything else.

There, fixed that for you ;)

(Yes, you can put a pass-phrase on your key-pair, but then you're still either at the point of having one password for everything or having 47 key-pairs and 47 passwords ;) )

Why are people still on FTP - Firewalls, perhaps?

[IBBoard]

Maybe people still use FTP rather than SFTP because of firewalls. At work we've got a firewall that blocks all unexpected ports and even does a degree of protocol checking on the expected ports. We're allowed to use the Net for personal use at lunch etc, and we have a proxy for FTP that lets use get at FTP servers, but anything encrypted like SSH/SFTP is right out.

It's probably not just the old legacy apps that don't support the protocols (which people will keep on using once they've bought them if they're expensive for the new ones and it isn't a commercial site) and a lack of knowledge, but sometimes it'll be technical limitations as well. FTP is a nice common denominator that people can rely on more than encrypted stuff.

Demise greatly exagerated

[ebvwfbw]

Yet another dumb death announcement. FTP will be here for years to come, probably long after anyone reading this right now has passed on. Want to announce a death? How about twitter. Only a twit uses twitter. You don't want to be a twit do you?

re: CompleteFTP

[King_TJ]

I didn't know about CompleteFTP before. Just looked at the web site. It sounds pretty full-featured, but I'm not so impressed by the pricing.

$299 for a single sever "professional" license, I could swallow, IF it included unlimited free updates for the life of the product or something. But that "1 year support + updates" thing doesn't do much for me.

I realize it's far cheaper than Serv-U (which wants something like $1000 for an equivalent-featured product with 1 year of support). But that pricing is WAY out of line, IMHO.

You guys selling these Windows FTP servers aren't so much competing against each other, as you are, competing against my cost of putting together a free Linux or BSD server solution instead.

The longer I use one of your product, the more costly it becomes, if "support" has to be constantly re-purchased.... That heavily tilts the value equation towards Linux or BSD.

Re:Seriously people use anything but ssh/scp/sftp?

[nedlohs]

It isn't easier.

If I had to remember 47 password they would either be so simple that you wouldn't have to steal them. Or there would really only be 3 unique ones. Or they'd all be stored on the computer anyway.

So stealing that one pass phrase and key isn't any easier than stealing 47 passwords.

Plus the advantage that the admin on one of those machine can't tweak the login/passwd/whatever commands and collect a password that will work on some of those other 46 machines.

Re:Why are people still on FTP - Firewalls, perhap

[squidinkcalligraphy]

If your proxy supports https connections, you have ssh access. You might need to run an ssh server on port 443 depending on how tight the proxy is, but most ssh clients now support using an https proxy for connections - basically they just have to issue a 'CONNECT server:port' command to the proxy, and they have a clean line.

Re:Why are people still on FTP - Firewalls, perhap

[IBBoard]

Unless the bit where they seem to do some kind of protocol sniffing and make sure that HTTP traffic is HTTP traffic gets in the way (so we can't check out SVN over HTTP because it rejects some commands it needs for not being POST or GET). The main corporate network also intercepts HTTPS and accesses the site for you, returning content using its own certificate (if the site is approved), although it doesn't seem to do that on our developer network.

Another link to preventing this type of attack.

[Anonymous Coward]

Here is another Blog Post on steps to prevent this type of attack. http://blog.igothacked.com/2009/06/steps-to-prevent-gumblar-martuz-nine.html

Re:Why are people still on FTP - Firewalls, perhap

[squidinkcalligraphy]

A corporate network that intercepts HTTPS traffic breaks HTTPS. The whole point of HTTPS is that it is encrypted point-to-point. If that were the case the browser should be popping up warnings all over the place, since what you have described is the definition of a man-in-the-middle attack.

Re:Why are people still on FTP - Firewalls, perhap

[IBBoard]

Not when it is a corporate network, they have their own certificate installed in your browser as "auto-approved", and all communication is re-encrypted using that certificate (and so looks like HTTPS) by the proxy server. Yes, it is a MITM attack, but if your certificate is installed and says it is valid for all domains then no browser will complain.