1) don't use IIS. Use a *nix ftp server. I see more IIS servers
compromised hosting malicious software than anything. I also monitor
FTP brute force attempts on the public Internet and see that attacks are
particularly centered around IIS servers. A frequent malicious attack
involves brute forcing a customer account, placing a directory full of
junk code in their site, then using their domain name to host the junk.
Ultimately they come back and try other attacks on the server to deepen
their control. Once in, they start using it as a waypoint/relay point
for control traffic.
2) If you are going to run IIS FTP anyway, then DO NOT - ABSOLUTELY DO
NOT - run FTP and HTTP on the same server. Don't be tempted by
convenience. A compromise of one is the compromise of the other. See
#1. Allow FTP protocols to the DMZ box, but not HTTP in/out-bound.
3) host the FTP server in a limited-access DMZ with no inbound access to
the production network. Have another trusted server within your network
run a script to pull stuff and place stuff on the ftp in the dmz. That
way, if the ftp server becomes compromised, your internal systems have
another layer of protection. Essentially, treat the exposed dmz ftp as
if it has an exotic disease in a quarantine. Don't allow it to have any
potentially uncontrolled access into your trusted network. Always make
interactions with the server at the time and method of YOUR choosing.
4) Choose a more secure protocol, like S-FTP or HTTPS login with file
upload form. This protects the password from casual sniffing, but
doesn't protect from bruteforces. If your clients need to upload many
files, use curl with a script loop. Implement a 3-strikes and you're
disabled bad password attempt policy. The nice thing about many HTTPS
content portals is that they provide modules to implement this for you
with full logging (potentially alerting if using an add-on like OSSIM).
Kosala Atapattu wrote:
You can separate the OS users from ftp users by using a SQL backend to
authenticate. I have done this once but not sure if it works with
chroot jails.
Kosala
On Jan 18, 2008 11:02 PM, Andrea Gatta <andrea.gatta@gmail.com> wrote:
Hi Lauren,
not sure if it's possible using IIS but I would say that the best way
to lock down an FTP server might be starting to use a chroot
configuration. On some OS like Freebsd you can even go for a jailed
configuration which is even more strict than a simple plain chroot.
The main goal is, instead of allowing total access to the system,
limit access to a given and fixed part of the file system. That is,
once the user has logged into the system he/her will "see" only
his/her resources and nothing else. For example the command "cd /"
will only take the user to his/her "root" i.e. /home/user.
As I said, I'm not sure that this configuration is possible using IIS
but you may want to use proftpd which supports the chroot
configuration
Cheers,
Andrea.
On 18 Jan 2008 18:57:57 -0000, <lauren.malhoit@tylertech.com> wrote:
I'm preparing to build a new FTP server using IIS (or an IIS server using
FTP??? I'm not sure). Anyway, I was wondering if anyone could recommend
some good sources on how to lock it down. I need to configure it for an
FTP site that anyone can get to and one that is password protected. Thanks
in advance!
