Simple Solution to prohibit client users from directly accessing server shared folders in LAN

In actual applications of the company, the server needs to share some folders with the client, so that the client users can use specific software to read and write the files in these folders. However, the current problems are: otherwise, you will not be able to access Shared Folders. Otherwise, you will be able to access the Shared Folders once successfully through that program, and then you will be able to go directly to the network neighbor or start menu to go in and go around.

In fact, this problem has been around for a long time and I have never imagined any simple solution. However, as the number of users increases, file security becomes more and more important.

The best solution to this problem is to program the software through socket. However, socket programming is relatively low-level and requires a program to handle many network communication problems. In addition, I am not very familiar with socket programming, so this solution was put to the end.

With the continuous release of new versions of. net, remoting and WCF that can be transmitted over TCP have emerged, and I have seen new hopes. However, I learned about WCF two days ago and found that it is still good for normal data transmission. However, the stability of stream processing is still a little lacking, and some strange errors may occur. Let's wait for Microsoft to complete it and then consider it. Therefore, this solution has been put on hold.

Today, I asked someone in the QQ group if I could solve this problem. I got two answers: socket programming. Add the US dollar number ($) before the shared name of the shared folder ), this prevents users from directly accessing from the network neighbors. Method 1 directly skips, method 2 has a good idea, but can only lie to those who do not directly enter the network path. You only need to know the path. However, this method reminds me that, whether it is socket programming or WCF, I have always been standing on the server side to consider how to solve this problem. Poor implementation on the server does not mean poor implementation on the client. Therefore, I decided to start from the client.

The entire network is an internal LAN consisting of a win2003 server and dozens of WINXP and Win2k clients. The server is equipped with MSSQL and shares files in Several folders for processing on the client, since the software used to process files is compiled by myself, this problem is transformed into how to allow my program to access shared files on the server only on the client, but none of them can.

When I manually restrict the installation of software, only the "cmd.exe" program is available. It is unrealistic to ban this program, but in another way, I can use it to kill it. I think of the virus "pandatv incense". I have read an article about its main work behavior. One of the most important points is to kill some specific processes based on the name or title displayed, I can also use this method for reference. You can only kill a path named assumer.exe with the actual path of the shared folder in the title. Direct disconnection is a processing method. In addition, you can hide the process window. Then, my program will pop up a window asking you to enter a specific password, if the password is correct, you can continue the access, which facilitates the Administrator's operations.

In addition to this method of directly entering the path through "Network Neighbor", open "my computer" or "run" in the "Start" menu, I also came up with a relatively secret method, that is, you can select "Network Neighbor" in the open file dialog box of a program such as NotePad to perform operations. At this time, add a dollar number ($) before the shared folder name) this is a good method.

The above section describes the main implementation methods and their production processes. The specific implementation steps are described below.

1. Set the shared folder on the server. Set the shared folder to start with "$.

2. Save the path information of these shared folders to the MSSQL database of the server.

3. modify the program for reading and writing shared files on the client, and add a Windows service to it. This service accesses the database every few minutes to obtain the latest list of shared folder paths, find the process whose window title contains the shared path in the local process every several seconds according to the path in the list, directly kill the process, or hide its window, and then prompt to enter the password to continue the operation.

4. To protect this monitoring service, you can also add the startup or timed detection monitoring service function to programs that are reading and writing shared files. The monitoring service does not work when it is stopped. In this way, when the monitoring service is stopped by the user, the user will report to the Administrator because the user cannot continue to use the read/write program, and the administrator can promptly detect this illegal operation. In addition, you can add the code that generates Event Logs because of manual stop in the Monitoring Service, save the Event Logs locally, and back up the logs to the server database.

5. Finally, package the program and service to the client.

　　

Later, I came up with a solution on the server: on the server, I used a program to obtain information such as sessions accessing the local shared folder and accessed files, if the information contains the visitor's process name, you can directly stop the access to this file. If this is the case, this problem can be easily solved. However, the "Computer Management" page does not show the information I want. The related programming methods are not found on the Internet, so I decided to adopt the above client processing solution.