Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!


CmdrTaco posted more than 5 years ago | from the and-good-riddance-to-ye dept.


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 "" and "", 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 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:

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 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 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 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 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.

cancel ×


Sorry! There are no comments related to the filter you selected.

All you need to know: (5, Insightful)

Godeke (32895) | more than 5 years ago | (#28676899)

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: (5, Insightful)

Phroggy (441) | more than 5 years ago | (#28678029)

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?

Back we go then... (5, Funny)

Canazza (1428553) | more than 5 years ago | (#28676937)

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

RIPFTP! (5, Funny)

SteveHeadroom (13143) | more than 5 years ago | (#28676957)

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

Re:RIPFTP! (0, Offtopic)

Kral_Blbec (1201285) | more than 5 years ago | (#28677061)


There fixed it for ya

Hmm (1, Funny)

Anonymous Coward | more than 5 years ago | (#28676987)

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

Amusingly.. (1)

grasshoppa (657393) | more than 5 years ago | (#28676989)

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.. (4, Insightful)

Archangel Michael (180766) | more than 5 years ago | (#28677215)

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

Re:Amusingly.. (0, Troll)

Cheech Wizard (698728) | more than 5 years ago | (#28677375)

Then they should have someone knowledgeable manage it for them.

Paper tape of course (5, Funny)

davidwr (791652) | more than 5 years ago | (#28677403)

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

Re:Amusingly.. (2, Insightful)

maxume (22995) | more than 5 years ago | (#28677719)

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.. (4, Informative)

Mr. Slippery (47854) | more than 5 years ago | (#28678161)

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.. (1)

grasshoppa (657393) | more than 5 years ago | (#28677761)

scp would be my protocol of choice.

Re:Amusingly.. (1)

shadowknot (853491) | more than 5 years ago | (#28677765)

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.. (4, Informative)

ThePhilips (752041) | more than 5 years ago | (#28678017)

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.. (4, Informative)

Hatta (162192) | more than 5 years ago | (#28677877)


FTP is dead; long live FTP! (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28676993)

Every few months, the Mac web is bombarded with open pleas [] to Apple [] , askingnay, demandingthat Apple swap out the Mach [] -based kernel that Mac OS X [] runs on, XNU/Darwin [] , with Linux. This, of course, ends in with Apple stoically continuing development of XNU/Darwin while fanboys dry their eyes and limp home after their flamewars. The cycle then repeats itself again a few months later like clockwork. The truth of the matter, however, is that Apple will never replace XNU/Darwin with Linux.

Tearing XNU/Darwin out from OS X and replacing it with Linux would be winding the clock back almost twenty-five years. Mach, which comprises a large percentage of XNU/Darwin's XNU kernel [] , was a microkernel research project developed at Carnegie-Mellon University [] in the Eighties, overseen by Avie Tevanian, who usually worked on it while playing Depeche Mode [] and Tears For Fears [] and ushered it through various revisions at NeXT and, ultimately, Apple [] .

This continuity of development has given Apple a tight integration between the kernel, libraries, utilities, and higher-level frameworks. Linux would throw that synergy right out the window, making Apple dependent on an entirely unregulated development team [] , and forcing Apple to play catch-up with their specific needs after every major upgrade to Linux. Apple would have to hire Linus Torvalds in order to recreate the creator/creation dynamic they have now. And as Linus has stated several times, he'll never go work for a company doing Linux.

Perhaps one reason Linux users bleat so unceasingly for Apple to switch kernels stems from a pre-NeXT project the company ran called MkLinux [] . MkLinux was a version of Mach running Linux as a process. The project was sponsored by both Apple and OSF/1 and ran on Apple's first generation Power Macs and some early second-generation Power Macs. Performance was about 20% less than a native Linux would have been, but that wasn't the point; Apple was looking at different ways to create a modern operating system in the dark times of Copland before NeXT was even a gleam in their eyes.

After Apple's operating system woes came to a head in 1997, MkLinux was all but forgotten by everyone except the long-time Apple engineers tasked with updating OPENSTEP alongside their NeXT counterparts. It was a non-starter, but it was the first taste of Linux anywhere near a Mac; it would be years later that Linux/PPC or the swatch of PowerPC versions of more popular distributions like Debian, Fedora, SUSE, and YellowDog came to Apple motherboards.

"But wait!" whine the Linux zealots, "Apple uses the BSD kernel in Mac OS X, and that's not under their control!" And so it is not. But the portions of the FreeBSD [] kernel are only used to fill out Mach, and as such does not constitute a significant portion of the kernel. In fact, Apple's use of BSD code is so minute that it amounts to being a charity project [] that allows Apple a way of keeping FreeBSD solvent [] . So Apple is simply not using the FreeBSD kernel, and asking to replace XNU with the Linux kernel is therefore asking something disproportionate to reality and wrong. It completely misses the point, just like Linux itself.

Alongside calls of kernel replacement, Linux zealots often ask for Apple to use the GNU [] userland. In the beginning of Mac OS X's life, Apple used utilities from FreeBSD, NetBSD [] and OpenBSD [] instead of Linux, which was a smart move. For one, with BSD, Apple can take what they want, modify it, and ship without worrying about anything else. That's the glory of the BSD license [] . It's hands-off and lets you use the code as you see fit unrestrained.

In contrast, the GPL [] is viral in nature and ties the hands of the developers to a process that dictates distribution of source code with the binaries. You know how Snow Leopard is going to weigh five gigs instead of Leopard's eleven? We'd be talking dozens of gigabytes today if Apple used GNU. Proponents of the GPL may argue that the GPL ensures a flow of new code back into the community, but it's really just a burden to the developer.

Another reason Apple favored BSD over Linux was standardization. Most commercial Unices are genetically related to BSD in some way. For instance, Sun's Unix, Solaris [] , is a hybrid of System 5 Release 4 and BSD, while IBM's Unix, AIX [] , is based firmly on BSD4. The same goes for Hewlett-Packard's HP-UX [] and Tru64 UNIX [] , SGI's IRIX [] , and SCO Group's SCO OpenServer [] and SCO UnixWare [] . These Unices represent over 97% of the current Unix market, which shows that the BSD family is stronger and more established than SVR4 or the myriad of incompatible Linux distribution offerings.

BSD command utilities, while not universal, are more ubiquitous than the GNU command set, which Linux uses. And while some GNU utilities offer BSD compatibility, it's really a crapshoot whether they'll even compile. By using BSD commands, Apple made sure that a Unix pro could sit down and get to work with their command line. Even though Linux has grown somewhat in popularity, the choice for familiarity and compatibility is still clear. For those who want Linux command tools under OS X, porting isn't a problem thanks to Mac OS X's strong POSIX support.

Apple to this day remains with XNU/Darwin after six (and coming up on seven) major releases of Mac OS X. and are unlikely to switch any time soon. At most, a move to the GNU userland would be feasible, but since that's already available for OS X and BSD, Apple doesn't want mired in the GPL, that's unlikely too. So for the time being, it would be easier on all of us if the Linux-for-Mac OS X camp just quieted down and realized that Mach is what works best for Mac OS X because it offers so much more than Linux.

WebDav (4, Informative)

lymond01 (314120) | more than 5 years ago | (#28677001)

Re:WebDav (1)

Hurricane78 (562437) | more than 5 years ago | (#28677501)

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.)

they won't guess mine (0)

Anonymous Coward | more than 5 years ago | (#28677005)

Nobody will ever guess my FTP credentials.

login: guest

It doesn't matter (5, Insightful)

RenHoek (101570) | more than 5 years ago | (#28677067)

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 (1)

Chris Mattern (191822) | more than 5 years ago | (#28677563)

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 (2, Informative)

hrimhari (1241292) | more than 5 years ago | (#28677857)

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 (1)

DNS-and-BIND (461968) | more than 5 years ago | (#28677983)

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 (2, Insightful)

Goaway (82658) | more than 5 years ago | (#28677679)

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.

FTPS (5, Informative)

xororand (860319) | more than 5 years ago | (#28677089)

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

* vsftpd (can enforce encrypted FTP)

Re:FTPS (4, Interesting)

hardburn (141468) | more than 5 years ago | (#28677341)

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 (0)

Anonymous Coward | more than 5 years ago | (#28677649)

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 (3, Informative)

gpuk (712102) | more than 5 years ago | (#28677805)

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 (4, Interesting)

bitslinger_42 (598584) | more than 5 years ago | (#28677915)

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 (1)

xororand (860319) | more than 5 years ago | (#28678059)

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

Not just unknown, incompatible (5, Informative)

danaris (525051) | more than 5 years ago | (#28677435)

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 (0)

Anonymous Coward | more than 5 years ago | (#28677621)

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:FTPS (1)

Hurricane78 (562437) | more than 5 years ago | (#28677569)

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 (0)

Anonymous Coward | more than 5 years ago | (#28677953)

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

Re:FTPS (1)

BitZtream (692029) | more than 5 years ago | (#28677639)

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.


Re:FTPS (1)

hrimhari (1241292) | more than 5 years ago | (#28677939)

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

Re:FTPS (5, Informative)

Hatta (162192) | more than 5 years ago | (#28677989)

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:


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 (1)

SanityInAnarchy (655584) | more than 5 years ago | (#28678311)

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 (0)

Anonymous Coward | more than 5 years ago | (#28677641)

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 (1)

SanityInAnarchy (655584) | more than 5 years ago | (#28678351)

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.

These aren't average users, are they? (1)

Sockatume (732728) | more than 5 years ago | (#28677111)

(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? (1)

hrimhari (1241292) | more than 5 years ago | (#28678159)

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.

that's why (0)

Anonymous Coward | more than 5 years ago | (#28677121)

And that's why I bought a Saturn.

J.T.P. (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28677135)

Jew Transfer Protocol - let's just say it involves trains, gas chambers, and Germans.

Users can't tell the difference (5, Interesting)

Anonymous Coward | more than 5 years ago | (#28677137)

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 (5, Informative)

4D6963 (933028) | more than 5 years ago | (#28677461)

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 (1)

Hatta (162192) | more than 5 years ago | (#28678035)

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

Authentication goes both ways. (1)

skeeto (1138903) | more than 5 years ago | (#28677151)

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. (2, Informative)

minsk (805035) | more than 5 years ago | (#28677455)

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. (1)

hackel (10452) | more than 5 years ago | (#28677969)

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.

Well, maybe Re:Authentication goes both ways. (1)

davidwr (791652) | more than 5 years ago | (#28677517)

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?

here's a thought (1)

juanhf (167330) | more than 5 years ago | (#28677165)

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.

SFTP support is still spotty .... (2, Informative)

King_TJ (85913) | more than 5 years ago | (#28677173)

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.

So much for regard (0)

Anonymous Coward | more than 5 years ago | (#28677277)

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 (2, Insightful)

Trashman (3003) | more than 5 years ago | (#28677509)

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 (1)

RalphSleigh (899929) | more than 5 years ago | (#28677675)

Client != Server?

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

Re:SFTP support is still spotty .... (0)

Anonymous Coward | more than 5 years ago | (#28677559)

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 .... (1)

redhog (15207) | more than 5 years ago | (#28677845) 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 .... (1)

LordLimecat (1103839) | more than 5 years ago | (#28678179)

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!).

Not FTP, but any -- especially on IpowerWeb (1) (142825) | more than 5 years ago | (#28677199)

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 (5, Interesting)

ironicsky (569792) | more than 5 years ago | (#28677205)

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.

Thats not a rootkit (1)

Viol8 (599362) | more than 5 years ago | (#28677331)

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 (1)

ironicsky (569792) | more than 5 years ago | (#28678051)

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.

Wowa..... (1)

sysgeek01 (866290) | more than 5 years ago | (#28677209)

I just had a flashback to 1999...

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

Anonymous Coward | more than 5 years ago | (#28677221)

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.

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

Anonymous Coward | more than 5 years ago | (#28677855)

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

Keyloggers don't care (5, Insightful)

kenp2002 (545495) | more than 5 years ago | (#28677253)


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 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 (3, Insightful)

Anonymous Coward | more than 5 years ago | (#28677405)

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 (2, Funny)

Hurricane78 (562437) | more than 5 years ago | (#28677607)

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

well then the answer is simple (1)

circletimessquare (444983) | more than 5 years ago | (#28677759)

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 (2, Insightful)

kenp2002 (545495) | more than 5 years ago | (#28678099)

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.

Re:Keyloggers don't care (1)

Abcd1234 (188840) | more than 5 years ago | (#28677829)

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...

FTP isn't going anywhere (4, Informative)

BigJClark (1226554) | more than 5 years ago | (#28677287)

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 (1)

Hurricane78 (562437) | more than 5 years ago | (#28677677)

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 (1)

Corporate Troll (537873) | more than 5 years ago | (#28677711)

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 (1)

DNS-and-BIND (461968) | more than 5 years ago | (#28678049)

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 (1, Informative)

Anonymous Coward | more than 5 years ago | (#28677795)

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 (1)

Abcd1234 (188840) | more than 5 years ago | (#28677973)

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 (1)

BigJClark (1226554) | more than 5 years ago | (#28678219)

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 (1, Informative)

Anonymous Coward | more than 5 years ago | (#28678259)

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 (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 .


Insecurities in ftp (0, Troll)

Cheech Wizard (698728) | more than 5 years ago | (#28677295)

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... (1)

Mr. DOS (1276020) | more than 5 years ago | (#28677299)

...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

Only /.ers Care (1)

Dracos (107777) | more than 5 years ago | (#28677385)

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.

Hello...mcfly... (1)

furby076 (1461805) | more than 5 years ago | (#28677437)

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 (1)

roedelius (828058) | more than 5 years ago | (#28677511)

I still don't understand why slashdot's CSS designer, having apparently never heard of the <blockquote> tag, turned <i> 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")

The security lie (4, Insightful)

Lord Bitman (95493) | more than 5 years ago | (#28677595)

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.

tl;dr (1)

olborer (1372163) | more than 5 years ago | (#28677617)


Not every machine is on teh webs (1)

spungo (729241) | more than 5 years ago | (#28677667)

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 (0)

hackel (10452) | more than 5 years ago | (#28678083)

*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 (1)

spungo (729241) | more than 5 years ago | (#28678271)

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!!

Missing the point... (3, Insightful)

hackel (10452) | more than 5 years ago | (#28677789)

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... (1)

DNS-and-BIND (461968) | more than 5 years ago | (#28678109)

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... (1)

The Cisco Kid (31490) | more than 5 years ago | (#28678241)

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.

FUD. Bullshit article. (0, Troll)

EddyPearson (901263) | more than 5 years ago | (#28677965)

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 (1, Offtopic)

The Cisco Kid (31490) | more than 5 years ago | (#28677997)

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.

Misconception about crypto in article (1)

TerranFury (726743) | more than 5 years ago | (#28678053)

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!

Wrong side of the problem (3, Insightful)

gmuslera (3436) | more than 5 years ago | (#28678123)

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 (1)

i621148 (728860) | more than 5 years ago | (#28678211)

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?

RIP FTP? (0, Offtopic)

Junior J. Junior III (192702) | more than 5 years ago | (#28678345)


Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>