Why is FTP blocked by a remote host when you try to initiate the connection with another website?
i.e.
ftp ftp.website.com

in command prompt this yields "connection closed by a remote host". I want to download files not offered for download. (not piracy, but for legit stuff) So ftp keeps that from happening.

BTW, webmasters out there. Is it dangerous to have an ftp on your website. People could find the password and screw crap up.

The site owners would have had to have set up an FTP server with public access (typically read-only). Just because a site has a publicly accessible HTTP server doesn't necessarily mean they have a publicly accessible FTP server (or, indeed, any FTP server at all).

Hosting packages typically come with an FTP account tied to the web server with full access as a way to upload the site. This is usually the only way you have access. If someone finds your password, then yes, they can "screw crap up". More advanced hosting packages would let you protect the FTP server behind a firewall, or offer more secure ways to upload files.

Ah! It must be a fire wall with a whitelist! It only allows certain people in. BTW, it is a well known site. Very likely answer! (so dumb of me to overlook something as stupid as a firewall...)
So, how can you whitelist yourself with another site??

Contact the webmaster.

Well, that answers the question..

No, that's not it either. What you're not understanding is that FTP and HTTP are two different things as far as permissioning and such. HTTP runs on port 80 (usually), and is generally (on a webserver) permissioned to serve specific types of files from the subdirectories of a given directory. FTP generally runs on port 21, for public FTP, but requires a username and password to access. A site may choose to expose public FTP on port 21 but password-protect it, require FTP via SFTP (FTP over SSH), put FTP on a port other than 21, or not have FTP or SFTP at all. FTP is not an alternative method of browsing and/or downloading the contents of a website.

Kerm just took everything I understand about the internet and changed it. Thanks Kerm...(I think...)

What specifically? I'd be happy to add some more details as necessary; I'd prefer to teach you as much as possible rather than just give you bits and pieces of the full picture.

I don't understand how you can update something without the protocol. That's how I did my website, is in FTP and notepad. (long, dark, scary nights for me...) I'd love to know how you can block from FTP based attacks. (which you might not know how, judging by the fact I can get right into yours...) The whole FTP thing is a huge vulnerability to my work on my website.
Secondly, I can't grasp how you can do it on a different port. I thought the port was constant. http is always port 80, and ftp is always port 21. If you change the port, how could any user even bother using your site? The ports are standard things, not something you change willy-nilly! But you said it isn't. So explain that.

Are you talking about Cemetech? The FTP you logged into anonymously looked blank, if you found an anonymous FTP, and you couldn't do anything with it. Please don't try to lecture me on Computer Security, I think several courses taken and papers published on the topic plus two EE/CompE/CS degrees give me some degree of authority. You can change ports to whatever you want, it's just that people using a web browser won't necessarily think to look anywhere other than port 80. I could link you to http://some.domain.com:8080/stuff.html, and that's a perfectly valid HTTP request on port 8080 (assuming it existed, of course). If there was nothing listening on the server on port 8080, you'd be SOL. Similarly, you can set the FTP port to whatever you want, and people running random port 21 attacks won't immediately run across it.

Kerm, I meant no offense to the classes you've taken. I do not doubt that you are far superior to me in every aspect of code. But yes, cemetech is what I was talking about. I didn't try to actually do anything though. I was just checking to see if you already knew for sure or not. One sec...
I took a guess at the username as kermmartian@cemetech.net
Guessed password, but authentication failed. No surprise there. I don't know KermM enough to guess a password.
So exact retard thing I tried Kerm is:
ftp ftp.cemetech.net
(insert in fancy thing here that says the privelages allowed to the anonomous user, blah blah blah. No login for just anyone...)
kermmartian@cemetech.net
331 User kermmartian@cemetech.net OK. Password required.
Password:

Oh, I see now Kerm. It does the same thing for fakeys like me as it did for what I guessed yours to be, so yeah... Was being dumb.

And thanks for showing me the port stuff. I don't understand why, but I do how now.
Finally, super impressive all those degrees. I'm just a stupid high school student who thinks their all smart.

Haha, I'm sure you're miles above all of your peers, and I think you'll go very far, don't take it as an attempt to put you down. I just get tetchy when people tell me they can circumvent my security when I know that that's not the case. The FTP 331 "user [user] OK" message is not confirmation that the username is valid, because that would make guessing FTP accounts a lot easier. You could just iterate usernames till you found a bunch of valid names, then iterate common passwords to bruteforce, essentially a (2n) search space. This makes it that both the username and password guess have to be correct, and there's no confirmation if you get one correct and the other wrong, a search space of (n^2), much much better for n >> sqrt(2) (and even n>sqrt(2)), as any computer scientist who's takes a CompSec or Data Structures & Algorithms class could tell you. Also, that's not my username.

There are other ways to upload your files, too. Especially if you have control of the server. You can use SFTP, or SCP, or FTP over SSH, or, if you have access to the actual hardware, either develop right on the server or use a flash drive. Hell, you could even develop your own transfer software if you really wanted to.
The argument about being able to guess a username and password isn't just an FTP thing. If you get to the point where you have access to a login prompt, you can do this no matter the protocol. There are measures to help prevent that, of course, but nothing is 100% water-tight.

Exactly, well-said. There's a certain amount of security-by-obscurity that has to be performed in every case, but ignoring that each method has similar weakness in terms of brute-forced login credentials.

Kerm, I'm far above my peers! But all we New Mexicans are stupid, so who cares. So FTP is not as powerful as I thought is was. I need to go and fix this on my site. (Though there really isn't anything to attack, and I back it up every week anyway...)

Well, you could leave it open for everyone to download your website, but that would be just about the worst security decision ever.

What's wrong with download? If they could upload I see the hazard, but download should be safe.

On Cemetech, for example, downloading the .php pages would give people the source of those pages rather than the content that they generate for users. That would allow all kinds of mischevious behavior, since one or two of them, for example, contain the credentials for the database server.

Ah! The SQL is revealed in the pages! (adept remembers his long hours studying this subject, alone in front of his computer.) That would give freedom to users credentials, including the webmaster's, which would compromise the integrity and reliablility of the site!
So why are the locations of those databases in the PHP? Why can't they be hidden? (Cuz adept never really works with PHP.)

That is where they're hidden. The HTTP part of the webserver is designed so that every PHP page is parsed and its output, rather than its source, served to the client. The page you're viewing right now is a giant 2,000 or 3,000-line PHP script that includes dozens of other scripts within it to handle your credentials, the news, the online users list, the profile info of all the users on this page, and much of that data is pulled from various tables and databases.