Re: FTP server security.

From: John Rothlisberger (
Date: 11/11/03

  • Next message: Marcin Firlag: "RE: Exchange SMTP Hole?"
    Date: Wed, 12 Nov 2003 09:26:07 +1200

    I achieve what you are after using the following directory structure and permissions:

    D:\inetpub - Administrators:Full, SYSTEM:Full

    It is very important that you host this structure on a drive that is *not* the System drive, as many previous IIS security compromises have exploited the ability to execute programs located on the same drive as the inetpub folder. D:\ is your friend.

    Each customer has a user account on the machine (or domain if you are that way inclined), which following the above convention would be either customer1, customer2, etc. or customer1com, customer2conz, customer3net (I don't like punctuation in user accounts - just a personal thing). The first one is easiest; it would be very unlikely to hit two "customer1" and even if you did, you could call the second one e.g. "customer1b".

    Inside each customer directory you create the following directory structure with respective permissions. Note that Windows 2000 permissions inherit downwards, so e.g. Administrator:F at the top level (d:\inetpub) filters down through everything. -- inherited + Customer1:Change
      \wwwroot -- inherited + IUSR_SERVERNAME:Read
      \logfiles -- inherited
      \database -- inherited + IUSR_SERVERNAME:Change

    Now, when you set up the site, you point their Web root at D:\Inetpub\Customer1\wwwroot, their FTP root at D:\Inetpub\Customer1 and their log files at D:\Inetpub\Customer1\logfiles (so they can download the logs if they wish to analyse them themselves). Note that you have also managed to keep *everything* under a single directory, which makes it easy to calculate disk usage. Oh, and I sue the database folder to store Access and SQL Server databases. Again, I can add up the total disk space with ease, but it also means that a casual web browser can't download your customer's Access database. Your customer would access her Access database with something like ..\Database\blah.mdb.

    Note that customer2 has absolutely no rights to the entire directory structure of customer1, so he/she has no way of getting in (remember that the IUSR_ account has a random password that only IIS knows -- oh, and of course you *have* turned off Anonymous FTP!).

    You could lock things down further by using more specific permissions for the customer; "Change" allows them to e.g. delete the wwwroot directory (although from memory I think IIS will stop them because it is "in use"). So you could give them more specific rights, deny them the right to delete certain folders, etc. In my experience adding that extra level of security wasn't necessary, and does add to the complexity. You make it clear to your customers that you have backups but they have to pay per incident to get them restored. That makes them extra careful about what they delete.

    Oh, and have a batch job that zips up their logs daily or weekly so they can download them faster and they don't take up as much disk space of their precious quota.

    I hope this was helpful.


    John Rothlisberger

    ----- Original Message -----
    From: "Michael Bellears" <>
    To: <>
    Sent: Tuesday, November 11, 2003 3:04 PM
    Subject: FTP server security.

    We are running 2000 advanced server, hosting multiple virtual domains
    for clients, with FTP access via Virtual Directories.

    I have noticed that any user connecting via FTP, is dumped into
    "/username" - eg.

    # ftp
    Connected to
    220 iis02 Microsoft FTP Service (Version 5.0).
    Name ( craig
    331 Password required for craig.
    230 User craig logged in.
    Remote system type is Windows_NT.
    ftp> pwd
    257 "/craig" is current directory.

    If I perform a cd ../different_username, I am successfully dropped into
    that clients dir:

    ftp> cd ../1800contacts
    250 CWD command successful.
    ftp> pwd
    257 "/1800contacts" is current directory.

    Once in there, I am able to list, create, and delete - Obviously
    something I need to restrict!

    Is there anyway to 'jail' each user to there own directory tree? - i.e.
    once authenticated, they cannot perform a "cd ../whatever" - If not, is
    there a 'recommended' ownership/perms that will restrict access, but
    still allow browsing via the web?


    Network with over 10,000 of the brightest minds in information security
    at the largest, most highly-anticipated industry event of the year.
    Don't miss RSA Conference 2004! Choose from over 200 class sessions and
    see demos from more than 250 industry vendors. If your job touches
    security, you need to be here. Learn more or register at
    and use priority code SF4.

  • Next message: Marcin Firlag: "RE: Exchange SMTP Hole?"