Securing an FTP Server

P

Phandalyon

Guest
Joined
Jun 12, 2001
Messages
5,839
Any quick tips for securing an FTP server. I just got one up and running. Anonymous access is disabled. Is there anything else I really need to look out for?
 
First off, make sure that you're running the latest version. This will lessen the risk of known exploits being used against your server. Many FTP daemons have holes in them that allows an attacker to crash the system. The good news is that most of these are patched rapidly, and you can protect yourself with the latest version.

Another major technique you can use to protect the integrity of your system is by changing the user that the server either runs as or saves files as. Avoid running it as root/administrator if the software permits it.

Since every user has their own account, turn on access logging in full detail. This will allow you to spot suspicious activity, as well as investigate any comprimise of security that takes place under a logged in account. Since accounts are regulated by the administrator, this will dramatically decrease the risk of anonymous attacks, now that a valid account is required. Also, users will be discouraged from attempting to exploit a hole or exceed their authority, since the action will be logged.

If on *nix, make sure to chroot the user to their home directory. If not, look for a similar option. Disabling a user from leaving their home directory will prevent a hole in FS permissions elsewhere from being accessed and exploited.

Make sure you disable server-to-server transfers, unless you have a highly trusted base of users. Othewise, a user can clog your bandwidth by transferring large files to another server on a backbone, at rates far higher than a normal residential/commercial line can support. Along this same line, enable a transfer quota for all users, and adjust as necessary. This can keep comprimised accounts from overrunning the bandwidth that they should be using. If a user legimately uses more bandwidth than would be expected, one call to the admin can establish that the increase in transfer is legitimate, and not part of and attemt to DoS the server.
 
You should start securing an ftp server with folder permissions. Make sure the everyone group is removed (NOT denied access). Limit the number of connections to the server (I use 4). Modify advanced permissions on the ACL so users can write to a directory but are denied delete permission. Otherwise any user can go in and delete everything in your server's ftp folder. Never ever log into an FTP server using an administrative account or an account with special access to anything as passwords are transmitted over a network in plain text. Anyone on your network can see ftp passwords plain as day.

