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 <[EMAIL PROTECTED]> 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, <[EMAIL PROTECTED]> 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! >>> > > >
