How to Ensure the Operational Security of Enterprise Systems
The security management and operation and maintenance of enterprise systems involve the anti-trojan horse intrusion and anti-leakage work of the company's information system and data, which is a fundamental work that all CSOs and COOs are very concerned about. Although it is basic, once the treatment is not in place, it will bring重大 data, economic losses or reputation losses to the enterprise, and the consequences are unimaginable.
Daniu Network has sorted out some existing domestic and foreign literatures for the security management of enterprise systems, hoping to more effectively strengthen the operation of enterprise systems, and help enterprise system administrators discover and handle in advance the possible risks and vulnerabilities of the system, so as to ensure the safe operation of the enterprise system in advance and reduce the risk and cost of post-maintenance.
From the perspective of safety awareness, foreign scholars analyzed in "Six Reasons for the Difficulty in Improving the Security of Enterprise IT Systems".
As early as 2014, Sony's security defense mechanism had long been criticized. In 2015, after Target's CEO and CIO encountered the largest payment card information theft case in history, they successively announced their resignations. Since then, major media headlines: Michaels, PF Cahng’s, American Community Health Systems, UPS, Dairy Queen, Goodwill, Home Depot, Morgan Dai Baos, Kmart, Staples, and the widely concerned Sony have successively been hacked - not only Sony Pictures Executive Amy Pascal, but the entire Sony brand has suffered a catastrophic blow. The best practices to prevent the successful implementation of attack activities are almost obvious.
1. High-level neglect
Security matters not only bring additional costs, but may also bring additional steps to normal business processes and thus affect the productivity level. No executive will be noticed because of the proper handling of security matters, but they are often praised for the high short-term profits. In addition, CEOs often change jobs frequently, which makes long-term work such as security matters seriously neglected.
2. Misguided by suppliers
Security solution suppliers are always at the forefront of security threat hype (aimed at promoting their own security protection brands) and are committed to selling their so-called panacea. Technically, these threats are indeed real, but compared with these small tricks, installing the correct patches for unprotected systems can often bring more ideal protection effects. If you blindly follow the advice of suppliers, everyone is likely to move the most valuable resources from the most critical areas to other uses.
3. Problem delay due to operational inertia
Suppose the enterprise management is highly concerned and hopes to quickly solve the top security risk in the organization, that is, client Java. But at this time, several LoB managers raised objections, saying that the normal operation of several key applications needs to be based on client Java. Then, will the enterprise possibly put the operation aside and re-create such applications using security technology? Or do they prefer to put the problem aside and solve it together when the large-scale technology update plan for next year is launched?
4. Lack of correct guidance on the most obvious problems
Administrators often think that only idiots will easily click on a file attachment, open a link to a website infected with malware, or credulously believe a forged virus alert and install anti-virus software that is actually malware. But in fact, phishing emails are indeed very, very effective, and if ordinary employees have never seen a real anti-malware detection software, they simply can't know how to distinguish it. Users need systematic security training and correct prompts and guidance when encountering phishing activities. The training time doesn't need to be too long each time, but such activities must be promoted for a long time.
5. Thinking that everything is safe
Firewalls, intrusion detection systems, security event monitoring, network monitoring, two-factor authentication, identity management... Our enterprise has deployed all these solutions, and no one can break in casually! However, the cruel fact proves that if everyone has been targeted by thieves, the above mechanisms are not enough to completely eliminate the loss of digital assets. To prevent the problem, everyone must have a prudent mentality - encrypt key information that is idle, avoid setting permanent administrator privileges, and reduce the cross-loss that may be caused by malicious people after they succeed through various measures.
6. Having a fatalistic mentality
In my opinion, most enterprises are very clear about the seriousness of security problems. However, in the face of the cruel reality, they almost give up resistance. Professional hackers who have the ability to organize APT (Advanced Persistent Threat) attacks are almost unstoppable. The financial industry suffers billions of dollars in fraud and criminal activities every year, and this has become a part of its operating costs. After going through so many formalities, the malicious people are the ones who laugh last.
This mentality also has its rationality, after all, in the security confrontation, vulnerabilities always appear ahead of defense mechanisms. Yes, attack activities are indeed unavoidable, but this cannot be used as a reason to give up the best practices to significantly reduce the attack surface.
Domestic scholar Sun Xiaojun put forward two views in "China New Communications". He believes:
1. Improve in work processes and management systems. Enterprises should establish a network configuration management system according to their own situation to make the management personnel be notified in the first time when a threat occurs, increase the response speed to dangerous situations, and reduce the threat degree to the enterprise to the minimum. At the same time, strengthen the monitoring strength of enterprise network management, conduct real-time monitoring, view security events at any time, convert potential security hidden dangers into visible risk factors, and enable the enterprise to find and solve them in the first time when discovered.
2. Use the image method to make security hidden dangers "come to light". Images can clearly reflect network security problems, make potential security hidden dangers "come to light" into visual security threats, which is convenient for staff to solve problems. The formation of the image interface effectively reduces the pressure of staff to analyze data, makes threats more intuitive and transparent, and can effectively promote enterprise network security management.
From the technical perspective, the article "Ten Suggestions for Enterprise System Security Management and Strengthening" gives strong suggestions. It gives 10 very practical and effective system strengthening measures for enterprise system security management, which can better help enterprise system administrators discover and handle in advance the possible risks and vulnerabilities of the system, so as to ensure the safe operation of the enterprise system in advance.
1. Remove "." from the running path
In the super user (root) mode, the user must be clear about the command being run is what the user wants. Consider the following scenario, where the user logs in as the super user, then the user's path variable is.:/usr/bin:/usr/sbin:/bin:/sbin.
The user creates a script containing the following commands in the ls directory:
#!/usr/bin/ksh
cp /usr/bin/ksh /tmp
chown root:bin /tmp/ksh
chmod 6755 /tmp/ksh
rm -f ls
/bin/ls $*
Now user A calls and reports a problem that there are some unknown files in his home directory. The user, as the super administrator, uses the cd command to enter his directory and runs the ls -l command to view. Suddenly, without the user's knowledge, user A can run a shell script to obtain the user's super user privileges!
Such situations happen often, but are easy to avoid. If there is no "." in the user's path, the user will see a script named ls in his home directory and will not execute it.
2. Avoid risk scripts
When writing a script, always specify the full path of the application being used. Refer to the following script:
#!/usr/bin/ksh
date > log
find . -mtime +7 -ls -exec rm -rf {} \; 》 log 2>&1
Although there are only three lines and only two lines of execution commands, there are many security vulnerabilities:
It does not specify a path, it does not give the full path of the date, it does not give the full path of the find, it does not give the full path of the rm, it performs error checking, and it does not verify the correctness of the directory.
When writing a script, you often need to follow these simple rules:
Always specify a path.
Always use the full path for each application used.
Always run error checking, especially when running potentially destructive commands such as the rm command.
3. Keep an eye on easily overlooked scheduled tasks
To master the user's system, the user needs to clearly understand the programs it is running. Regularly review which programs are running in the user's scheduled tasks list file. The scheduled tasks files of many systems are stored in /var/spool/cron. Some scheduled task daemons additionally support files for hourly scheduled tasks, weekly scheduled tasks, monthly scheduled tasks, and yearly scheduled tasks, as well as a cron.d directory. Use the man cron command to determine the exact functions of the user's scheduled task daemon.
Check all files in each directory. Pay attention to the owner of each job. If the user's scheduled task daemon (crond service) supports, lock the scheduled tasks and only open them to the user IDs that need to use them. Please pay attention to each running file and the time it runs. If the user is running something that the user thinks they don't need, contact them, ask the reason, and then handle it accordingly.
Continuously track the user's scheduled task jobs and regularly check if there are any changes. If the user finds that something has changed, investigate and determine the reason. Continuously tracking what the user's system is doing is a key step to keep the user's system secure.
4. Record logs of all daemons
As we all know, if the daemon does not record any information at the first time, then saving and recording logs is useless. By default, some daemons create logs and some do not. When the user audits the user's system, verify whether the user's daemons record log information.
Any public daemon needs to be configured to log, and the logs need to be saved. Try to access some of the user's services and view the logs collected by the user's log server. If not, read the online manual of the service and find the required operations to activate recording. Start it and try to use the service again. Continuously check all of the user's services until ensuring that all logs are recorded and saved.
5. Run CIS scans
The best part of the CIS benchmark is the instructions they give. The report will not just simply mention "what the user has and which is bad"; it will tell the user the deeper reasons why it is bad, and it allows the user to decide whether to disable the "bad things" or keep them as they are. The benchmark tool may check many places that the user didn't think of and give the user a detailed report of the system.
After the CIS tool is installed, the user should have a directory /opt/CIS. Run the command cis-scan to understand the user's system. After the scan is completed, the user will have a document named cis-ruler-log.YYYYMMDD-HH:MM:SS.PID. This document is a summary report of the system, including all test results. However, this document does not include detailed information - which means it can only be used as an index to refer to the PDF document that comes with the scanning tool. Review the ruler-log file line by line. If there is a negative result, it is suggested to determine in the PDF document whether the change can be executed. Most changes can be implemented without affecting the operation of the server, but not all. Be careful of false negatives; the user may need to use the PortSentry tool to check if there is an lp vulnerability on port 515, which will cause the CIS tool to report that the user has an lp vulnerability incorrectly. At the end of the report, the higher the number, the "tougher" the user's system is.
6. Avoid using super user privileges during operation
Many services running on the server do not need super user privileges to perform their functions. Usually, they do not need any special privileges other than the ability to read and write data directories. But due to the Unix security measures that open TCP/IP ports running with super user privileges must be below 1024, plus the fact that most famous ports are below 1024, it means that the user's daemon must open its port with super user privileges.
There are several solutions to this dilemma. First, the safest is not to run all services. If the daemon is not running, then it does not need to run as a super user. However, this does not work every time. Sometimes the user also needs to provide the daemon to run the service. In this case, create a dedicated user ID to run the daemon and control it as strictly as possible. Only use this ID to write to writable directories and do not give this ID particularly high privileges. Then change the startup script so that the daemon only belongs to this new user ID. Now if an attacker uses a vulnerability to attack the user's server and compromise the user's daemon, the attacker will get a non-privileged account and must do further work to get super user privileges, which will give the user more time to track and stop him or her before more losses occur.
7. Scan and handle high-privilege files
All systems have set user ID (SUID) and set group ID (SGID) files. These files can use specific users or groups to run applications, scripts, and daemons instead of personal user IDs or group IDs. The top command is a good example, which has high running privileges so that it can scan process information in the kernel space. Because most users' default permissions cannot read this information, it is necessary for top to run with higher privileges.
Many operating systems allow the user to specify that certain disks do not support SUID and SGID, usually by using a command in the user's system mount file. In Solaris, the user will specify the nosuid command in /etc/vfstab.
8. Take control of open ports
Before the user publishes the user's system to the outside world, the user needs to know which ports are open and allow connections. Some ports are open without the user's knowledge, and the user should close them before people access the user's server through these ports. There are some tools that can let the user know that the user's system is exposed.
The Netstat tool can be used for investigation. Almost every operating system comes with the Netstat command. Netstat is a simple tool that can display the user's network information, such as network ports, routing tables, and network connection information. The Netstat tool displays all ports that have been used and defined with similar names under /etc/services, making it easier to parse and export. This is a good reason to ensure that /etc/services on the user's system is continuously updated. Use the man command on the user's system to find the capabilities of netstat.
It is suggested that the user spend some time learning netstat. If the user learns how to use it, it will provide the user with rich network information and let the user clearly see who connected to the user's system at what time.
9. Use a centralized log server
If the user is responsible for maintaining multiple servers, then checking the logs of each server will be very tedious. To this end, establish a dedicated server to collect log messages from all other servers. By integrating the user's logs, the user only needs to scan one server, which will save the user a lot of time. After the user's server is compromised, this is also a good archive file; the user can still view these log files elsewhere.
Create a core log server with a high-speed CPU and a large amount of available disk space. Close all other ports and services except syslogd to minimize the chance of this system being damaged, possibly except for using the TCP-wrapped SSH daemon to limit the user's workstations for remote access. Then verify that syslogd can receive messages from remote systems. This is different from from message provider server to message provider server. Some servers receive messages by default, and the user may need to turn it off; some do not receive messages by default, and the user needs to turn it on.
Create a system to archive old logs and form files. If the user's logs have ever been used as evidence, the user needs to be able to prove that they have not been changed, and the user needs to show how they were created. It is suggested that the user compress all timestamped logs that are more than a week old and copy them through read-only media, such as CD-ROMs.
Once the user has a server that receives logs, the user needs to start other servers to point to it. Edit /etc/syslog.conf and determine the information that the user wants to copy. At the very least, the user should copy the highest emergency level status, emergency status, important information, critical status, and warning information and more information that the user thinks is useful.
10. Keep software updated
Every piece of software has vulnerabilities. Most vendors audit the code and remove all vulnerabilities found, but some are inevitably released to the outside world. Some people spend a lot of time trying to find these vulnerabilities; some report them to the vendor, but some use them personally.
Many vendors provide a tool to help you keep the patches on your system up to date. HP-UX has software update management software, Solaris has patchdiag and patchpro, AIX uses SMIT, and so on. Run the user's diagnostic tool at least once a month to see the patches that the user's system can be updated, and decide whether to install them. Set aside at least one hour (or more time) every Sunday afternoon specifically as system maintenance time, and use this time to install patches and perform other necessary maintenance.
The user should develop a habit of often checking the websites to see if there are bug fixes or security patches released for each application the user has installed. Use the application list created earlier to determine if there are patches applicable to the user. Remember to update the user's list information after the user updates the patches.
【1】Six Reasons for the Difficulty in Improving the Security of Enterprise IT Systems, March 2015, Nuclear / Translator: Dong Jianwei
Original link: http://www.infoworld.com/article/2896513/security/why-improving-security-is-so-hard.html
【2】China Information and Communications, April 2013, Sun Xiaojun
【3】Ten Suggestions for Enterprise System Security Management and Strengthening, May 2015, Yushan Lunjin
The security management and operation and maintenance of enterprise systems involve the anti-trojan horse intrusion and anti-leakage work of the company's information system and data, which is a fundamental work that all CSOs and COOs are very concerned about. Although it is basic, once the treatment is not in place, it will bring重大 data, economic losses or reputation losses to the enterprise, and the consequences are unimaginable.
Daniu Network has sorted out some existing domestic and foreign literatures for the security management of enterprise systems, hoping to more effectively strengthen the operation of enterprise systems, and help enterprise system administrators discover and handle in advance the possible risks and vulnerabilities of the system, so as to ensure the safe operation of the enterprise system in advance and reduce the risk and cost of post-maintenance.
From the perspective of safety awareness, foreign scholars analyzed in "Six Reasons for the Difficulty in Improving the Security of Enterprise IT Systems".
As early as 2014, Sony's security defense mechanism had long been criticized. In 2015, after Target's CEO and CIO encountered the largest payment card information theft case in history, they successively announced their resignations. Since then, major media headlines: Michaels, PF Cahng’s, American Community Health Systems, UPS, Dairy Queen, Goodwill, Home Depot, Morgan Dai Baos, Kmart, Staples, and the widely concerned Sony have successively been hacked - not only Sony Pictures Executive Amy Pascal, but the entire Sony brand has suffered a catastrophic blow. The best practices to prevent the successful implementation of attack activities are almost obvious.
1. High-level neglect
Security matters not only bring additional costs, but may also bring additional steps to normal business processes and thus affect the productivity level. No executive will be noticed because of the proper handling of security matters, but they are often praised for the high short-term profits. In addition, CEOs often change jobs frequently, which makes long-term work such as security matters seriously neglected.
2. Misguided by suppliers
Security solution suppliers are always at the forefront of security threat hype (aimed at promoting their own security protection brands) and are committed to selling their so-called panacea. Technically, these threats are indeed real, but compared with these small tricks, installing the correct patches for unprotected systems can often bring more ideal protection effects. If you blindly follow the advice of suppliers, everyone is likely to move the most valuable resources from the most critical areas to other uses.
3. Problem delay due to operational inertia
Suppose the enterprise management is highly concerned and hopes to quickly solve the top security risk in the organization, that is, client Java. But at this time, several LoB managers raised objections, saying that the normal operation of several key applications needs to be based on client Java. Then, will the enterprise possibly put the operation aside and re-create such applications using security technology? Or do they prefer to put the problem aside and solve it together when the large-scale technology update plan for next year is launched?
4. Lack of correct guidance on the most obvious problems
Administrators often think that only idiots will easily click on a file attachment, open a link to a website infected with malware, or credulously believe a forged virus alert and install anti-virus software that is actually malware. But in fact, phishing emails are indeed very, very effective, and if ordinary employees have never seen a real anti-malware detection software, they simply can't know how to distinguish it. Users need systematic security training and correct prompts and guidance when encountering phishing activities. The training time doesn't need to be too long each time, but such activities must be promoted for a long time.
5. Thinking that everything is safe
Firewalls, intrusion detection systems, security event monitoring, network monitoring, two-factor authentication, identity management... Our enterprise has deployed all these solutions, and no one can break in casually! However, the cruel fact proves that if everyone has been targeted by thieves, the above mechanisms are not enough to completely eliminate the loss of digital assets. To prevent the problem, everyone must have a prudent mentality - encrypt key information that is idle, avoid setting permanent administrator privileges, and reduce the cross-loss that may be caused by malicious people after they succeed through various measures.
6. Having a fatalistic mentality
In my opinion, most enterprises are very clear about the seriousness of security problems. However, in the face of the cruel reality, they almost give up resistance. Professional hackers who have the ability to organize APT (Advanced Persistent Threat) attacks are almost unstoppable. The financial industry suffers billions of dollars in fraud and criminal activities every year, and this has become a part of its operating costs. After going through so many formalities, the malicious people are the ones who laugh last.
This mentality also has its rationality, after all, in the security confrontation, vulnerabilities always appear ahead of defense mechanisms. Yes, attack activities are indeed unavoidable, but this cannot be used as a reason to give up the best practices to significantly reduce the attack surface.
Domestic scholar Sun Xiaojun put forward two views in "China New Communications". He believes:
1. Improve in work processes and management systems. Enterprises should establish a network configuration management system according to their own situation to make the management personnel be notified in the first time when a threat occurs, increase the response speed to dangerous situations, and reduce the threat degree to the enterprise to the minimum. At the same time, strengthen the monitoring strength of enterprise network management, conduct real-time monitoring, view security events at any time, convert potential security hidden dangers into visible risk factors, and enable the enterprise to find and solve them in the first time when discovered.
2. Use the image method to make security hidden dangers "come to light". Images can clearly reflect network security problems, make potential security hidden dangers "come to light" into visual security threats, which is convenient for staff to solve problems. The formation of the image interface effectively reduces the pressure of staff to analyze data, makes threats more intuitive and transparent, and can effectively promote enterprise network security management.
From the technical perspective, the article "Ten Suggestions for Enterprise System Security Management and Strengthening" gives strong suggestions. It gives 10 very practical and effective system strengthening measures for enterprise system security management, which can better help enterprise system administrators discover and handle in advance the possible risks and vulnerabilities of the system, so as to ensure the safe operation of the enterprise system in advance.
1. Remove "." from the running path
In the super user (root) mode, the user must be clear about the command being run is what the user wants. Consider the following scenario, where the user logs in as the super user, then the user's path variable is.:/usr/bin:/usr/sbin:/bin:/sbin.
The user creates a script containing the following commands in the ls directory:
#!/usr/bin/ksh
cp /usr/bin/ksh /tmp
chown root:bin /tmp/ksh
chmod 6755 /tmp/ksh
rm -f ls
/bin/ls $*
Now user A calls and reports a problem that there are some unknown files in his home directory. The user, as the super administrator, uses the cd command to enter his directory and runs the ls -l command to view. Suddenly, without the user's knowledge, user A can run a shell script to obtain the user's super user privileges!
Such situations happen often, but are easy to avoid. If there is no "." in the user's path, the user will see a script named ls in his home directory and will not execute it.
2. Avoid risk scripts
When writing a script, always specify the full path of the application being used. Refer to the following script:
#!/usr/bin/ksh
date > log
find . -mtime +7 -ls -exec rm -rf {} \; 》 log 2>&1
Although there are only three lines and only two lines of execution commands, there are many security vulnerabilities:
It does not specify a path, it does not give the full path of the date, it does not give the full path of the find, it does not give the full path of the rm, it performs error checking, and it does not verify the correctness of the directory.
When writing a script, you often need to follow these simple rules:
Always specify a path.
Always use the full path for each application used.
Always run error checking, especially when running potentially destructive commands such as the rm command.
3. Keep an eye on easily overlooked scheduled tasks
To master the user's system, the user needs to clearly understand the programs it is running. Regularly review which programs are running in the user's scheduled tasks list file. The scheduled tasks files of many systems are stored in /var/spool/cron. Some scheduled task daemons additionally support files for hourly scheduled tasks, weekly scheduled tasks, monthly scheduled tasks, and yearly scheduled tasks, as well as a cron.d directory. Use the man cron command to determine the exact functions of the user's scheduled task daemon.
Check all files in each directory. Pay attention to the owner of each job. If the user's scheduled task daemon (crond service) supports, lock the scheduled tasks and only open them to the user IDs that need to use them. Please pay attention to each running file and the time it runs. If the user is running something that the user thinks they don't need, contact them, ask the reason, and then handle it accordingly.
Continuously track the user's scheduled task jobs and regularly check if there are any changes. If the user finds that something has changed, investigate and determine the reason. Continuously tracking what the user's system is doing is a key step to keep the user's system secure.
4. Record logs of all daemons
As we all know, if the daemon does not record any information at the first time, then saving and recording logs is useless. By default, some daemons create logs and some do not. When the user audits the user's system, verify whether the user's daemons record log information.
Any public daemon needs to be configured to log, and the logs need to be saved. Try to access some of the user's services and view the logs collected by the user's log server. If not, read the online manual of the service and find the required operations to activate recording. Start it and try to use the service again. Continuously check all of the user's services until ensuring that all logs are recorded and saved.
5. Run CIS scans
The best part of the CIS benchmark is the instructions they give. The report will not just simply mention "what the user has and which is bad"; it will tell the user the deeper reasons why it is bad, and it allows the user to decide whether to disable the "bad things" or keep them as they are. The benchmark tool may check many places that the user didn't think of and give the user a detailed report of the system.
After the CIS tool is installed, the user should have a directory /opt/CIS. Run the command cis-scan to understand the user's system. After the scan is completed, the user will have a document named cis-ruler-log.YYYYMMDD-HH:MM:SS.PID. This document is a summary report of the system, including all test results. However, this document does not include detailed information - which means it can only be used as an index to refer to the PDF document that comes with the scanning tool. Review the ruler-log file line by line. If there is a negative result, it is suggested to determine in the PDF document whether the change can be executed. Most changes can be implemented without affecting the operation of the server, but not all. Be careful of false negatives; the user may need to use the PortSentry tool to check if there is an lp vulnerability on port 515, which will cause the CIS tool to report that the user has an lp vulnerability incorrectly. At the end of the report, the higher the number, the "tougher" the user's system is.
6. Avoid using super user privileges during operation
Many services running on the server do not need super user privileges to perform their functions. Usually, they do not need any special privileges other than the ability to read and write data directories. But due to the Unix security measures that open TCP/IP ports running with super user privileges must be below 1024, plus the fact that most famous ports are below 1024, it means that the user's daemon must open its port with super user privileges.
There are several solutions to this dilemma. First, the safest is not to run all services. If the daemon is not running, then it does not need to run as a super user. However, this does not work every time. Sometimes the user also needs to provide the daemon to run the service. In this case, create a dedicated user ID to run the daemon and control it as strictly as possible. Only use this ID to write to writable directories and do not give this ID particularly high privileges. Then change the startup script so that the daemon only belongs to this new user ID. Now if an attacker uses a vulnerability to attack the user's server and compromise the user's daemon, the attacker will get a non-privileged account and must do further work to get super user privileges, which will give the user more time to track and stop him or her before more losses occur.
7. Scan and handle high-privilege files
All systems have set user ID (SUID) and set group ID (SGID) files. These files can use specific users or groups to run applications, scripts, and daemons instead of personal user IDs or group IDs. The top command is a good example, which has high running privileges so that it can scan process information in the kernel space. Because most users' default permissions cannot read this information, it is necessary for top to run with higher privileges.
Many operating systems allow the user to specify that certain disks do not support SUID and SGID, usually by using a command in the user's system mount file. In Solaris, the user will specify the nosuid command in /etc/vfstab.
8. Take control of open ports
Before the user publishes the user's system to the outside world, the user needs to know which ports are open and allow connections. Some ports are open without the user's knowledge, and the user should close them before people access the user's server through these ports. There are some tools that can let the user know that the user's system is exposed.
The Netstat tool can be used for investigation. Almost every operating system comes with the Netstat command. Netstat is a simple tool that can display the user's network information, such as network ports, routing tables, and network connection information. The Netstat tool displays all ports that have been used and defined with similar names under /etc/services, making it easier to parse and export. This is a good reason to ensure that /etc/services on the user's system is continuously updated. Use the man command on the user's system to find the capabilities of netstat.
It is suggested that the user spend some time learning netstat. If the user learns how to use it, it will provide the user with rich network information and let the user clearly see who connected to the user's system at what time.
9. Use a centralized log server
If the user is responsible for maintaining multiple servers, then checking the logs of each server will be very tedious. To this end, establish a dedicated server to collect log messages from all other servers. By integrating the user's logs, the user only needs to scan one server, which will save the user a lot of time. After the user's server is compromised, this is also a good archive file; the user can still view these log files elsewhere.
Create a core log server with a high-speed CPU and a large amount of available disk space. Close all other ports and services except syslogd to minimize the chance of this system being damaged, possibly except for using the TCP-wrapped SSH daemon to limit the user's workstations for remote access. Then verify that syslogd can receive messages from remote systems. This is different from from message provider server to message provider server. Some servers receive messages by default, and the user may need to turn it off; some do not receive messages by default, and the user needs to turn it on.
Create a system to archive old logs and form files. If the user's logs have ever been used as evidence, the user needs to be able to prove that they have not been changed, and the user needs to show how they were created. It is suggested that the user compress all timestamped logs that are more than a week old and copy them through read-only media, such as CD-ROMs.
Once the user has a server that receives logs, the user needs to start other servers to point to it. Edit /etc/syslog.conf and determine the information that the user wants to copy. At the very least, the user should copy the highest emergency level status, emergency status, important information, critical status, and warning information and more information that the user thinks is useful.
10. Keep software updated
Every piece of software has vulnerabilities. Most vendors audit the code and remove all vulnerabilities found, but some are inevitably released to the outside world. Some people spend a lot of time trying to find these vulnerabilities; some report them to the vendor, but some use them personally.
Many vendors provide a tool to help you keep the patches on your system up to date. HP-UX has software update management software, Solaris has patchdiag and patchpro, AIX uses SMIT, and so on. Run the user's diagnostic tool at least once a month to see the patches that the user's system can be updated, and decide whether to install them. Set aside at least one hour (or more time) every Sunday afternoon specifically as system maintenance time, and use this time to install patches and perform other necessary maintenance.
The user should develop a habit of often checking the websites to see if there are bug fixes or security patches released for each application the user has installed. Use the application list created earlier to determine if there are patches applicable to the user. Remember to update the user's list information after the user updates the patches.
【1】Six Reasons for the Difficulty in Improving the Security of Enterprise IT Systems, March 2015, Nuclear / Translator: Dong Jianwei
Original link: http://www.infoworld.com/article/2896513/security/why-improving-security-is-so-hard.html
【2】China Information and Communications, April 2013, Sun Xiaojun
【3】Ten Suggestions for Enterprise System Security Management and Strengthening, May 2015, Yushan Lunjin