Hmmm....hvis man kan få adgang til root-mappen, vha overordnede stier, så er der vel. prøv at downloade MBSA fra www.microsoft.com/mbsa Den kan da scanne efter et par sikkerhedsbrister.
Der er masive sikkerhedsrisici ved at oprette en ftp server overhoved. Denne gamle protokol er uden indbygget sikkerhed og ofte bruges ftp servere som indgang til systemerne. Generelt ville jeg ikke have mine ftp mapper liggende på systemdrevet, det giver både mulighed for sikkerheds kompromiser og mulighed for denial of service attacke
Det gør det, og du kan øge sikkerheden yderligere ved at ntfs formatere disken, oprette alle dem der skal tilgå filerne som brugere, sætte rettigheden på ntfs til disse brugere. Det har så den ulempe at kun oprettede brugere kan tilgå og at alle skal oprettes (her under forudsætning af at anonym tilgang forbydes)
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.
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. --------------------end snip 1----------------------------- --------------------start snip 2--------------------------- 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. ---------------------end snip 2------------------------
Læs den omhyggeligt derer gode informationer i begge
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
