BE/FE Security *Important*

[razaqad]

i have an access application in fe/be environment. I have put the BE in a shared forlder on the network.

Now the problem is that the shared folder where the BE is stored, has full read/write access. And this folder is visible to all users on the network from their network neighbourhood or through the mapped metwork drive.

So the problems are:
1) The shared folder has read/write access, so anyone can delete the BE mdb file. <<<<< main problem >>>>>

2) As this folder is visible to even those users who do not use this softaware, anyone can see the data.


We are using winxp and win98 on our network.
What can i do to secure the BE mdb file?

 

[RuralGuy]

If you end the Shared folder name with a dollar sign "$" then I think you will find it is not visible on the network but still available if you know the name. As for securing the BE, I put auto code that displays a message about no access allowed and quits when someone tries to open the BE. You can also secure the AllowBypassKey to make it really tight.

 

[ghudson]

1) Your network security folks could set the file permission to the backend file [not all files for the .ldb file needs to go away each time the last user exits the db] so that it can not be deleted.

2) Your network security folks can create a secured group for the directory where the backend is located and only the members of that group can access the secured directory. All group/department specific directories should be locked down.

 

[razaqad]

RuralGuy:
If you end the Shared folder name with a dollar sign "$" then I think you will find it is not visible on the network but still available if you know the name. As for securing the BE, I put auto code that displays a message about no access allowed and quits when someone tries to open the BE. You can also secure the AllowBypassKey to make it really tight.

I told u that the shared folder where the BE is kept is a mapped network drive on user computers. so no reason for $ sign. Yes but it is useful for securing from users who dont have access to my software. And i have secured the allowbypass key and i have also put a code to identify the computer so only those people can open the software who are autherized to do so. But still the problem is that anyone can delete the BE file. Actually there are some people in the production department who can accidentley or intentionally delete the BE file. And anyone who has some know how of access and vb can bypass the security of BE file and gain access to all the critical information.



ghudson:
1) Your network security folks could set the file permission to the backend file [not all files for the .ldb file needs to go away each time the last user exits the db] so that it can not be deleted.

2) Your network security folks can create a secured group for the directory where the backend is located and only the members of that group can access the secured directory. All group/department specific directories should be locked down.

well i'm the only network security , IT department or what so ever. Im the only person who handels all the issues. Ghudson can you elaborate what you said. and i have said above that those people who have access to the software ie. who are allowed to use the software have full acess to the shared folder where BE is kept. So they can actually delete the BE file.

 

[ghudson]

ghudson:
1) Your network security folks could set the file permission to the backend file [not all files for the .ldb file needs to go away each time the last user exits the db] so that it can not be deleted.

2) Your network security folks can create a secured group for the directory where the backend is located and only the members of that group can access the secured directory. All group/department specific directories should be locked down.

well i'm the only network security , IT department or what so ever. Im the only person who handels all the issues. Ghudson can you elaborate what you said. and i have said above that those people who have access to the software ie. who are allowed to use the software have full acess to the shared folder where BE is kept. So they can actually delete the BE file.

Our company uses NT servers. My IT security folks have told me that they could set the security to a file so that nobody can delete it. We use custom security groups that our users have to be members of or else they can not access the sercured directories where the back end of the db is located. Sorry I can not give you the how to's but I am not a network security person.

 

[Robert88]

Hi razaqad,

NTFS allows for the following file permissions;

Read
Write
Read & Execute
Modify
Full Control

If you remove Full Control and Modify permissions from the file the remaining permissions (Read, Write and Read & Execute) should allow users to use it and not delete it.

The same permissions apply to folders and as GHudson has suggested it is better to place all your users in a group and apply the same permissions as above on the folder and that will have the same effect. Usually you want to avoid going all the way to securing files, it is best to work on folders from an administration point of view.

Robert88

 

[razaqad]

Hi razaqad,

NTFS allows for the following file permissions;

Read
Write
Read & Execute
Modify
Full Control

If you remove Full Control and Modify permissions from the file the remaining permissions (Read, Write and Read & Execute) should allow users to use it and not delete it.

The same permissions apply to folders and as GHudson has suggested it is better to place all your users in a group and apply the same permissions as above on the folder and that will have the same effect. Usually you want to avoid going all the way to securing files, it is best to work on folders from an administration point of view.

Robert88

hi robert ,

i dont have much knowledge about networking and group security. can you explain in detail what you said.
thanx

 

[The_Doc_Man]

OK, first things first...

If you use workgroup security correctly, I believe the information in the DB is encrypted to those who do not go through the workgroup. So perhaps your concern is not well-placed in that regard.

