Search: Home Bugtraq Vulnerabilities Mailing Lists Jobs Tools Beta Programs
Focus on Microsoft
FTP server security. Nov 11 2003 02:04AM
Michael Bellears (michael bellears staff datafx com au) (3 replies)
RE: FTP server security. Nov 13 2003 04:52AM
Laura A. Robinson (larobins bellatlantic net)
Re: FTP server security. Nov 12 2003 05:09AM
Jorge Alejandro Olivo Ramirez (jorge alestraidc net mx)
Ok Michael, to complete your goal, follow this steps:

Step 1: Create a home folder for your user.

Typically, this will be a subfolder under a parent folder that is named
exactly the same as the username. All users will need the right to Log on
Locally. Of course, Admins should have full control of everything all the
time.

TIP: Do not set NTFS permissions yet. If you do, be sure the System account
has access to the users' folder or you will get a 'stop sign" error when you
try to create the Virtual Directory.

Step 2: Create a Virtual Directory and map the user's folder.

The trick here is that the Virtual Directory has to be the exact same name
as the user. In this case, we create a folder called Juan and map it to
FTPusers/Juan. Note that the directory name is case sensitive!

Step 3: Enable Write on the Virtual Directory

Unless this is a read-only FTP site, enable the write permission on the FTP
snap in.

Step 4: Remove Anonymous authentication from the Virtual Directory.

Uncheck the "Allow only anonymous authentication" on the Security Acccounts
tab. Now, when Juan logs on, he will be automatically placed in his user
folder.

Step 5: Assign NTFS permissions.

For the parent folder of your users' folders, you can assign No Access to
the anonymous account. Despite what some KB articles say, the user does not
need permissions to the parent folder. The System account, however, does
need access to this folder so Everyone, No Access is not a good idea. If the
System account can't access the folder, you can have problems later when
you go to make changes to the FTP server setup for the user.

For the users' folders, NTFS permissions Read and Write are typical. Execute
permissions should be avoided. Remove Everyone from the access list and add
the user's account. According to your policy, you may or may not include
Administrators.

That's it! Now when users log on with FTP, they will be routed to their own
FTP folder.

TIP: You can keep users from seeing folders for other users:
1. Point your FTP server to an empty root. Fine to use Inetpub/ftproot, just
don't put anything in there or your users will see it.
2. Map your users' Virtual Folders to a location outside of the FTP server
virtual root. By keeping your users' folders in the same parent folder
outside of the virtual FTP root, when they go "up" in the directory tree
from their personal folder, they will be magically transported to the empty
FTProot.

WARNING. Password sent to the FTP service are sent in absolute cleartext.
SSL can't be used and you can't use NTFS authentication. No good solution
exists for this problem using native Microsoft FTP server.

Jorge A. Olivo Ramirez
Internetworking and Linux Manager
www.att.com.mx

Hasta la victoria siempre :)

----- Original Message -----
From: "Michael Bellears" <michael.bellears (at) staff.datafx.com (dot) au [email concealed]>
To: <focus-ms (at) securityfocus (dot) com [email concealed]>
Sent: Monday, November 10, 2003 8: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 xxx.xxx.xxx.xxx
> Connected to xxx.xxx.xxx.xxx.
> 220 iis02 Microsoft FTP Service (Version 5.0).
> Name (xxx.xxx.xxx.xxx:mb): craig
> 331 Password required for craig.
> Password:
> 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?
>
> Regards,
> MB
>
> ------------------------------------------------------------------------
--
-
> 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
> http://www.securityfocus.com/sponsor/RSA_focus-ms_031027
> and use priority code SF4.
> ------------------------------------------------------------------------
--
-
>

------------------------------------------------------------------------
---
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
http://www.securityfocus.com/sponsor/RSA_focus-ms_031027
and use priority code SF4.
------------------------------------------------------------------------
---

[ reply ]
Re: FTP server security. Nov 11 2003 03:54PM
Ivan Hernandez (ivan hernandez globalsis com ar)







 

Privacy Statement
Copyright 2009, SecurityFocus