Common Application Server Security Management Vulnerabilities

Common Application Server Security Management Vulnerabilities
 
 
 
 
 
Although enterprise application servers have been added, the security management of this application server cannot keep up. If you look at a company, you can always see some obvious security management vulnerabilities. Below we will list some typical vulnerabilities as an example to remind everyone to pay attention to server security management.
 
(1) All Hosts can Telnet to the server.
 
Because servers are usually placed in a specific space, if any maintenance work on the server, such as viewing the server's hard disk space, needs to be viewed on the server, obviously, it is not very convenient. We hope that we can perform routine maintenance on the server on our computers, instead of running it to the room where the server is stored.
 
Therefore, most of the maintenance work on the server can be performed via Telnet to the server and maintained through command lines. This undoubtedly provides a convenient management channel for the management of our servers, but it also brings some potential risks to the servers.
 
When attackers use some specific methods to know the Telent user name and password, they can access the server smoothly on any enterprise host. In particular, it is easier for some dissatisfied employees to vent their dissatisfaction with the company. In the past, when I was a CIO in a software company and an employee did not pay attention to the Administrator, I obtained the Telent username and password of the file server. Subsequently, the company was warned against the leakage of customers' confidential information. This employee was dissatisfied and used the stolen username and password to log on to the file server and delete many files. Fortunately, a sound backup system is adopted in the file server to avoid significant losses.
 
Therefore, Telent technology provides a convenient means for our server management, but its security risks cannot be ignored. In general, for Telent technology, we need to pay attention to the following aspects.
 
First, the Telent user name and password should be different from the administrator login user name and password of the server. That is to say, the username and password used to log on to the server host are different from the administrator username and password used to remotely log on to the server. In this case, the leakage of user names and passwords can minimize the harm to the server.
 
Second, it is best to restrict Telent to the server's user host. For example, we can restrict the server to allow remote Telent to the server only on the host of the network administrator. This implementation is also relatively simple. If it is a Microsoft server system, you can use its own security policy tools. Alternatively, you can use the firewall to restrict the IP addresses or MAC addresses of Telent to the server. In this case, even if the user name or password is disclosed and the IP address or MAC address is restricted, other users cannot log on to the server. In this way, only legal personnel can perform routine maintenance on the server.
 
Third, disable the Telent service if you do not need Telent to manage the server. There is no need to leave a backdoor for the attacker.
 
(2) All users of the file sharing house on the server have access permissions.
 
On the application server, we sometimes create several shared folders for the convenience of maintenance. However, improper management of these shared folders may also pose a major security risk to the application server.
 
If all users in a shared folder can access the folder without restrictions, a problem may occur. If there is a virus in the network, these folders are easily infected. When we accidentally open these shared folders on the server, the server will be infected with viruses, and even cause the server to become a machine.
 
Therefore, you need to pay special attention when setting shared folders on the server, because after the server crashes, it is fatal for enterprise information applications. Generally, do not set a shared folder on the application server. If necessary, follow the following security principles.
 
First, you need to add files as non-shared files in a timely manner. When we need to create a temporary shared folder, We need to delete the shared folder in time or change it to "not share. Clean up shared folders in time to ensure the security of shared folders.
 
Second, set the minimum permission for the shared folder. When setting shared folders, we may become accustomed to not setting access permissions, so employees can access Shared Folders without restrictions. However, when setting shared folders on the file server, you must note that when setting shared folders, you must set the users to access, it is recommended that only specific users can access this shared folder, especially the read/write permissions must be strictly controlled. Some people may think that I only share it for the moment, and it cannot exceed 10 minutes. However, if there is a virus in the network, it will take one second to infect the shared folder. Therefore, you cannot be lucky enough in server management.
 
(3) unnecessary services are not disabled.
 
A large number of services are installed when the server operating system is installed. For example, if we install the file server system, the WWW Service, Telent service, and DSN service may be enabled by default. However, for file servers, these services are often unnecessary. We have enabled these unnecessary services on the application server, which not only occupies valuable hardware resources, but also reduces the security of the file server.
 
Therefore, I suggest closing unnecessary services during server management.
 
If you use Microsoft's server operating system, you can view the services enabled by the current operating system by starting, setting, control panel, management tools, and services. In general, we can disable the following services.
 
First, the DHCP client. Because the application server generally uses a fixed IP address, you can disable the DHCP Client and prohibit the server from obtaining the IP address from the DHCP server. This can effectively prevent IP address conflicts, resulting in server network disconnection.
 
Second, pay attention to Ping attacks. Using Ping commands to launch denial-of-service attacks on application servers is a common method for many attackers. The basic principle is to use bots to continuously Ping the application server at the same time, resulting in depletion of application server resources and serving as a machine. Therefore, in general, you need to set "prohibit others from pinging yourself" on the file server, so that you can prevent DDOS and other malicious attacks.
 
Third, you can disable the remoteappstophelpsessionmanager service. This service is mainly used to manage and control remote assistance. If the service is terminated, remote assistance will become unavailable. If we do not need tools such as Remote Desktop Connection to remotely maintain this application server, we can directly disable this service. By default, this service needs to be started manually. We can disable this service for the sake of security.
 
The third is automatic update service. This is a controversial service. If this service is enabled, the operating system of the application server can automatically upgrade the latest operating system patch from the network to improve the operating system security. However, sometimes, when Microsoft is installed with the upgrade patch, the server becomes unstable, and sometimes the application server that is subordinate to the above cannot be used. Therefore, the author's suggestion is that if you belong to Microsoft products on the top of the application server, such as Microsoft's email server, you can enable this automatic update service. If you deploy an email server of another brand or a database system of another brand on their server operating system, do you want to enable this automatic update service, you should consider it with caution.
 
(4) Different administrators use the same account to manage the server.
 
Sometimes, multiple applications may be deployed on one server. For example, an application server may be both a mailbox server and a file server. Different applications have different administrators. Some enterprises may use the same user name to manage different services for ease of management. I think this is not safe.
 
When an administrator manages an application service, he or she may accidentally change the configuration of another service. At this time, the other administrator is unaware of the configuration. In this case, another service may encounter a running error. Therefore, this will generate security vulnerabilities for server management.
 
To this end, I suggest you use one server for a service. Although this requires a certain amount of expenditure, if a server encounters a problem, it will only affect one application at most, it can minimize the adverse effects caused by server problems.
 
If you need to deploy different services on different servers due to cost constraints, it is best to create different administrator accounts when installing the services, then use the corresponding account to log on and deploy the relevant services. In this way, mutual interference between administrators can be minimized. Even if the same administrator manages different services, it is best to create different accounts.