Closing the MS loopholes in network share security
Warning - never use the default 'Shared Music', 'Shared Pictures' or 'Shared Video' folders. By default, these folders can be accessed by 'everyone' with no password = and this simply invites the wannabee hacker script kiddies to steal (your music & movies), add (porn) or delete (your wedding photos) and do anything else that might enter their minds. Instead these folders should be deleted and forgotten about.
Remember = script kiddies and 'wannabee hackers' rely on Microsoft's 'gifts' and will only try to get access to what they can 'see' or know to exist 'by default'
How do I disable Microsoft's insane gifts to network intruders ?
A1. The first thing to do on any new install is disable Microsoft's first insane gift to hackers, 'simple file sharing'. This is found in the My computer icon (double click it to open a window), Tools menu, Folder Options, View tab** (scroll down to the bottom of the Advanced Settings list & clear the 'Use simple file sharing (Recommended)' check box). This will at least stop 'everyone' gaining immediate access to the default share 'hacker magnets' ('Shared Music', 'Shared Pictures' & 'Shared Video') and all the folders you decide to 'share' yourself.
**Yep - plainly MS thinks 'simple file sharing' is some sort of minor 'View' option ... rather than a fundamental hole in your Network Security ...
WARNING - if you create a 'share' before you disable 'simple file sharing', Windows will automatically add the 'Everyone' group to the share with 'read' and 'execute' access rights. So DON'T create ANY shares until AFTER turning off 'simple file sharing'
A2. Next you need to DISABLE Microsofts second insane gift to hackers the innocent sounding 'Guest' account. This account not only allows some-one to 'log-on' locally to your computer without a password, but also allows some-one to 'map' to a 'share' without specifying a User Name & Password (when they do so, they get 'Guest' access rights).
First give the Guest some random password, set 'Password never expires' and 'User can not change password' and finally 'Account is disabled'
A3. The third insane trick Microsoft pulls is to create drive 'root' shares for "Corporate Administration" access. To prevent the 'owner' accidentally discovering what has been done, Windows creates root access to the drives as 'hidden' shares 'C$', 'D$' etc. There is even an admin$, which maps to the \winnt (w2k) or \windows (XP) folder, just to make it 'easier' to access your windows system files. Whilst MS tells you how to 'stop' these shares they don't tell you how to prevent them being started again EVERY TIME YOU REBOOT
To disable this, the third of Microsoft's insane gifts to hackers, you have to edit the Registry, see How to disable hidden admin shares or below :-
Navigate to & highlight HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
(right click Services) New, Key = LanManServer
(right click LanManServer) New, Key = Parameters
(right click Parameters) New, DWORD Value, AutoShareWks
[the default value for AutoShareWks, 0, is correct]
A4. Note that, if you don't want anyone to access anything on your computer via 'shares', go to Control Panel, Administrative Tools, Services and set the 'Server' service to 'disabled'
Later, if you change your mind and right click a folder you want to share, when you choose Properties the 'Sharing' tab will only appear if the 'Server' service is running.
How do I setup a secure share ?
Assuming you have addressed above, access to a shared folder will only be possible via a User Account specifically setup on the host computer to restrict access and control what the remote user can 'see' and 'do'
A1. First you should always 'hide' the shares. This is done in the 'share' tab by adding a '$' symbol to the end of the 'share name'. This will 'hide' the share from another one of Microsoft's gifts to hackers, Network Neighbourhood 'browsing' by other computers. This will ensure that only those who know the exact name will be able to 'Map' to that share.
Since you will have made the Server computer itself 'hidden' ('net config server /hidden:yes'), hiding shares as well should prevent any nosey visitor 'stumbling' across your Server or it's shares
A2. Next, always create a new User Account for each individual share user. Never give users the name of a single 'common' user account, however tempting this may be = when something 'goes wrong', each of the 'common' users will blame some other. Further, should a 'common' account become 'compromised', 'locking' it will cause as many problems for the 'innocent' as it does for the 'guilty'
Assigning each remote user their 'own' account also makes it easy to detect 'compromise' by 'logging' access to the shares (you will be able to see immediately when the same 'user account' is used simultaneously from more than one computer)
To avoid having to add each new user to each multiple user share - eg Movie$, Photo$ etc. - you should create Groups, such as 'Movie Users', 'Music Users' etc (see later) and grant (add) the Group access to the share
A3. If you allow users to back-up to a share on your Server, you should create a separate share for each backup user. Whilst a user will need access to their own backup 'share' they have no valid reason for access to any other users backup 'share'.
In this case, you grant (add) the individual (not Group) User Account access to their own backup share folder
It is suggested that the backup share name match the user account name. To make life just a bit harder for 'wannabe hacker' who might try to 'guess' other back-up user share names, you could add a 4 digit PIN to the name = for example, if Johns (or Janes) computer needs to be backed up, you might create a user account 'John 1546' (or 'Jane 9762') and the back-up 'share' might be named 'Johns 1546$' (or 'Janes 9762$') ... thus removing the temptation for John (or Jane) to 'take a guess' and 'log-in' as 'some-one else'.
Having the 'same user name' as the 'share name' will make it a lot easier for you to remember who 'owns' what back-up (after their computer crashes) as well as making it harder to blame 'some-one else' when back-up files are deleted or over-written in error
A4. Finally, you should also create specific accounts for any computer that will need 'automated' or 'scripted' access. Again, the user 'name' should make it easy for you to remember 'why' that account exists
For example, you might create an account for a Digital Photo Frame with the name 'PhotoFrame' (and a password 'Ph0t0 Frame@R3ad_0nly') for Read access to the photo$ share (only). If you run into the 'simultaneous user' count limit, you can (temporarily) disable one of the 'scripted' users to allow a 'real' user access
Remember that Windows XP won't allow a user to 'log-on' to a remote computer using two different accounts at the same time. So all the 'shares' (photo$, backup$ etc) a user needs to access on your Server must be accessed using their own 'single' account
How do I secure the (local) server Administrator account(s) ?
A1. You will, of course, have renamed the 'real' Administrators account (and also have set up a second administrators account, for use when Windows corrupts the first)
Those with a sense of humor might 'swap' the names of the Guest and Administrators account. This is fine so long as the (old) Guest is 'denied' 'local' log-on rights :-)
A2. The Administrators Group should be set so that any member of that Group is denied 'remote logon' rights. This means you - or anyone else - MUST be sitting in front of the 'server' in order to log-in as an Administrator
A3. If you want to administer the 'shares' remotely from your own computer, you will need to create a new account (eg 'Shares Admin'), which is not a member of the (local) Administrators Group (so will retain remote log-on rights). This account is then added to each share individually with Full Control. Needless to say, to prevent this account being used 'locally', it should be 'denied' local log-on rights (so it is restricted to 'share' administration)
Do you need to setup Groups on the server ?
Yes, to minimise the administration of individual users accessing 'common' shares (such as 'Photo$', 'Movie$' etc) it's best to set up a Group with the appropriate access right for those shares. For a user to gain access to the share, all that needs to be done is to add them to the Group (rather than adding them to the share)
The exception to 'you only get access via the Group' is an individuals back-up share - here the individual is added to their own backup share to get access
What Groups should I setup ?
A1. 'Share users'. It's function is to 'Deny' users 'local log-on' rights, so ALL 'remote user' accounts (including any 'Shares Admin' account you setup) must be added to this Group
The rational here is that the name & password of a 'remote user' account may well 'leak' from the intended user (who may write down the details and stick it to the front of their computer on a 'Post it' note). It is even possible that details of the 'Shares Admin' account may leak (eg. by some-one 'shoulder surfing'). Being a member of this Group with 'deny local log-on' ensures that no remote user account can be used by someone sitting in front of the server itself
A2. 'Common share readers'. Members of this Group will be given Read & List access but Denied Write, Modify and Execute rights
This Group is for users of the music / photo / movie 'shares' who are not 'contributors' i.e. they can 'play' the media file but not modify or create new ones
If you want to further restrict access to your 'common' shares, create separate Groups for 'Photo readers', 'Music readers', 'Movie readers' etc.
To avoid the need for 'single member' Groups, 'special' accounts (eg Photo Frame) should be added directly to the single share they need to access (and given Read & denied Write)
A3. 'Common share contributors'. Members of this Group will be given Write & Modify access to the share but be Denied Execute and 'Change Attribute' rights (see later).
Note that those granted Write access automatically get Read as well. Note further that any user in both a 'reader' and 'contributer' Group will end up with 'reader' rights (not 'contributer' rights).
How do I 'deny' local logon rights ?
To remove this 'right', go to Control Panel, Administrative Tools, Local Security Policy, expand Local policies, User Rights Assignment. Find the 'Deny logon locally' key and add the 'Share users' Group.
While you are in Local Security Policy, if you haven't already done so, expand Security Options and change the "Interactive logon: Do not display last user name" setting to 'Enabled' (there is no point renaming the local Admin account if you let MS Windows ('the hackers friend') display the new name to everyone who sits down in front of the server).
Can I stop a share user account intended for one person being used by multiple individuals ?
You would think that a very sensible security precaution in any network would be a way to prevent the same user account being used on more than one computer at the same time. Unfortunately, it seems this is one of Microsoft's 'Domain only' functions
It would be possible to enforce this using a 'CMD file' running at frequent intervals (eg every minute). The 'net session' command will show the remote computer name and the user name of all those 'logged into' shares on the server. Since you are using 'unique' users names (John1234 etc) it is possible to note each account being used and check if it's used on more than one computer. The 'net session \\Your_computer/Name /delete' command can then be used to terminate all 'duplicate' name sessions (thereby shutting down any unauthorised user and prompting the real John1234 to 'complain' & have their account password changed)
How do you setup Security on a share to limit user access ?
NOTE that after the final step (in 4) below), you (the local logged in Administrator) will no longer be able to access that share (except by 'taking control')
A1. First you make sure the share folder will be 'hidden' by giving it a 'share name' ending in $
A2. Now Right click for Properties & select the Security tab
1) Start by adding your own remote administration (eg. 'Share Admin') user account with 'full control'
2) Next remove all other Users and Groups.
3a) If this is a 'backup share', add the User account for the individual who 'owns' the backup with full control but set 'Execute' to 'Deny'
In the Sharing tab, in User limit, click Allow. In the Users dialog box, enter '1' as the number of concurrent users
This adds to the protection of a back-up share by preventing any other user accessing it at the same time as the single 'authorised' user
3b) If this share is a 'common' share add the 'Common share contributors' and 'Common share readers' Groups and grant the appropriate rights (and deny others). If the share needs to be accessed by a 'special' account - eg Photo Frame - add that individual user with appropriate rights
There is little point in restricting the number of 'concurrent users', since a common share needs to be available for an 'unknown' number of future users
4) Add the (local) Administrators Group & set all rights to 'deny'.
The rational here is that anyone accessing the Server using a 'normal' remote share user account and then 'elevating' their permissions by adding themselves to the server's Administrator Group will immediately find themselves denied access to the shares. Further, since they will remain members of the Remote User group they be denied local logon rights and as members of the Administrators Group they will now be denied remote logon rights, so they will now be completely locked out !!
How can I prevent a shared file (music track, photo, video etc.) being modified or deleted ?
If you have kids and it's possible for them to delete your images etc., sooner or later they will. It's also far too easy to 'open' an image in Photo-shop etc. and after making some edit, casually click 'save' (which will then overwrite the original image on the share)
The first step is to ensure that those who will never be adding music, photos or movies etc. to the share are made members of the 'Share Readers' Group. However there is no way to use NTFS permissions (see Microsoft Technet) to prevent members of the 'Share Contributors' Group (who will have Write access) deleting (or overwriting) files.
To stop files being deleted, you can run a script that sets the files Properties to 'Read Only' (see my Using scripts to preserve your data page) and then make sure members of the 'Contributers' Group are 'denied' the right to change the file Attributes.
Note that 'deny' always takes priority over 'allow'. First the user gets those Permissions granted to their groups and then any 'deny' is taken off. So if you are a member of two Groups, one that allows some permission and one that denies that permission, you end up with 'deny' (to gain the permission granted by the other group, your account has to be removed from the group with the deny).
How do I track user activity ?
Use the server 'Auditing' Service to 'log' your remote users activity. You will want to see any 'failed' access attempts in the Security log and any failed 'delete' attempts on the Share(s) (photo archive etc.).
There is no point in tracking each individual file or folder 'create' or 'read' access. But you do want to know who is renaming folders = this is useful to resolve any disputes, especially if some-one is using 'Library' or 'Cataloguing' software (which may become very 'upset' if the folder names are changed :-) ). Remember = each individual user has their own individual 'remote access' user account, so there will be no doubt about who is doing what.
You also want to log ALL activity by members of the Administrators Group. In theory this is only you - however the first indication that you have been 'hacked' may come when you see an (un)successful remote log-on by some user account that has suddenly appeared in the local Administrator Group
Should I use Encryption or Compression on the shared folders ?
No
A1. Encryption is a waste of time = it does not improve security (because Windows will automatically decrypt the contents for anyone able to gain access to the folder), wastes time and is just one more 'disaster waiting to happen' = if you ever have to reload Windows you will loose access to all your encrypted folders, because every time Windows is installed it will create a new SID/GUID and thus a new encryption key.
A2. There is generally little point it using Compression. MS backups (.bkt files) are already 'compacted', so placing these in a Compressed folder is a total waste of time. The same applies to photo's (.jpg, .raw), music (.mp3, .wav) and video (.avi, .mov, .mpg, .m4v, etc etc) = since all these file types contain data that has already been compressed !
However, if you have limited hard disk space, you could enable compression on folders containing any MS Office etc. 'synchronisation' files. Unless you have an extremely slow Server CPU (eg a '486 or a sub-GHz speed Celeron), you will not see any slow down in access speeds (if your network does not limit your access speeds, your hard disks will).
Click 'Next >>' in the Navigation Bar (left) for Data Backup, Synchronisation and Recovery