FTP stops working after installing Apache port

I run Freebsd 5.4 on a remote server.

This is a brand new install. I enabled FTP and SSH by enabling inetd in rc.conf and uncommenting the ftp/ssh lines in inetd.conf and it worked fine.

I then installed CVSup and Portupgrade via Ports - everything was still fine.

Next I installed Apache2.2 (and its required packages) via ports. The installation went fine but I can no longer access the server via ftp although ssh still works.

I use WS_FTP on a windows box to access the remote server. A connection is made but the program then sits and waits for a response from the server which it apparently does not receive and the remote host terminates the connection.

Any ideas....?

Couple things you can try:

1. SSH in, and run tail -f /var/log/auth.log. While you are watching this log update, try your FTP connection and see what happens. You can also try looking at /var/log/messages the same way.

2. If this doesn't give you any good info, then right after the connection is terminated, run dmesg -a in your SSH terminal, and see if anything pops up.

3. Did you verify that inetd.conf has not been changed in some way? For example, is the FTP line still uncommented? Ditto for /etc/rc.conf

4. Have you considered just how really, really bad FTP is for security? Why not just use SFTP, which is enabled by default if you have sshd running. If you need a Windows client for this, try WinSCP. No more plaintext passwords sent through other people's routers . In fact, if you are running default, unprotected FTP on a server with a public domain name, it is only a matter of time before you are hacked.

5. If you really must have FTP, do it right. Disable inetd.conf, install ProFTPD (/usr/ports/ftp/proftpd), and learn how to configure /usr/local/etc/proftpd.conf so that only a limited number of users can get in, and learn how to set your other directives for maximum security. Pay special attention to MaxLoginAttempts and all the other "Max[something]" settings, as well as DefaultRoot. Turn RequireValidShell off and make sure that any user who is connecting to FTP is not able to connect via SSH (set them for /sbin/nologin). At least you can sleep with only one eye open at night .

Regards,

A FreeBSD user who has been hacked

Thanks for the response.

I could not glean any useful info from the logs etc.

WS_FTP has an SFTP/SSH option which I tried, but it did not work, something to do with the keys missing I think.

In any case I downloaded SCP and that seems to work. SCP will be fine for server admin i.e. my use.

However, for uploading websites etc and in particular with Dreamweaver, what is the best approach - ProFTP?

FWIW I have now disabled FTP in inted.conf

TIA

Glad SCP is working for you.

Yes, for your website owners, best bet is to run a sandboxed Proftpd setup, as I describe above. No FTP user should have a valid SSH account, period, because once an FTP username/password is sniffed the next thing a hacker will do is try to SSH to that machine with that account.

Also, do some serious reading on FreeBSD security. Best to at least set

kern_securelevel_enable="YES"
kern_securelevel="1"

in /etc/rc.conf, and set NOSUID and NODEV flags for /tmp, since a lot of common exploits involve placing tricky files in /tmp, and that can be done fairly easily with some versions of PHP. See this link for more. You should also spend some time looking through the basic security documents in the FreeBSD handbook, and perhaps do a search on

Do a search at FreeBSD security /tmp at Google.

By the way, the same applies for standard Unix POP3 accounts also: default POP3 on FreeBSD is done with plain-text logins, so if your mail users happen to have SSH login with the same username/password, you are wide open for exploits. Learn to at least set up TLS for mail, but better yet, learn how to divorce mail accounts from Unix shell accounts. I use DBMail for my mail users, which allows me to have mail accounts in a PostgreSQL database, and not at all tied to Unix shell accounts.

Personally, I would put Apache's tmp dir somewhere besides /tmp (say /var/tmp). You can apply nosuid and nodev to /var as well (or create a separate /var/tmp partition just for apache and apply nosuid, nodev, noexec). Reason for keeping apache's tmpdir on /var/tmp is because /tmp is used by a lot of system daemons for keeping track of system specific things. One of these is sshd, which writes a session file in /tmp every time you ssh into the box. If apache were to fill up the tmp dir (don't laugh, it has happened to me before!), your app will probably quit working and pop error messages. Worse, you can't now ssh into the box and fix the problem because sshd can't write to /tmp as it is now full.