you can also change the port from the default 21 to something else (just make sure it's not used by anything crucial).
 
Yoblad said:
You should start securing an ftp server with folder permissions. Make sure the everyone group is removed (NOT denied access). Modify advanced permissions on the ACL so users can write to a directory but are denied delete permission. Otherwise any user can go in and delete everything in your server's ftp folder.
Click to expand...
Thats only applicable on Windows.

Yoblad said:
Limit the number of connections to the server (I use 4).
Click to expand...
That will do nothing but make it easy for an attacker to prevent legitimate users from logging on by tying up every connection.
Yoblad said:
you can also change the port from the default 21 to something else (just make sure it's not used by anything crucial).
Click to expand...
This doesn't help. Hiding a service is not security, its obscurity.
 
M11 said:
Thats only applicable on Windows.


That will do nothing but make it easy for an attacker to prevent legitimate users from logging on by tying up every connection.

This doesn't help. Hiding a service is not security, its obscurity.
Click to expand...

1. He didn't specify what he was using so we can assume it's IIS.

2. I'll admit that it doesn't do much to secure the server but you really don't want 1000+ people to be able to connect to your server at any time if it IS compromised. I do it so each user is granted a sufficient amount of my available upload speed. If I let it go like wildfire I could have 40 people trying to download something at 2 kB/sec

3. Apparently you're not familiar with practicing security through obscurity.

edit: BTW I wasn't refuting your tips, only adding to them.
 
Yoblad said:
1. He didn't specify what he was using so we can assume it's IIS.

2. I'll admit that it doesn't do much to secure the server but you really don't want 1000+ people to be able to connect to your server at any time if it IS compromised. I do it so each user is granted a sufficient amount of my available upload speed. If I let it go like wildfire I could have 40 people trying to download something at 2 kB/sec

3. Apparently you're not familiar with practicing security through obscurity.

edit: BTW I wasn't refuting your tips, only adding to them.
Click to expand...
1. Assuming anything in this instance is a bad idea, especially IIS. IIS is not even close to the predominant FTP server.

2. You can limit one account to one concurrent session to prevent a comprimised account from tying up excessive resources (memory, CPU, etc since it can waste BW whether its connected 1 or 1000 times). Limiting connections to keep acceptable speeds is not security but efficient use of the network.

3. Obscurity is not security. Changing ports will confuse legitimate users, but not deter hackers with port scanners. Besides, with proper access control, who cares if people know a box has an active FTP server on it?
 
Well, if he/she is using anything but IIS point 1 is not applicable as you stated. Most ftp servers are running IIS though so anything we can do to help with that is valid info.

I've already stated that point 2 isn't really much of a security measure, but I feel it's good practice to limit the number of connections.

I feel that obscurity IS security. Anything you can do to make your server less vulnerable or harder for the wrong people to find you is a security measure. It's almost impossible to set up an indestructible ftp server. Granted, changing the port number might be something legitimate users take issue with but he hasn't commented on exactly who will be using this and what they will be using it for. Is he hosting files for download that are linked from a web site? Is he serving files on a business LAN? Is he hosting skateboarding videos for his friends? We don't know. Security isn't achieved by checking some magic box or setting a 1 to a 0. It's by using mutliple layers of athentication and access control, and misdirection for those who don't belong.
 
relying only on security through obscurity is a bad idea, however, adding obscurity as an additional layer helps.

moving your FTP port from the normal one to a random one might confuse the attacker (if they are a n00b) into moving along to an easier target.
 
i can clear some of this up.

It is an IIS server (unfortunately, not my choice)

It is running on a Windows 2003 SBS box

It is behind an NAT DSL modem with only the FTp and VNC ports forwarded right now. I will probably disble the VNC ports in the future, I am just working on it right now.

Everything is passworded with nice, complex passwords.

The user base for this is extremely small. There are 3 users in house, and one who accesses the FTP remotely.

Thats it.

So I can pretty much secure it as much as I want.

All the latest updates and patches are installed, and set to check and install regularly.

Oh, and I removed all users from permissions except the specific one that I want to allow to logon. I will probably set it so only 1 user can login at a time and since his remote PC will automatically log in and map the FTP server as a drive on startup it should effectivelt lock that one user port up.

I have not changed ports, but I guess its not a bad idea since there is only 1 user and his computer will be preconfigured for everything.
 
Steel Chicken said:
sounds like you got it pretty well setup for what you have to work with.
Click to expand...


Thanks. This has been a trial and a half. They started out wanting a VPN and things degraded from there. Qwest irritates me now.

But at least it should be a decent system for them.

I really love Novell NetDrive. I had never used it before, but now I can't live without it.

;)
 
M11 said:
Thats only applicable on Windows.


That will do nothing but make it easy for an attacker to prevent legitimate users from logging on by tying up every connection.

This doesn't help. Hiding a service is not security, its obscurity.
Click to expand...

1) ACL is but many *nix daemons (pro and vs for example) follow the same template

2) Actually some exploits rely on people like you ;)

3) Of coarse it helps lmao.. Do you have any idea how many random exploits, zombies, and alike just spew out packets to 21? Let me show you how many our box got yesterday alone.... Dropped 721 packets That was JUST to 21 from over 600 different hosts...

The #1 threat now days is NOT some guy hacking into your box. It is running an outdated and or exploitable piece of software that a zombie randomly attacks which results in a script or alike being exec'd on your box. Next reporting that it has succeeded which in turn results in someone controlling your server. Most "hacks" are all automated and the person responsible has either watched a bot log in somewhere thus showing them it was successful or the guy is simple sending a syn to every IP on the net on specific ports just looking for boxes that have a given bot/daemon/exploit running on them.
 
You must log in or register to reply here.
Back
Top