Search this forum for literally HUNDREDS of descriptions about the correct way to set up workgroup security so that no one has any rights if they try to connect through the "default" workgroup created by installation of Office on their particular machines.

Among other things, this means creating a workgroup file with a name other than SYSTEM.WKG in the same folder as your main .MDB file. Create some groups through which your users will gain whatever rights they have. NEVER EVER IN A BAZILLION YEARS should you use the Users group for this purpose. Create an account that is a member of the Admins group but that isn't named Admin. Then, you have to "adjust" the security of the Users groups and the Admin account so that nobody has any rights. But if you do the search, you are better off reading the more detailed articles.

Now, as to the security on the file, you must be extra careful. You need nearly full access for all users on the folder and the files therein, mostly because you have to be able to update the .MDB file and you have to be able to create/delete the .LDB if you are first in/last out of the .MDB for the day. And of course, first/last accesses aren't predictable. BUT you can do this rationally. Here are a few hints:

1. DENY is the most dangerous option you can use on a permission set because if you are a member of the affected group, you can't EVER compress or repair the DB. If you don't want someone to have access to a .MDB file, remove the permissions. Do not use DENY.

2. You might wish to remove inheritance from the folder if it isn't at the top of the folder tree on the shared drive. I.e. S:\L1\L2\L3\MyDB is not as easy to manage, security-wise, as S:\MyDB - because of inheritance. So take away the chance to inheret.

3. Always use GROUPS rather than USERS to define access rights. Define a group that has the rights you want - at the server level. Then make your users members of that group. NEVER let them get personal rights from Windows based solely on their login name.

4. If some yahoo decides to delete the .MDB file, you can at least catch that person by adding a security Access Control Entry on the .MDB file to perform an event log at file deletion. Then review your security logs.

5. BACKUP BACKUP BACKUP. Never leave a DB sitting exposed to the world without a good backup regimen.

6. Publish penalties for thumb-fingered idiots who delete things they shouldn't. Like threaten to shorten their careers with your company. Then carry out the penalties at least a couple of times. (You have to have a "sympathetic boss" to make this stick; unfortunately, too many of us have that kind of boss minus the first three letters.)

 

[Robert88]

Hi razaqad,

What server are you running, I have looked after Windows NT Server, Windows 2000 and now Windows Server 2003.

A lot of changes were made between Windows NT and the reminder, as microsoft introduced Active Directory, which is where all groups are created.

I would have to set-up a Windows NT Server which could take a couple of days if it is a NT Server, in order to support you.

You are lucky as I am just going through the ropes of upgrading my 2000 server at home so this would not be a problem, but let me know which server you have first before I make a comment on NT File securirty.

Look forward to your response.

Robert88

 

[razaqad]

currently im using winxp but for security reasons going to shift to either win 2000 or 2003. what do u recomend.

 

[Robert88]

Hi razaqad,

Windows XP is for your clients.

With Servers, Windows Server 2003 is more secure than Windows Server 2000 by default, Microsoft tried to follow the LINUX method of security everything by default is closed and then the Administrator gives permissions.

Give me a day or two to set-up this NT server, when I have it set-up I will get back.

Robert88

 

[razaqad]

thanks robert

 

[Robert88]

Hi ,

OK, the permissions I spoke of earlier were from a 2000 or 2003 Server along with Windows XP local machine. In your case you will have a shared folder on a Windows NT 4.0 Server so you will have to change the file permissions according to this list;

1. No Access: The user or group is unable to read or change the file.
2. Read: The user or group can only read the file, but not change it.
3. Change: The user or group can read and change the file.
4. Full Control: The user or group can read and change the file, as well as change permissions for other users or groups.

I would say create the group as according to the first link below, what they caled "Pathways Group", on your server (obviously give it a name you are familiar with, say "Access Users". Place all users (which they refer to as "pathways", in the first link) in this group and then place the group permissions on the folder with this group. However I would not give them "Full Control" permissions in order to stop them from deleting it.

Try either of these two links in order to set your folder permissions;

http://support.plato.com/kb/tip.asp?psid=23725

http://support.riverdeep.net/techtips_detail.asp?id=158

I will still set it up but might have to wait longer, I hope in the meantime this helps.

I would also take on board "The Doc Man's" comments above as well.

In order to keep tabs on users who delete I would also investigate Auditing the folder so that you know who deletes it. Not sure if this can be done on Windows NT as it was along time ago, but it can certainly be done on Windows 2000 and Windows 2003 Server. I think "The Doc Man" is right here but as an administrator you also have to have proof of this transaction, auditing a folder is one method.

Good Luck.

Robert88