SQL Server: "Less" is more secure

To be honest, most of the SQL Server installed in your company boils down to one of the following two types. The first type is the machine for the developer who installed SQL Server (that is, one of several types of installation-desktop, Standard, enterprise, or an obvious development version). The second type is Microsoft's SQL Server Desktop Engine (MSDE) for various installations for various applications, including the use of MSDE as a backup, network management, or other toolkit for information storage. One common feature of these two types of changes is that most of them do not need external connections at all, except for applications that reside on the host.
　　
Now, let's do a simple test: how many connections from other machines in the network are always listening to those connections? Yes-almost all of them. In a recent penetration test, I found that about 90% of the company's SQL Server installations were used by software installed on the same machine and never received connections from other machines in the network. In addition, both TCP/IP and netlibs (named pipe network Library) are enabled and monitored in all but 2 machines in this 90%.
　　
Here we have a very good example of the excessive surface area. That is, when the machine is exposed to this level without invoking any relevant measures, then encountering accidental discovery, violent attacks, and possible remote buffer overflow attacks is obvious. Recently, for MSDE release A, Microsoft started to install MSDE by default without enabling any netlibs to help minimize the exposed surface area. However, many older installations of MSDE still do so and continue to monitor.
　　
An overly netlib solution to support the problem is simple. Any SQL Server or MSDE instance that does not require an outside connection should disable all netlibs unless it is a shared memory netlibs, which is turned on by default. Shared memory netlib exists only on the same machine as the application that uses them, and does not allow connections from outside hosts in the SQL Server environment.
　　
If you are using SQL Server, the fix is very simple. Just load the server network Utility for each instance of SQL Server you want to protect and disable all netlibs (in the Enable protocol). Then, stop and restart the SQL Server instance for the modification to take effect.
　　
If you're using MSDE, you'll have to pay a little bit. Of course, if you have a SQL Server installation on the same machine and the Server Network Utility is installed, you can see the MSDE instance in the Drop-down list. However, you can delete netlibs in exactly the same way as described earlier for the SQL Server instance.
　　
If you do not have access to the server Nerwork Utility on the host, you need to edit the registry key to directly control support for Netlib. This key is located in the
　　
Hkey_local_machine\software\microsoft\mssqlserver\mssqlserversupersocket\netlibprotocollist
　　
Just edit the REG_MULTI_SZ there, delete any numeric data (TCP/IP and Named Pipes are "TCP NP" by default). Again, you need to stop and restart the MSDE instance for the modification to take effect.
　　
After all netlibs are disabled, only shared memory netlib can also communicate with SQL Server. This is important for understanding netlib and your application: to connect to a local SQL SERVER/MSDE instance, you can no longer use the name of the local machine (or IP address) as the name of the server in the connection string. You need to use some "." or the word "(local)" To replace the server name or IP address. Some applications behave differently from one another, so you need to be sure to test thoroughly. Using one of those strings as the name of the server can tell the local SQL Server client network subsystem to use the shared memory netlib to replace the network-based library.
　　
Now that you know how to move netlib and still connect to an instance of SQL Server, you should tell your developers how this is done because they are most likely to install the local SQL SERVER/MSDE environment the most times. Letting the environment stop listening can protect them from attacks in remote locations, hotspots, or other public environments where they are likely to be attacked. Minimizing surface areas is a key part of the security challenge, and making this approach the default option for all new SQL SERVER/MSDE installations can greatly strengthen your infrastructure.